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.

GlobalSign have added a SHA-256 signed Root to the repository. This is a step preparing for a future changover to using SHA-256 when signing certificates. Currently there are no test sites available.

As mentioned earlier when we updated two of their certificates, Verisign have been updating some of their certificates that were signed with MD2 so that they are signed using the more secure SHA-1 method instead. However, there were some problems with the Class 3 (G1) certificate chain as all the intermediate certificates issued by the Root were chaining to the old MD2 Root because they specified the serial number of that certificate. Therefore new replacements for the intermediates had to be issued as well.

Unfortunately, testing showed that at this time it is not practical to update older versions (9.5 and 9.6) to use this Root due to a bug in the certificate verification code (updating the older clients would "break the Web"). This combined with missing functionality in the repository language meant that to be able to use the new Class 3 Root we had to create a new version of the repository ("03") where the "02"-version's shortcomings have been fixed, which will be used by upcoming releases of 10.0. In the upcoming versions of 10.0 MD2 support will be completely disabled. Further down the road when "all" servers have been updated with the new intermediates we may replace the certificates for older clients, too.

The fourth RSA root signed with MD2 (the "RSA Secure Server Certification Authority" Root) is now being replaced in all 9.50+ builds, as it does not have the problems mentioned above. This certificate is also being phased out, so it is not going to remain in the repository for long; it expires early January.

DigiNotar, a Dutch CA added last year, has now been EV-enabled. Test sites can be found here and here.

We have also added new SHA-256 roots for Verisign and its Thawte and Geotrust subsidiaries. These certificates are very new, so there are currently no testcases available.

As part of the migration away from the less secure MD5 and MD2 methods Verisign have also updated their Generation 1 Class 1 and Class 2 Root Certificates to be signed using SHA-1 instead of MD2. These certificates are only used for client certificates, not web sites, and will not usually be installed.

Verisign also updated their G1 Class 3 Root, which is used to sign web site certificates, but we have not included this certificate yet due to problems we discovered while testing it. As Verisign's "RSA Secure Server Certification Authority" Root Certificate is expiring in just a few months (early January), we have decided to not replace it.

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.