The Opera Rootstore

We have now added the following Roots to the repository:

• Buypass, a Norwegian CA. This CA has been provisionally EV enabled, please see below. Testsites 1, 2, EV.
  
• CNNIC, China Internet Network Information Centre. Testsite. Note: Currently we are missing a HTTP CRL for the intermediate certificate for this site, so the site will unfortunately not show a padlock. We are working with CNNIC to resolve the problem, which may include adding a CRL override.
  
• Secom (a Japanese CA) has issue a new SHA-256 Root, as part of many CAs transition to more secure certificate signatures: Testsite
  

We have also restored the "Verisign International Server CA" intermediate CA certificate, and updated to the most recent version of the certificate, which is valid to 2016. This is a certificate that Opera shipped with until Opera 7.2x in 2004, when that version of the certificate expired, though newer versions of the certificate have been issued and used by servers.

Recently however, the old expired certificate started to cause problems. The old certificate is still present in many Opera profiles which has been updated continously from Opera 7.x or before, and therefore caused certificate verification problems (even for the Opera CEO). We did work around it when problems occurred in the Opera 10.00 beta after we changed the certificate verification procedure in order to update the Verisign G1 Roots to SHA-1.

Even more recently other problems started to appear (though they may have been there for a while), and we discovered that a number of mis-configured sites are still using the old expired certificate. This triggered certificate warnings in all versions of Opera before Opera 10.00. In Opera 10.00 these sites triggered a more severe error message, since the expired certificate is signed with the now insecure MD2 method. This is no longer supported in Opera 10.00, and therefore triggers a certificate signature verification failure which is code "554".

These problems should be fixed at server side by installing the newest certificate. The number of sites with the problem that came to our attention indicates that there are too many sites for us or Verisign to play Whack-a-mole that way. After speaking with Verisign about it, we decided to reintroduce the certificate and now require it in all installations. This certificate will therefore be automatically downloaded to Opera the next time it does its weekly check of the repository, replace existing older installed versions of the certificate, and override the certificates used by web sites.

Additionally a couple of bugs in the backend producing the files on the server have been fixed. These bugs may have caused some problems during the past several months.

We have also noticed a problem with DigiNotar's OCSP responder, and have temporarily added an OCSP override while working with DigiNotar to resolve the problem.

EV enabled CAs:

• Izenpe, a Basque CA added in 2008, was EV enabled a few weeks ago, but the announcement was delayed due to the more significant problem we fixed at the time. Testsite
  
• Buypass is provisionally EV enabled based on their EV Readiness audit (testsite); the full audit is expected by the end of the year. Please note that at the moment Buypass EV will only be indicated in Opera 10.00 and later. The reason is that Buypass is not using intermediate CA certificates to issue EV certificates (nothing wrong with it, but it is the first CA we have seen to do so). This triggered a logical problem with the EV check in Opera 9.50 to 9.64 which has been fixed in Opera 10.00. If Buypass starts issuing EV certificates from intermediate CA certificates, those certificates will also show as EV in Opera 9.50 and later.
  
• Several more Comodo Roots have been EV-enabled. These certificates should have been EV enabled a year ago, but due to an error on our side they were not. We apologize to Comodo for this error. Testsites: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
  
• The EV enabled status of several CAs has been extended after we received their updated audits.
  

As usual, these updates become active and available after the weekly check for updates, but that update can be forced by going to the Opera Toolbar: Help -> Check for updates. The exception is Opera 10.00 where a bug which is fixed in Opera 10.10, and will be fixed in Opera 10.01, disabled the certificate repository updates. A workaround for the problem in Opera 10.00 is to 1) Shut down Opera, 2) delete/rename the file "tasks.xml" in the profile folder, 3) Restart Opera.

The SwissSign Certificate Authority has now been EV enabled. A testsite is available here.

Those who are keeping an eye on what data are available from the certs.opera.com server will notice a new folder at the root, "domains". This folder will contain the data future versions of Opera will use to determine what type of domain a given hostname or domain is, specifically whether it is a normal domain name like opera.com, or a registry-like domain such as co.uk and city.state.us, also known as a "Public Suffix" or "Effective TLD". There are several areas where this type of information is useful, such as cookie domain checking, some Javascript security functionality and UI presentation of web server hostnames to highlight the domain.

We are now starting internal testing of Public Suffixes (not in Opera 10). As our variant of the Public
Suffix support is based on an online update system, as documented in my "subtld" Internet Drafts, a necessary precondition for the testing is a live service providing the data.

The Public Suffix list XML files in Opera's repository is based on (generated from) the list created by the Public Suffix List project managed by Mozilla. Like the original Public Suffix List, Opera's generated XML files are available under the same MPL tri-license (MPL, GPL, LGPL) and unsigned versions of the files can be downloaded as a single archive from from our Public Suffix download location.

You can read more about the Public Suffix List at publicsuffix.org and my articles^1,2.

New Roots

