How does IE/Chrome know which Intermediate CA to use when not part of chain?
A server on my network is signed with a certificate issued by RapidSSL CA but does not supply to complete issuer chain (RapidSSL CA's certificate is issued by GeoTrust CA which is a trusted root authority).
When I access the site using firefox I get the following error:
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
But if I connect to the site using IE or chrome it works and I noticed that RapidSSL is then loaded as a Intermediate CA afterwards. I don't understand how Chrome/IE (I assume it uses the Windows Certificate store) knows to add RapidSSL as intermediate CA.
I get the expected behaviour (according to me) when I use openssl s_client to debug the connection.
I get the following when only using GeoTrust as CA:
Verify return code: 21 (unable to verify the first certificate)
Using only RapidSSL as CA:
Verify return code: 2 (unable to get issuer certificate)
When using both:
Verify return code: 0 (ok)
Can anyone help me understand how Windows knows to load RapidSSL CA as intermediate authority?
CA certificates are downloaded based on URL information in the Authority Information Access (AIA) extension of the issued certificates.
Firefox, last I heard, uses its own certificate store and/or chaining engine. Chrome and IE use the one in Windows.
Certificate Validation Process
When a certificate is presented to an application, the application must use the certificate chaining engine to determine the certificate’s validity. Only after the certificate chain is successfully validated can the application trust the certificate and the identity represented by the certificate. Three distinct but interrelated processes are used to determine a certificate’s validity:
■ Certificate discovery To build certificate chains, the certificate chaining engine must collect the issuing CA certificate and all CA certificates up to the root CA certificate. CA certificates are collected from the CryptoAPI cache, Group Policy, or Enterprise Policy, or, as a last resort, downloaded from Authority Information Access (AIA) Uniform Resource Locators (URLs) in issued certificates. Once a certificate is downloaded from a location other than the CryptoAPI cache, it is added to the user’s CryptoAPI cache for faster retrieval.
■ Path validation When the certificate chaining engine validates a certificate, it does not stop at the presented certificate. Each certificate in the certificate chain must be validated until a self-signed root certificate is reached. Validation tests can include verifying authenticode signatures, determining whether the issuing CA certificate is included in the NTAuth store, or the inclusion of specific application or certificate policy object identifiers (OIDs). If one certificate fails the validity test, it is possible that the entire chain will be deemed invalid and not used by the calling application.
It is indeed the different certificate store. The intermediates are only needed on apps that don't already have those certs built in. The issuer CA is included in every certificate. The only question is if that issuer cert is trusted. Adding the intermediates helps on software with a smaller set of trusted certs installed by default. .