Skip navigation.

The Opera Rootstore

The Roots of Internet trust

Posts tagged with "Opera browser"

STICKY POST

Introducing the Opera Rootstore

, , , ...

Welcome to the new home page of the Opera Root Certificate Store.

Root Certificates are used in several security areas to get assurance of identity, by establishing a relationship between the control of the private key associated with the public key in a certificate signed by the Root Certificate, and the entity identified by the certificate. The keypair can then be used to establish various forms of secure communication with that party, such as digital signatures and encrypted connections.

The area where certificates are most widely used is to set up and secure SSL/TLS connections, for example, to secure your online banking transactions and online shopping.

To use certificates signed by a Root properly, the application needs a copy of the Root provided by the owner of the Root via a different route than from the web site presenting the certificate, so that we can be assured that the Root is the real Root, and not a look-alike.

That is why we have the Rootstore database. The Rootstore is where we store the list of Roots that are either pre-checked by us and shipped with Opera, or installed by the user.

In Opera 9.50 we changed the design of the Rootstore. In the new system, only the most frequently used Roots are shipped with the Opera executable, while the other Roots are stored in our online root repository at https://certs.opera.com/ and will be automatically downloaded and installed, as needed.

"The Rootstore" home page will be where we will announce all updates of the online Root repository, as well as other public information about this part of the Opera browser.

If you represent a CA that wants to have its certificate added to Opera's rootstore, please see http://www.opera.com/docs/ca/ for information about the procedure.

Additional EV-OID for Izenpe, untrusted certificates, and public suffix update

, , , ...

The Basque CA Izenpe (EV-enabled in September) is preparing a new line of EV certificates to be used by Spanish government web sites. These new certificates are mandatory for all the public administrations according to the 11/2007 law. Currently, only Izenpe is able to issue these certificates as EV because Izenpe is the only Spanish CA certified to issue EV certs. Izenpe have designated an extra EV-OID for this line of certificates. This new OID has now been added to the list of OIDs recognized for the Izenpe EV Root. This is the first time a CA has had two EV-OIDs enabled for the same Root in Opera. A testsite is available

We have also added a few certificates to the list of untrusted certificates.

* Two of these certificates leveraged differences (related to handling of NUL bytes) in the processing of hostnames between a CA's domain name checking systems and some browsers to trick the CA into thinking it was validating a certificate for www.mybank.com<nul>.www.example.com, while the browser would think the certificate was for another site, www.mybank.com, which could facilitate a Man-In-The-Middle attack on the user. While the issuing CA has revoked these certificates we are taking the extra precaution of adding the certificates to the list of untrusted certificates. Therefore, they will not accidentally be accepted by users if the revocation system fails. Both CAs and browsers have been fixing the related issues, and Opera included fixes for this issue in Opera 10.00.

* Additionally, in preparation for future code changes in Opera Presto 2.4, and just to be on the safe side, we have added two object signing certificates that were issued in 2001 to someone pretending to act on behalf of Microsoft. While these certificates have long since expired, the possibility exists that they could still be used maliciously.

These certificates are only downloaded and installed in the untrusted repository when they are actually encountered.

In version 1.1 of the Opera Public Suffix list we have added the domain operaunite.com as a public suffix domain. We have also submitted a patch request to the Public Suffix project and to Microsoft for inclusion of the domain in their lists. The updated version is available from our repository.

Secom, CNNIC, Buypass Root, Izenpe EV-enabled, and more

, , , ...

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.

Temporarily missing EV indication with Verisign EV certificates

, , , ...

Due to an unfortunate misunderstanding, Opera had not received an updated EV audit from Verisign in time for the latest rootstore update. As a result, our automatic system reverted to showing a yellow bar instead of a green bar on sites with EV certificates signed by Verisign, Thawte and Geotrust.

We have in the meantime received a currently valid EV audit. The update took effect Sep 3rd 1900 UTC, and the sites in question will start displaying the green EV bar again after the next time the browser contacts our server. This takes place on a weekly basis.

Users can rest assured that this does not signify any reduced trustworthiness for the sites in question, their certificates remain valid and are recognized by Opera. It is only the additional EV indication that will be off until the next time the browser downloads certificate information from our servers.

Unfortunately, there is a minor bug in the newly released Opera 10 that prevents the user from forcing a manual update of the rootstore in this version. This will be fixed in a maintenance build. A workaround for users that want an immediate update is to shut down Opera and delete/rename the file "tasks.xml" in the profile folder and then restart Opera.

GlobalSign SHA-256, Verisign roots, new repository version

, , , ...

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.

SwissSign EV-enabled and a Public Suffix List

, , , ...

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 articles1,2.

DigiNotar EV-enabled and new Verisign Roots

, , , ...

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.

SECOM EV-enabled

, , , ...

SECOM, a japanese CA has now been EV-enabled. Test URL

As usual, you may have to restart Opera for the update to take effect.

New Roots, EV-enabling, and more. Plus, the end of a brief era

, , , ...

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:



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.

QuoVadis EV enabled + CRL override

, , , ...

The CA QuoVadis has now been EV enabled. Test URL

Also, we have now added a CRL override URL for the Telia/Sonera Root we had problems with.

As usual, you may have to restart Opera for the update to take effect.

This update has been active since November 14, the announcement have been delayed due to traveling.