Trouble understanding SSL certificate chain verification

Question

My app uses SSL to communicate securely with a server and it's having trouble verifying the certificate chain. The chain looks like this:

Entrust.net Secure Server Certification Authority -> DigiCert Global CA -> *.ourdomain.com

We are using a certificate store pulled from Mozilla. It contains the Entrust.net certificate, but not the DigiCert Global CA one.

My understanding is that an intermediate authority doesn't have to be trusted as long as the root authority is, but the verification fails:

% openssl verify -CAfile mozilla-root-certs.crt ourdomain.com.crt error 20 at 0 depth lookup:unable to get local issuer certificate 

So do I need to explicitly trust the DigiCert Global CA in order for verification to pass? That seems wrong. But you tell me!

EDIT: I now understand that the certificate file needs to be available to OpenSSL up front. Something like this works:

% openssl verify -CAfile mozilla-root-certs.crt -untrusted digicert.crt ourdomain.com.crt ourdomain.com.crt: OK 

This allows me to provide a copy of the DigiCert CA without explicitly saying "I trust it", the whole chain still needs to be verified.

But surely browsers like Firefox won't always ship with a copy of every single certificate it'll ever need. There's always going to be new CAs and the point is to use the security of the root certificate to make sure all intermediate CAs are valid. Right? So how does this work? Is it really as silly as it looks?

Answer 1

The intermediate certs have to be installed on your web servers as well as the certs for your own domain. I was having this same problem last week... Firefox seems to be more picky than the rest of the browsers about this.

Answer 2

Here is correct way to verify a certficate coming from a web server

• Client maintains a list of trusted CA ROOT certificates
• Web Servers should return the following Server Certificate - Required
• Intermediate Certificate(s) - Required ROOT CA Cert - Not required/Optional

When a client connected to a server, it gets the server certificate and intermediate certificate(s) from the server. The client then then builds a chain of trust from the server certificate, through the intermediate certificate(s) to one of the CA ROOT certificates it trusts. ROOT Certificates are always self-signed - so that is where the chain stops.

Here is a simple command to test a web server certificate using openssl

openssl s_client -CAfile <root ca file> -quiet -showcerts -connect IP:PORT 

In the case of virtual hosting, where multiple certificates are served on the same IP:PORT, server name indication (SNI) can be enabled using -servername <FQDN>. Otherwise, the default certificate will be sent.