nted to it. Then things got more complex…
See, the benefit of root key signing was also the risk. Since a root key was trusted implicitly, if that key was compromised, it could be used to sign ANY certificate, and malicious people could present seemingly identical sites to unsuspecting people. It’s sort of like the equivalent of stealing the printing press and paper to counterfeit money.
The most likely way that the root key would become compromised is during the signing process. Since every certificate needed signed by the root key, the root key needed to be everywhere signing took place. The volume of certificates that get churned out by some of these CAs is huge, which meant that one hole in the system anywhere could be exploited to cause the whole system to come crashing down.
In order to avoid this problem, what CAs have implemented are “intermediate certificates”, which alleviate the necessity of keeping the root key around by creating “certificate chains“. The root key still creates the public certificate installed in your browser, but it no longer signs the certificates presented by web servers. Instead, the signed certificates refer to the intermediate certificate, and the intermediate certificate refers to the root key.
This picture from IBM does it much more justice than I can:
The problem for us is that the browsers don’t inherently know anything about the certificate chain…so we have to configure our web servers to present the entire chain of certificates. To facilitate this, lots of CAs have provided ready-made certificate chains in .pem files. I use Thawte, and you can get their intermediate bundles from here. Essentially, it’s just a text file:
$ cat SSL_PrimaryCA.pem -----BEGIN CERTIFICATE----- MIIERTCCA66gAwIBAgIQM2VQCHmtc+IwueAdDX+skTANBgkqhkiG9w0BAQUFADCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl cnZlckB0aGF3dGUuY29tMB4XDTA2MTExNzAwMDAwMFoXDTIwMTIzMDIzNTk1OVow gakxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwx0aGF3dGUsIEluYy4xKDAmBgNVBAsT H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xODA2BgNVBAsTLyhjKSAy MDA2IHRoYXd0ZSwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYD VQQDExZ0aGF3dGUgUHJpbWFyeSBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEArKDw+4BZ1JzHpM+doVlzCRBFDA0sbmjxbFtIaElZN/wLMxnC d3/MEC2VNBzm600JpxzSuMmXNgK3idQkXwbAzESUlI0CYm/rWt0RjSiaXISQEHoN vXRmL2o4oOLVVETrHQefB7pv7un9Tgsp9T6EoAHxnKv4HH6JpOih2HFlDaNRe+68 0iJgDblbnd+6/FFbC6+Ysuku6QToYofeK8jXTsFMZB7dz4dYukpPymgHHRydSsbV L5HMfHFyHMXAZ+sy/cmSXJTahcCbv1N9Kwn0jJ2RH5dqUsveCTakd9h7h1BE1T5u KWn7OUkmHgmlgHtALevoJ4XJ/mH9fuZ8lx3VnQIDAQABo4HCMIG/MA8GA1UdEwEB /wQFMAMBAf8wOwYDVR0gBDQwMjAwBgRVHSAAMCgwJgYIKwYBBQUHAgEWGmh0dHBz Oi8vd3d3LnRoYXd0ZS5jb20vY3BzMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU e1tFz6/Oy3r9MZIaarbzRutXSFAwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cDovL2Ny bC50aGF3dGUuY29tL1RoYXd0ZVByZW1pdW1TZXJ2ZXJDQS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAhKhMyT4qvJrizI8LsiV3xGGJiWNa1KMVQNT7Xj+0Q+pjFytrmXSe Cajd1FYVLnp5MV9jllMbNNkV6k9tcMq+9oKp7dqFd8x2HGqBCiHYQZl/Xi6Cweiq 95OBBaqStB+3msAHF/XLxrRMDtdW3HEgdDjWdMbWj2uvi42gbCkLYeA= -----END CERTIFICATE-----
This is where I started having a problem. See, I was looking at documentation that was telling me to use the SSL_CA_Bundle.pem file, which includes both the Primary Intermediate CA cert and the Secondary Intermediate CA cert. This was making my web server (actually a load balancer) puke.
The key? Only use the Secondary CA cert. I didn’t even figure it out. I went to bed in disgust. My boss Andrew played with it after I gave up and finally figured that out. How we were supposed to know? I’ve got no idea.
Also, why we had to use the Secondary CA and not the Primary CA? I don’t know that either. I examined my certificate with
openssl x509 -in mycert.pem -noout -text
and there’s no indication of the secondary CA being used, so I’ve got no idea. If you do know, I’d love to hear an explanation.
So yeah, I worked on this for a total of 5