The Opera Rootstore

The Roots of Internet trust

Subscribe to RSS feed

Posts tagged with "SSL"

Sticky post

Introducing the Opera Rootstore

By Yngve Nysæter Pettersenyngve. Thursday, July 3, 2008 3:23:56 PM

, , , ...

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.

5 comments

DigiNotar Second Step: Blacklisting the Root

By Yngve Nysæter Pettersenyngve. Thursday, September 8, 2011 6:56:46 PM

, , , ...

A few days ago we removed the DigiNotar Root from our list of trusted Certificate Authorities, for the reasons mentioned in our announcement. Today, continuing our process of securing our users by revoking the DigiNotar Root, we add it to the list of untrusted certificates.

How we actually implement this revocation is probably going to surprise many readers.

The first part of the revocation -- adding the DigiNotar Root to our untrusted certificate repository -- is as you would expect.

However, during testing we discovered a minor problem. The entry in the untrusted repository worked, when the installation had the DigiNotar Root installed, as it would for somebody that had visited a site issued from that Root. On the other hand, it did not work as intended when the Root was not installed, in those cases it only triggered an "Unknown Issuer" dialog.

There are two reasons for this difference:

  • First, the fact that most secure sites do not send the Root CA certificate to the client when the connection is being negotiated (This is allowed if the server expects the Root to be known to the clients)
  • Second, the untrusted repository matches a certificate based on the combination of its Subject Name and Public Key, and the Public Key is not known until the certificate containing it is has been processed.


Since the Root Certificate is no longer known by the client this means that there is no certificate that can we can search for in the list of untrusted certificates. Therefore, the site certificate is allowed to pass through to display the "Unknown issuer" dialog.

This problem is due to limitations in how the untrusted functionality was designed and implemented, and we are investigating how to remove this limitation in a future version.

In most cases, this would be sufficient protection. Unfortunately, in this case we are dealing with a CA hierarchy that has been compromised to a degree never seen before, and we cannot allow the risk that a user may accidentally click through one of the warning dialogs.

Thus, the problem with the incomplete chains had to be solved, and the easiest way to do that, while we are working on a more permanent fix, is to ensure that the certificate chain for a DigiNotar issued certificates is complete, with the Root. This is accomplished, in addition to the above blacklisting, by re-inserting the DigiNotar Root back into the certificate repository, but this time the entry is marked with the "Deny access to sites presenting this certificate"-flag, meaning that it cannot be used for SSL/TLS websites. Combined with the untrusted repository entry, this ensures that all "DigiNotar Root CA" issued certificates are blocked.

To users, this will work out as follows:

  • Users that never have visited, and never will visit a site with a DigiNotar certificate will never see this certificate, or the untrusted repository entry.
  • For users that have previously visited a site with a DigiNotar certificate there will be no change in the Authorities listing; the DigiNotar Root entry will remain unchanged. Should one of these users visit such a site again, the untrusted repository entry will cause Opera to block access to the site.
  • For users that have not previously visited a site with a DigiNotar certificate, but at some time visit such a site, the DigiNotar Root will be downloaded and installed in the Authorities repository, but, as mentioned above, with a flag that blocks the access, in addition to the untrusted repository entry that will be used to block access to the site.


The visible result of the website blocking varies a little in various versions of Opera. In older versions an error page with error code "49" will be displayed. In newer versions, due to a bug, a blank page will appear instead. A blank page still provides effective protection, however, we plan to fix the bug in future Opera releases, so that it displays an error page instead.


Getting the update

For desktop users no action is needed, strictly speaking, as the update will be automatically downloaded and configured during the next week. If you would like to get the update immediately, you may do so using the menu option Help > Check for Updates, which will trigger the update.

Users of Opera for Mobile 11.10 (except for Symbian/Nokia, see below) will get the update automatically within the next week. The update can be triggered manually by opening opera:config , search for "Time Of Last Root Certificate Update Check", setting this value to 0, and restarting Opera Mobile. Users of older versions will need to update to version 11.10.