Two new Root Certificates have been added to the Rootstore:

• "Certum Trusted Network CA", from Unizeto/Certum a Polish CA
  
• "Staat der Nederlanden Root CA - G2" from GBO Overheid, the Dutch Government CA
  

Neither of these roots are currently in active use, there are, therefore, not yet any test sites available. The Dutch certificate is, by the way, the second SHA-256 signed certificate in the Opera Rootstore.

EV-enabled Roots

The following CAs are now EV-enabled:

• Digicert. Tests: Homepage and Facebook
  
• Godaddy Tests: Godaddy homepage and Starfield Tech homepage
  
• Trustwave Test: Homepage
  

These CAs have been EV-enabled since February 5th, but this announcement was delayed until now, because we discovered problems with several of them.

This was the first time we EV-enabled Roots that are not shipped by default, and these Roots are cross-signed by another Root (most EV certificate chains are cross-signed by a legacy Root, to avoid verification issues in older clients), and it turned out that, while Opera handles this fine when the cross-signed Root is in the local certificate store, Opera was not able to fetch the missing Root like it should have in these cases.

That bug has been fixed in upcoming versions, and, in the meantime, we have configured the Rootstore to push the three affected Roots out to all older versions of Opera. The announcement delay was due to us having to add new functionality and to make sure that newer versions would not fetch the Roots until they were needed.

As usual, before testing use Help->Check for updates to download the updates, and you should probably restart afterwards to clear any pre-esablished SSL/TLS sessions that might interfere with your testing.

New repository for untrusted certificates

The old online repository of untrusted certificates had a problem because it would immediately push an untrusted certificate out to all installations, instead of each Opera instance only fetching the certificate to double check when it encountered a blacklisted certificate. That action will usually be too severe, unless we are dealing with a compromised Root.

That was a mistake in the original design of the functionality. Given recent developments, it was time to fix that mistake.

In upcoming version of Opera, we will instead only download these blacklisted certificates when we encounter a certificate that matches the one in the repository. The old functionality is still present, but will only be used for severe cases where it is necessary to distribute widely.

OCSP overried removed

For a while now we have been configuring Opera installations to use the HTTP POST method instead of GET for some CAs, because of problems with their servers, which cause Opera to not display sites certified by these CAs as secure. We have now removed these overrides for Entrust and DigiNotar since their servers have been updated.

End of a brief era

When we started testing Extended Validation in Opera 9.50 weekly build 9903/4758/1904, we used a
temporary signing key for the files in the repository. We changed to the permanent signing key in build
10048/4853/2021 .

