New in Kestrel: Faster Root Certificate updates

Extended Validation (EV) is not the only new feature in the most recent Weekly; we've also improved the certificate database by making it able to download new Roots automatically. This means that we can add new Roots to the Certificate Authority database without requiring users to update their installation.

Root Certificates are one the fundamental pillars of Internet security. They are used to confirm the identity of secure webservers by acting as a trusted third party. The introduction of a third party is what makes it possible for two parties that have had no previous contact to determine who the other is, and, based on that, establish an encrypted connection. That is the true "magic" of Public Key Cryptography.

The problem with Root Certificates has been that before they can be used, each relying party (in particular, TLS clients, as in our case) must have a copy of it. If a party doesn't have a trusted copy of the Root it cannot verify the certificate that the other party sent, and can therefore not make any statement about the identity, nor establish a secure connection to that other party.

In SSL/TLS clients like Opera, much of this initial problem has been handled by the vendor shipping a list of trusted Roots with each installation, as well as some update mechanism to add new Roots when necessary. In Opera, this update mechanism has until now been rather crude, as a new version of Opera would have to be installed by each user.

In this Weekly, we are adding an automatic certificate download capability that works like this:

  • A number of frequently used Roots are still shipped with Opera.
  • If a Web site presents a certificate issued from a Root that is not in the local Certificate store, but is available in the online repository, it will be downloaded and installed in the repository. (Please note that this means that if you delete a certificate rather than marking it as untrusted, it will be downloaded again if necessary.)
  • If a Root is added to the repository, and is closely associated with another Root, we can instruct all Opera instances to download that root if they have the other Root. This is particularly important in relation to how EV certificate chains have to be organized.

The certificates are downloaded from a repository hosted at https://certs.opera.com/, which is also the server hosting the EV information, and the information is refreshed every 6 hours. The certificate files hosted on this server, whose names are constructed from a SHA-256 digest of the CA name and other information that uniquely identifies them, are all digitally signed to prevent forgery.

A separate list in the repository identifies all the certificates that are included in the repository. This list is used to stop Opera from checking the repository for unknown issuers. The list is currently retrieved every time Opera starts, but will later be checked when Opera checks for other updates, that is, once a week when Opera starts.

We are particularly interested in your experiences with this new functionality and would like you to test it in various environments, such as:

  • performing an upgrade of a used test installation of 9.2x
  • clean installs,
  • whether or not secure sites that worked in 9.2x and previous Kestrel Weeklies work OK in this build.

Also, somebody may ask, "Does this mean Opera now have the ability to automatically remove a Root certificate?". Yes, in extreme cases, such as the unlikely event (I hope) of a Root Key compromise, we now have the ability to do what previously would have required an emergency security update.
We also have the ability to add certificates to the new "Untrusted" certificate store, which might be necessary in cases where an important certificate has been issued in error.

11 thoughts on “New in Kestrel: Faster Root Certificate updates”

  1. Is the ~/.opera/cache4/revocation/ directory a side effect of the EV snapshot (GNU/Linux O9.50-1904(.6))? If so, any idea how big it will get/grow?

  2. Wachovia is due to RSA Security not serving their CRL as a binary file (as our code currently expects), but as a PEM file (which takes at least 33% more space). That results in a decoding error which is considered fatal for the handshake.

  3. The revocation directory is a result of a change in how we handle OCSP, we now cache the responses persistently (no responders used the security feature that made it uncacheable, so we’ve stopped using it, at least for the moment), and CRLs (revocation lists) are also stored there. It keeps those data out of the way of the normal cache maintainance. The cache mechanism is the same as the one we use for widgets.

  4. @mstreibe: Front page works OK (with the green EV indicator on :up:), but as your problem is only seen after login I am unable to check.There are lots of changes in this build, so you might perhaps take a look at the source of the page to find out if what is missing is really missing, or if it is just not displayed.

  5. @yngve: Strange. After I first saw that the page hasn’t been displayed correctly, it reverted to the previous build and there it worked. Now I tried again with the current build and this time it was ok too.Don’t know what the problem was. Maybe incidently the server side had a temporary problem when I tried the new build. I’ll keep an eye on that.

  6. Since 9.50, I have problem importing local self-signed certificates. In 9.27 it was as easy as visiting the https page and accepting the certificate. Now it doesn’t work, and when I try to import manualy .pem file, I get the “The certificate installation failed.” error.So my question is: How to import CA-certificates into opera 9.5?

  7. comp64: There has been a number of security concerns about that kind of certificates, and how many users click OK too quickly, so it was decided to remove the ability to install certificates directly from the connection. You must import the certificate into the authorities panel.

  8. OK, then please help me with the second part of my post:When I try to import manualy .pem file, I get the “The certificate installation failed.” error.

Comments are closed.