Opera Mobile for the Symbian/Nokia platform does not use Opera's certificate repository, but instead uses Symbian/Nokia's repository, so Symbian/Nokia is responsible for providing any updates for this issue, if an update is needed. According to our testing it does not appear that the Symbian/Nokia repository contain the DigiNotar Root.

Opera Mini will be updated separately, and no action will be needed by users of Opera Mini.

4 comments

DigiNotar First Step: Disabling the Root

By Yngve Nysæter Pettersenyngve. Tuesday, September 6, 2011 7:45:29 PM

, , , ...

There is a first time for many things. Sometimes this is positive, but other times it is unfortunate. This time, we're dealing with one of the latter variety.

Today, we have updated the Opera Rootstore and disabled the DigiNotar Root (Note: DigiNotar is not in any way associated with DigiCert, which is another CA).

The reason for this action is due to last week's news about the large scale attack on DigiNotar's CA systems and the subsequent discoveries about what has happened after the attack.

This is the first step in our handling of this incident. We are currently testing further updates that will add the DigiNotar Root to our "Untrusted" repository.

That a CA gets attacked and even tricked into issuing certificates that turn out to be fraudulent is not, by itself, a reason to revoke trust in a Root CA. CAs are high profile targets for criminals given the role CAs have in the online security framework; it is how the CA responds to such events that determine how much we can trust it.

In this case, DigiNotar's response has unfortunately fallen short in many respects, including the following:

  • They did not inform the affected websites, the browsers or the CABForum (CA/Browser Forum) about what had happened for more than 5 weeks, and they only did so after one of the certificates turned up being used in a MITM attack against Google websites. This can be compared against the fact that the browsers were informed about the (successful) attack on Comodo, as well as the (unsuccessful) attack on Startcom, within a few days of the events.
  • While they did revoke a number of certificates that were fraudulently issued, they did not inform the affected websites, and they did not discover that a certificate for Google's domain had been issued until after Google had learned of the certificate from users being actively attacked with it (a discovery made possible by a recent Chrome security measure implemented for Google's sites) and informed DigiNotar and the browsers about it.
  • The reason for the delay in discovering this certificate was that the attackers had tampered with the log information in the certificate issuance system for at least one of the subCAs. It is presently unknown whether the attackers also tampered with the logs for the other subCAs.
  • Due to the log problems, it is in fact still unknown how many certificates that were really issued by this system or for what websites! We have seen reports that more than 500 certificates were issued during the attack, with less than 300 being positively identified, according to our information.


For these reasons, we are today discontinuing distribution of DigiNotar's Root.

A couple of points to note:


  • No user action is needed to get this update. If your installation does not have the DigiNotar Root installed already, visiting a site with a DigiNotar issued certificate will trigger a "Unknown issuer" dialog; if this happens, click "Reject" on the dialog.
  • This first step of our planned revocation does not remove, or untrust, the DigiNotar Root from Opera installations that already have the Root installed. For these installations, sites using DigiNotar certificates will continue to work as before, indicating a secure connection, as will the EV-enabling of the Root until the next weekly download from the repository server (using the menu choice Help->Check for Updates will trigger an immediate update). For advanced users: if your installation has this certificate, and you want to untrust it now, you can do so by following these steps:


  1. Go to the Root Certificate Management dialog in the Menu->Setting->Preferences->Advanced
    Preferences->Advanced->Security->Manage Certificate->Authorities.
  2. Locate the "DigiNotar Root CA" entry and click "View".
  3. Uncheck the "Allow connections to sites using this certificate".
  4. Click "OK" on the viewer dialog, the Certificate Manager and the preference dialog.
  5. The DigiNotar certificate is now untrusted, and visiting sites issued from the Root will cause Opera to refuse to connect to the site, without displaying a certificate warning.


Please note that this action does not affect the Dutch Government CA "PKI Overheid" Root CA, which is in the process of revoking the subCA certificate they issued to DigiNotar.

In relation to these events, the browsers and the Certificate Authorities in the CABForum are monitoring the situation and are discussing further improvements to how certificates for secure websites work, both in browsers and on the CA side.


Update Sep 8: Second stage deployed.

11 comments

Public review period of new certificate issuance baseline requirements

By Yngve Nysæter Pettersenyngve. Tuesday, April 12, 2011 6:26:16 PM

, , , ...

A few years ago, the CAB Forum (CA/Browser Forum, of which Opera is a member) published the Extended Validation (EV) Guidelines. This specification raised and set the bar high for how the identity and operational existence of websites should be assured, which had not been properly standardized until that time.

Now the time has come to set the lower bar that all certificates need to be able to pass, when they are issued by Certificate Authorities pre-shipped as trusted by browsers.

For the past couple of years, the CAB Forum has been working on the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" document, to define where that lower bar should be placed.

Today, the current draft (PDF) of this specification is being released (PDF) for a public 45-day review period, before the CAB Forum finishes version 1.0 and its members vote on adopting it.

The CAB Forum is looking for constructive input on potential improvements of the specification. This input does not need to be restricted to what is in scope for version 1.0, but also might include suggestions for improvements that could be included in future updates of the specification.


CA and browser members of the CAB Forum acknowledge that the current version lacks provisions in some key areas, and they anticipate working in the coming months to overcome these deficiencies. Nevertheless, they see great value in adopting and enforcing an initial version covering those areas where agreement has already been achieved. For this reason, the CAB Forum welcomes well-thought-out, constructive improvements to the current draft. Proposals for more far-reaching changes will be considered. However, proposals that may significantly hold-up the adoption of common requirements for the industry must await a future revision.

According to a spokesperson for the CAB Forum, "Representatives of the major browser suppliers and Internet certification authorities have long recognized the need to establish and enforce common standards for assurance across the industry. The current draft of the Baseline Requirements represents an initial step in that direction. We welcome input from others with expertise to share. And we expect to continue to enhance these requirements as the threat landscape evolves."



It is Opera Software's intention to start requiring all CAs embedded in its Rootstore to implement these new requirements when they become active, and to be audited according to the updated ETSI and WebTrust auditing standards that will be based on this new specification.

You are welcome to discuss this draft here in the comments, as well as in the My Opera Community's Security and Privacy forum (Please use the framework laid out in the press release (PDF).) If you have specific suggestions for improvements, please submit them to the CAB Forum via the two official channels for comments on this review, questions@cabforum.org and Mozilla's dev-security-policy mailing list (Google mirror). The Mozilla list is also where members of the CAB Forum will be participating in the discussion.

You can download the PDF of the draft here


3 comments

New CNNIC EV Root, pubsuffix update, and some blacklisted certificates

By Yngve Nysæter Pettersenyngve. Thursday, March 31, 2011 6:32:21 PM

, , , ...

Today, we have updated the Rootstore with the following:

  • CNNIC, the Chinese Registrar and CA have been EV enabled. As
    part of this, a new EV-enabled Root was added (the old is not EV-enabled). Testsite
  • An update of the Public Suffix list, adding the suffixes gob.ec
    and bv.nl. Version 1.5 is available for download from our source repository.


Additionally, the "major" update is due to the recent attack on the CA Comodo1,2, where an attacker was able to hack into an account and trigger the issuance of 9 certificates for major communication sites (a few other accounts have apparently also been compromised, though no certificates have been issued from these accounts according to our information). Rumors are flying about who was behind the attack, and why, but I will let those rest.

We learned of the attack late evening March 16th, and, by then, the issued certificates had already been revoked by Comodo for more than 24 hours (Comodo detected the attack within a few hours).

I evaluated whether to update the Rootstore Untrusted list of certificates with those certificate already that week, but decided not to do so at the time, in particular since Opera's blacklist could not blunt any attack within the 2 days remaining of the pre-revocation OCSP response validity, and there had been no accesses for the revocation information in the open window.

Also, after the (possible) pre-revocation OCSP responses had expired, any attempt to block revocation checking would remove the secure indication of the site when loaded by Opera, so any users that are keeping an eye on the padlock (we know that a lot you do) would be protected, so after that time the certificates could not in any way have been used to flag pages as secure in Opera.

Another consideration is that the Untrusted list is not intended to be an extra revocation list for normal certificates; it is only intended to include problematic certificates that cannot be revoked in any other fashion, such as the MD5 collision cert a few years ago or a renegade Root CA.

Adding fraudulently issued certificates is not among the list's intended uses, except in special situations. The reason is that revoking those certificates is what the revocation lists (CRLs and OCSP) are for.

At present, however, we have a situation where it is not practical to refuse access to a secure site because the browser cannot access up-to-date revocation information, particularly since the responders have occasional momentary down periods. Opera removes the padlock if we can't get the revocation information, as far as I know Chrome puts a (Golden? Shouldn't that have been red?) warning triangle over the padlock, others give no indication at all that there was a problem.

In the aftermath of the Comodo incident, several participants in the discussion, including me, have suggested that we should move towards stricter requirements regarding having revocation information available before allowing a secure connection to complete.

There are several downsides to this, particularly that it requires exceedingly high stability for the revocation servers, and there is also an implied requirement that all browsers need to do this policy change at the same time, to provide the same user experience.

The stability requirement can be worked around by requiring secure servers to implement TLS OCSP stapling, an extension to the TLS protocol where the TLS server caches its own OCSP response and sends it to the client when it connects. This saves the extra roundtrip for the client when it retrieves it directly, and provides an up-to-date status. There are two problems at present: 1) only 3% of servers support the extension and 2) to be truly useful, all the revocation info for all the certificates in the server's chain needs to be included, and that is currently not possible; but I have submitted a proposal to the TLS WG that would allow that (although there are some concerns that the extra data will cause performance issues for big sites).

In the meantime, using a blacklist may be the best option for limiting impact, but it is also an option that does not scale in the long run, and it also has a relatively long deployment time, compared with revocation. Excluding time for users to update, it took the browsers that shipped blacklist updates last week a week to ship their updates, and that was probably achieved by pushing their release cycles to the limit. Even this Rootstore update took a week to prepare.

In this case we have decided to follow the other browsers, and update our Untrusted list with these certificates, and we might continue to do so in the short term, should there be more incidents, but in the long term other solutions will have to be found.

The are some things to note, even though I hope none of you will ever encounter any of these certificates in the wild:

  • Only 7 of the 9 certificates are included, due to the ID of two certificates colliding with a third certificate; the ID is based on the certificate's subject name and public key. This problem is due to a design error in the repository handling; plans are under way to fix the problem.
  • The blocked certificates are only pushed to Opera 9.5x and 9.6x versions, since they are not able to use the newer dynamic system. The above point means that two certificates are not installed in those version and are not blocked. In all other versions, there is no visible indication of the list having been updated.
  • In newer versions the blocked certificates are only downloaded if they are ever needed. If the download fails, the certificate will still be blocked, which also means that the two certificates not in the list will actually be blocked anyway.
  • In Opera 10.x before 10.50, the certificates will be blocked in the way the functionality was designed, by displaying a message that the certificate is untrusted.
  • In Opera 10.50 and later, including 11.10, there is a bug. While the blocking works, it works by either showing a blank page or a "Could not connect" message. We are looking into this.
  • If the blocked certificates are ever encountered, by Opera 10.0 or later, revocation is checked first, and only if the certificate is not revoked (or the information could not be retrieved) will the untrusted list be consulted.


This update will propagate to all Opera versions that support the online Rootstore during the next week; if you are impatient, just use Menu->Help->"Check for updates" to fetch it (The CNNIC EV-site mentioned above can be used to test that you got the update).

Summary: Opera users who consult the security indication could not have been tricked into believing a site with the fraudulent certificates was secure once the Comodo revocation lists became authoritative, the addition to the blacklist is an extra security measure that strictly speaking is not necessary. No action is needed by our users to download this update.

4 comments

EV-enabled Startcom and Trustcenter, updated Public Suffix list to v1.3

By Yngve Nysæter Pettersenyngve. Thursday, December 9, 2010 4:02:50 PM

, , , ...

New EV-enabled CAs

The Rootstore repository has been updated with two CAs being EV-enabled:



The reason there is a specific 11.00 test site for Startcom is that, up until now, Opera has implemented a restriction on the relative key sizes for the certificates in an EV certificate chain. The rule was that an intermediate CA certificate had to use a key that had at least as many bits as the key being signed.

The primary reason for this rule was to make the CA keys a harder target than the web site's key, but unfortunately this policy have caused some issues in the past, including the Startcom site, and we are now removing the policy as of Opera 11.00.1133. Earlier versions of Opera will, for example, not display Startcom's page as having an EV certificate, while Opera 11 now will do so.


Public Suffix v1.3

We recently discovered that we had lagged behind the current state of Mozilla's Public Suffix List. The reason turned out to be that the URL for the changelog RSS feed I had originally subscribed to had changed.

This new update contain adjustments to many TLDs, as well as adding initial entires for a number of new internationalized (IDN) TLDs such as for China, Egypt and Russia.

As usual, an unsigned version is available from our source repository.

2 comments

New Roots, new EV, and a new Public Suffix file

By Yngve Nysæter Pettersenyngve. Wednesday, July 28, 2010 10:43:39 PM

, , , ...

The Opera Rootstore has been updated with several new Roots, a new CA has been EV-enabled, and a new file has been added to the Public Suffix repository.


Extended Validation:



New Roots:

  • AffirmTrust: This is a new US-based CA, headed by people that worked at Geotrust before it was acquired by Verisign. Test sites: 1, 2, 3
  • GoDaddy: This popular US ISP and CA has added 3 new EV-enabled Roots signed using SHA-256, a more secure signature method. Test sites: 1, 2, 3
  • Taiwan CA (TWCA): This a CA is based in Taiwan. Test site
  • TrustCenter: This is a German CA that has been in Opera for a while. They have created two new Roots to take over when some of their
    older certificates expire in January 2011. Test sites are not yet
    available (this article will be updated when they are)     Testsites: CA-1 and CA-3.
  • StartCom/StartSSL : This is a CA based in Israel which has gathered
    a following. We received quite a few requests to include it, and the wait
    is now over. Test site


AffirmTrust, GoDaddy and Taiwan CA were all added at the end of April, but due to problems with some of the test cases this announcement was delayed.


Public Suffix

  • To improve performance for the Public Suffix handling in upcoming versions, we have created a new file that collects all the specifications into a single file. This does not affect the existing files. The updated distribution (Mozilla Tri-License) version 1.2 is also available from our repository.


The new file is "all.tlds.xml", and it contains a "<tlds>..</tlds>" element containing multiple "<tld>..</tld>" elements. The draft describing the format has not yet been updated with this addition.

8 comments

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

By Yngve Nysæter Pettersenyngve. Wednesday, September 30, 2009 1:39:26 PM

, , , ...

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.

[Update Jan 14, 2010: Secom's testurl has been updated with a new URL]

3 comments

GlobalSign SHA-256, Verisign roots, new repository version

By Yngve Nysæter Pettersenyngve. Friday, July 31, 2009 12:51:25 PM

, , , ...

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.

3 comments

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

By Yngve Nysæter Pettersenyngve. Wednesday, February 18, 2009 5:30:37 PM

, , , ...

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.

6 comments

1 2 Next »