Support for the temporary key has now been disabled; and if any of them are still in use (they shouldn't be) the alpha and beta builds mentioned will no longer get Root or EV updates.

Today, Verisign (including Thawte and Geotrust), and Comodo were formally EV-enabled in Opera v9.50 and later.

There are no practical effects for Comodo, as their certificate has been provisionally enabled for a few months as part of EV testing. Verisign's Thawte and Geotrust certificates, which were not part of the testing, are EV-enabled as of today.

TestURLs:

• Comodo:
  https://comodocertificationauthority-ev.comodoca.com/
  https://www.sslcertificaten.nl/
  https://secure.comodo.com/example.html
  
• Geotrust: https://www.geotrust.com
  
• Thawte: https://www.thawte.com
  
• Verisign:
  https://www.dnbnor.no/
  https://nettbank.sparebank1.no/
  

As usual, the EV certified Web sites signed by the newly EV-enabled Roots will not show the EV indicator until after the weekly automatic update (on start), or a manual Help->Check Updates (with a restart possibly needed afterwards).

We have several more CAs in the EV pipeline that are expected to be ready within a couple of weeks. Stay tuned.

In this information letter we will cover some recent news relating to the CA Root Store in Opera:

• Opera 9.50's new rootstore
  
• Opera 9.50 certificate revocation checking
  
• EV in Opera
  
• Process for EV-enabling roots
  

Opera 9.50's new rootstore

In Opera 9.50, which was released a few weeks ago, we introduced [URL= http://my.opera.com/yngve/blog/2008/04/08/new-in-kestrel-faster-root-certificate-updates]a new system for distributing Root Certificates to Opera users.

Instead of users having to upgrade their installation in order to be able to use new Roots, they are now able to use the new roots within a week of the root being added to the repository.

This is achieved by storing all Roots in an online repository. Each client will regularly download an up to date list of available Roots from it.

Each installation now ships with only the most frequently used, and it will download and install Roots from the online repository as needed.

The repository index can also indicate that if a user has a particular certificate installed, then Opera should download another certificate as well. This is particularly useful during certificate rollover, and when a cross-signed root is used for Extended Validation.

The benefits of this approach are:

• Quicker time to market for new CAs
  
• Wider availabilty to users "immediately"
  
• No need for users to upgrade their client when new roots are added
  
• Reduced executable footprint for Opera, in particular on phones and devices.
  

All automatically downloaded content in the repository is digitally signed, as well as hosted on a TLS server to secure the system.

Opera 9.50 certificate revocation checking

Opera 9.50 includes two major changes to its revocation checking system: Support for CRLs, and using GET for OCSP instead of POST.

Opera has since version 8.0 supported OCSP for SSL/TLS using the POST retrieval method with a nonce. This method was not very cacheable between sessions, and was not proxy cacheable, and could therefore cause extra load on the CA's OCSP responder.

In Opera 9.50 we have changed to using the GET HTTP method without sending a nonce. This makes it possible for proxies to cache the response, as well as that Opera can more easily cache the response between sessions.

Opera 9.50 also added support for CRLs for SSL/TLS and will now download and cache CRLs for all non-root certificates, except those end certificates identifying an OCSP responder. Selection of CRLs for a verification is done based on the URL identified in the certificate.

If a certificate chain fails either CRL or OCSP verfication (but is not revoked) the associated website will not get a padlock indication, and the security toolbar will not be displayed.

Known issues:

• We have seen several OCSP responder from various vendors that does not correctly implement the GET method for OCSP. The vendor of the most widely responde have located the problem and developed a patch.
  
• If a certificate indicates a CRL that is not signed by the issuer of that certificate then CRL validation will fail, even if the correct CRL is cached.
  
• Some certificate chains have CRLs specified for some certificates in the chain, but not all non-root certificate. In these cases CRL validation will also fail.
  
• We have also seen some cases where the only CRL specified uses LDAP, not HTTP. Opera does not support LDAP, and thus CRL validation will fail.
  

Opera 9.51 have override capabilities for some of these cases, and 9.52 will expand those. To configure those overrides, detailed information about the correct URLs and certificates are needed for the CRLs.

More information about these problems and the workaround are available in this article.

Extended Validation in Opera 9.50

Opera 9.50 for Desktop is the first version of Opera to support Extended Validation (EV).

EV websites are indicated by turning the security toolbar green, instead of yellow as before. In this mode Opera will also display the website's Organization Name from the certificate.

Opera will once a week update information about which Roots are EV-enabled from the same online repository as the Roots are downloaded from.

For a site to get the EV indicator the following requirments must be met:

• All content displayed on the site must be downloaded over strong TLS connections
  
• All revocation checking must succeed.
  
• The EV-enabled Root must use an RSA key that is at least 2048 bits long
  
• Certificates using 1024 bit RSA must expire before Jan 1, 2011 (GMT)
  
• Except for the Root, intermediate certificates must use keys at least as long as the key in the certificate it is used to sign, and if one of the keys are longer than the roots,all of them must be longer. That is, a 2048 bit Root can sign a certificate with a 4096 bit key, but that key can only be used to sign certificates with at most 4096 bits.
  

Process for EV-enabling Roots

To EV-enable a root embedded in Opera a CA must have passed an EV-audit, currently by WebTrust. An authorized copy of this audit must be sent to Opera.

We also require the URLs to a number of sites (test or real) using certificates issued from the Root that is to be EV-enabled. These sites should demonstrate use of all relevant OCSP, CRL and AIA hosting servers so that we can verify that these services interoperate with Opera. Confirmation of this is necessary before a Root can be EV-enabled.

Once the qualification step is passed, EV-enabling require a legal agreement to be signed, and once these steps and the testing has completed, the root will be EV-enabled.

EV-enabling of clients will take about a week from the online repository is updated, until all installations have downloaded the update.

Please note that we have currently received a large number of applications for EV-status, and it will probably take a few months to process all of the applications.

Other changes in Opera 9.50

There are a number of other changes in Opera 9.50 that may be of interest to Certificate Authorities:

• Opera no longer support SSL v2.
  
• Neither does Opera support 40- and 56-bit encryption methods anymore. This also affects import of PKCS #12 files where these methods have been used.
  
• Opera now supports the Authority Information Access (AIA) extension in certificates, and is therfore able to download missing intermediate certificates. Once used to successfully complete a validated chain the intermediate is cached in the intermediate CA certificate store so that the CA's repository server is not overloaded by requests.
  

Other things of note in Opera are:

• Opera gives warnings to the user if a certificate in the chain, or other keys used in the key exchange is shorter than 900 bits for RSA, DH, and DSA.
  
• If those keys are shorter than 1000 bits no warning is displayed, but the "padlock" is not displayed for the site.
  

Both these limits can be adjusted by a preference that Opera Software can adjust via our automatic update system. The next steps on the ladder are 1020, 1100, and 1200 bits, after which both limits will move in steps of 100 bits, and 300 bits apart. Raising the upper boundary to 1020 bit is being considered, and we may raise the boundary to this level before the end of 2009, and while no decision has been made, it is quite possible that this limit will be raised further before 2012, which will affect all 1024 bit roots.

The goal of this system is to inform the user as accuratly as possible about how secure the connection to the server is.