I purchased a GeoTrust RapidSSL certificate from Namecheap to install on an Amazon Web Services Elastic Load Balancer. I won’t go into all the details of deploying SSL on AWS here, but I do want to document something about the certificate chain.
(Update December 12, 2016: apparently Namecheap and their SSLs subsidiary no longer sell RapidSSL certificates., but you can purchase RapidSSL from other resellers. If you choose another brand like Comodo’s PositiveSSL, the concepts below would need to be adjusted accordingly.)
Amazon wants you to install the intermediate and root certificate when you install your SSL certificate. You bundle these together in one “chain,” which is to say, you just copy and paste them into one text file, with the root certificate last.
The first trick was finding the root certificate, since that is not included in the bundle. I found that on the GeoTrust Root Certificates page as Root 2 (serial number 23456). So the chain I uploaded was:
My Rapid SSL certificate (signed by RapidSSL CA)
-> Rapid SSL CA certificate (serial number 0236d1, signed by GeoTrust Global CA)
–> GeoTrust Global SA (serial number 23456, self-signed)
However after uploading my certificate with that chain, the GeoTrust SSL checker gave me two recommendations:
It’s unclear to me from the Amazon instructions whether the root should be included or not. For now, let’s assume that’s okay.
But why does it say that I need to update the chain? And why does the Download certificate link point to a GeoTrust Global CA certificate that is not in my chain?
On closer examination, I see something interesting about these certificates. Here is the GeoTrust Global CA root that I installed. Note that the Issuer and and Subject are the same, indicating it is a self-signed root:
Now here is the “extra” certificate that the GeoTrust SSL checker suggested:
Here the Issuer is Equifax but the Subject is still GeoTrust Global CA; in fact the Subject Identifier is identical to the previous certificate.
What we have here, as explained in this StackExchange post, is a cross-signed root certificate. The Equifax root has signed the self-signed GeoTrust Global CA root. Why? Because older (by now, probably much older) browsers did not trust the GeoTrust root, but they did trust the older Equifax root. By adding this Equifax root, the GeoTrust root can act as an intermediate certificate and trust is ultimately based on trusting Equifax. The chain would look like this:
My Rapid SSL certificate (signed by RapidSSL CA)
-> Rapid SSL CA certificate (serial number 0236d1, signed by GeoTrust Global CA)
–> GeoTrust Global SA (serial number 23456, self-signed )
–> GeoTrust Global SA (serial number 12bbe6, cross-signed)
—> Equifax Secure Certificate Authority (serial number 35def4cf, self-signed)
By the way, I tested my site on a copy of Internet Explorer 6 that I keep in a Windows XP SP3 virtual machine. Even there, it worked fine without the Equifax root, probably because I have continued to update the root certificates packages on that machine.
Adding Equifax to the trust chain may have been important in the early days of the GeoTrust Global CA (note that it was issued in 2002). By now, most browsers trust GeoTrust directly, so the Equifax root is not needed. Based on that, I plan to leave the Equifax root out of my Amazon chain unless I hear that someone using an ancient computer absolutely must have to access my application.