One of the most important parts of SSL/TLS, as it is used in browsers, is the use of certificates to identify the website you are visiting, and to identify the keys used to agree on the encryption keys used for the connection.
The certificate is the website's passport, and like a passport it is issued by an authority trusted by the people checking them. For passports this is the government of a country, for certificates it is a trusted Certificate Authority (CA).
As with passports, there are a lot of things that have to be checked to make sure the certificate is not forged.
Each certificate contain, among other things the name of who the certificate is issued to (the website); the public key of the website; who issued it (the CA); and a digital signature of the data in the certificate, which is signed by the CA.
To verify the signature the browser must use the public key of the CA to decrypt the signature (which could only be created by using the associated private key), and compare the result with the calculated "checksum" of the certificate. The public key is stored in another certificate issued to the CA – the CA certificate.
There are two types of CA certificates, the ones that are signed by yet another CA, called Intermediate CA certificates, and certificates signed by the CA itself, which are known as the Root Certificates or Self Signed Certificates.
The Intermediates CA certificates are verified using the public key of the signing CA, while the Root CA certificates are verified using the public key in the certificate itself.
The Root CA certificate is a special case. By itself it only verifies that somebody claiming to be the named issuer issued the Root Certificate, and by extension vouches for the named identity in the certificates issued from it. But that does not carry any real assurances.
To be sure that the Root CA is valid the signature on the certificate have to be verified by a trusted copy of the Root Certificate, stored in the client's list of such certificates. These certificates are usually shipped with the client, and are accepted and trusted by the vendor to be reasonably careful about who they issue certificates to and how they store the private key. The user can elect to not trust some of these roots, and may add his own list of certificates.
Only a certificate and its associated certificate chain that can be verified and traced back to a Root in the Trusted Root store on the client is accepted automatically. If a certificate cannot be verified because the signature does not validate this is a fatal error; if we can't trace the certificate to a known root we display a certificate warning.
A problem often encountered is that a web site gets a certificate from a CA that is issued from an Intermediate CA (Most CAs do this now, for convenience and security reasons, as well as for selling CA certificates to CAs without their own root or to cross-sign roots) but the web site administrator forgets to install the Intermediate CA certificate on the server. This means that the client will not be able to trace the certificate to a known Root, even if it has the Root in its repository, because clients usually do not, and are not expected to, know specific Intermediate CA certificates; the result (for the user) is an unexpected Unknown Issuer certificate warning.
SSL/TLS servers that do not send intermediate certificates are actually not operating in compliance with the SSL/TLS standard. The standard requires the server to send any CA certificates it cannot reasonably expect the client to have already, and the only thing it can expect the client to have is the root certificate, and not any intermediates.
There is however a mechanism (called Authority Information Access, AIA) defined in the specification of the certificate format that let the CA specify a "CA Issuer" download location for the Intermediate CA certificates. This mechanism is already used by at least one other browser (which neatly explains why so many badly configured sites get past testing), and now Opera 9.50 also use this mechansism.
When Opera 9.50 encounters a site with a certificate chain that is missing an Intermediate CA certificate linking it to the Root, but the certificate specifies an AIA issuer download location, Opera will download the specified certificate. If the verification then succeeds (without other incidents) to link the certificate with a known root, the certificate will be accepted as normal, and the intermediate CA certificate will be "cached" in the new Intermediate CA certificate store in Opera's certificate manager for future reference, to avoid downloading it again later.
What this means is that you will no longer get any certificate warnings about unknown CAs when the certificate is issued from a root and a CA that also includes an AIA issuer download location for the intermediate certificate(s) for the Intermediate CA(s) that issued the certificate.
Special thanks to Gary and Les in Verisign for helping me debug this new functionality.
:yes: for standards.