The most common SSL connection you will evaluate is from a web browser to an HTTPS web site. Fortunately, we have seen that the popular web browsers will not encounter a problem with this certificate expiry. So we will to focus on server-to-server connections. It is still good to update your web server chains, but we believe it is not required.
Server-to-Server SSL is the Concern
These SSL protected services are client-server protocols and, with server to server, that word “server” can be ambiguous and confusing, so let’s attempt to clarify terms. Let’s use an example of server messenger.dept.utoronto.ca using our LDAP server, utorable.auth.utoronto.ca. The admin of messenger.dept would naturally think of that system as a server. But messenger.dept is connecting to the utorable.auth, so messenger.dept is an LDAP client, from UTORable’s perspective. Thus, messenger.dept is both a client and a server. If we say “the server’s settings need to be changed”, it is not clear which system we mean. But we know that messenger.dept connects to utorable.auth.
messenger.dept.utoronto.cais the source of the connectionutorable.auth.utoronto.cais the destination of the connection
So we’ll use the terms “source system” and “destination system” instead of client and server.
When a source connects to a destination, the destination presents a certificate and the source system must decide if it will accept the certificate and trust the destination. When the “AddTrust External Root CA” certificate expires on Saturday, May 30th, some destination systems will likely present expired certificate chains to source systems and the source systems will not accept such connections. Action must be taken to fix the destination’s certificate chain.
In this example, utorable.auth.utoronto.ca must update its certificate chain or messenger.dept.utoronto.ca will reject connections.
What Needs to be Fixed and Who Can Fix It? Who Will?
You need to evaluate your servers:
- Which are sources or destinations of an SSL connection?
- Does the destination present an expiring certificate?
- Who is responsible to fixing the certificate chain? (The responder.)
You should make a table of source, destination, responder, and status. For example,
| Source | Destination | Responder | Status |
|---|---|---|---|
| messenger.dept | utorable.auth:ldaps | utorauth@utoronto.ca | Updated |
| idpz.utorauth | sites.utoronto.ca:https | shib.admin@utoronto.ca | Updated |
| foo.dept | bar.dept:https | dept.admin@utoronto.ca | Pending |
Regrettably, there is little time to make that list, to find the responders, and see who will address the issue and when. But the issue will need to be addressed, before or after the weekend.
Does the destination present an expiring certificate?
It’s best if you know the Responder and can ask them. There are some tools that you can use, though only the simple public web service is easy. One such simple example is sites.utoronto.ca. This server is needed by Shibboleth Service Providers (SPs) and Identity Providers (IdPs). Since it’s just a public web server (serving “metadata” files for Shibboleth), you can use external websites to examine sites.utoronto.ca’s certificate chain.
Visit https://www.ssllabs.com/ssltest/index.html
- enter “sites.utoronto.ca” in the Hostname field
- for privacy, select “Do not show the results on the boards”, and
- Submit.
SSLlabs.com runs an evaluation of the certificate. It usually takes a minute and it will report on the certificate chain. If there is an expiring certificate, you’ll see it in the report:
