Implementer's notes

Today we have formally EV-enabled the first two CAs.

For more information, please see The Rootstore's announcement

We have now created a homepage for the Opera Root Certificate repository: The Rootstore.

The Rootstore will be where we announce updates and general information about the root repository.

If you are a Certificate Authority, or generally interested in Opera's certificate store, The Rootstore will be the place to watch.

Last week at the W3C's Web Security Context Working Group's meeting at Opera HQ here in Oslo we discussed what should be the criteria for displaying the Extended Validation (EV) indicator, or the Augmented Assurance (AA) indicator, as the WG has decided to call this technology.

As I have said earlier, we are of the opinion that the EV indicator should not be displayed unless all content is loaded from EV servers.

The opposing view is that, so long as all content is loaded over secure connections, the displayed document is what the author of the main document intended (bugs, vulnerabilities, and all), and that it is therefore only necessary to verify that the main document is served from an EV server, as this will provide the information necessary to identify the author.

The decision of the WG was in favour of the less restrictive position: if an AA/EV document loads all resources over strongly TLS-protected connections, then the document can be displayed with an AA/EV indicator.

In the interest of providing a common user experience with respect to EV we have decided to follow this recommendation, and today's Kestrel snapshot include this policy change.

We have, however, left the old logic in place, controlled by a preference that can be updated remotely. This permits us to quickly change to a stricter mode if the consensus about what constitutes an AA/EV site changes in the future.

As a consequence of this policy change a large number of sites, such as Paypal, with mixed EV and non-EV content will now get the "Green Bar" in Opera:

One of the new SSL/TLS features we added in 9.0 was the TLS Certificate Status Extension, which is essentially asking the TLS server to do the revocation check for its own certificate (OCSP), thus telling the client whether or not the certificate it presents is valid.

At first this can look pretty much like putting the fox to guard the henhouse, but there is no real danger as even a malicious server can't get away with sending the wrong data for long. This is because the status information is generated and signed by the certificate issuer (CA), meaning it can't be faked, and is only valid for a few days at most, reducing the window of opportunity to a minimum.

The primary reason for using this method is reducing the traffic load on the OCSP servers. Once all clients support OCSP the load on those servers will be tremendous, so it is prudent to look at solutions to reduce not just the network load on the CA's servers, but also the time used to check the validity of the certificate. It is a fact that making a direct OCSP check takes time, and that it increases the time to establish a connection, slowing down the user's surfing.

Therefore, using the TLS server as a proxy makes sense, and we introduced it in 9.0.

Unfortunately, it turned out that the implementation had a problem. Due to a mistake in the way the Extension was read, a method introduced in 9.0, Opera 9.0 to 9.25 will crash when the server tells it that it will send the status message.

This showed up only when Microsoft started testing its Windows 2008 server (IIS 7), due to be released this month.

Unfortunately, it was not until less than two weeks ago I learned of the problem, when Microsoft contacted me directly with a testcase (Thanks). It didn't take me long to find and fix the problem, but it still requires releasing a new Opera version.

In this case I will strongly recommend that users of Opera 9.0 to 9.25, inclusive, upgrades to the upcoming Opera 9.26 (Update: It is now available), due to be released later this week (but an RC is available). The next 9.50 weekly will also contain a fix for the problem. In particular, you should upgrade if your installation crashes when it tries to connect to an SSL/TLS/HTTPS site.

We apologize for the inconvenience, in this case we were a little bit too far out on the (b)leading edge.

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.