Implementer's notes

We have now created a homepage for the Opera Root Certificate repository: The Rootstore.

The Rootstore will be where we announce updates and general information about the root repository.

If you are a Certificate Authority, or generally interested in Opera's certificate store, The Rootstore will be the place to watch.

A few hours ago the new online certificate repository that the most recent weeklies are using was updated with several new roots, and an additional CA, Comodo, was also provisionally EV-enabled

The new and the updated CAs are

• America OnLine
  
• Cisco
  
• Comodo
  
• Digicert
  

There is no need to download an updated Weekly (if you have one of the two recent ones). When you next restart one of the Opera 9.50 Weeklies with support for online certificate updates, it will immediately download the indexes, and download the new certificates when necessary. Please give it a minute to finish the update.

Here are a couple of testsites:

• AOL: https://new.aol.com/ . This site will verify in newer versions, but not in older (Warning about issuer). Known problem: The security level is low due to problems with the CRL (Unsupported format, and currently no plans to support it. The connection will fail in the first build). AOL is aware of the problem, and was already working on updating their CRL system
  
• Comodo EV sites:
  
• https://www.sslcertificaten.nl/
  
• https://comodocertificationauthority-ev.comodoca.com/
  
• https://secure.comodo.com/example.html
  

Known Issues: The complex certificate chain system used by Comodo encounters some, mostly hidden, problems with our OpenSSL certificate verification support, and that will cause some EV sites to not be recognized. We will try to fix it, but it may not be advisable to include a fix in 9.50.
[*] DigiCert:

• https://vpn.osrmedical.com/Citrix/AccessPlatform1/auth/login.aspx In older versions this will validate to an Entrust root (see in the Certificate details view of the security toolbar dialog), after this remote update of 9.50 the root will instead be "Digicert High Assurance".
  
• https://www.iwanttss.com/ In older versions this site will trigger an unknown issuer warning, after this update it will also validate to "Digicert High Assurance"
  

I do not currently have testcases for Cisco, as they have not yet started issuing certificates from the new root.

More about known issues:

• We know there are some problems with OCSP and CRL responses (the two kinds of revocation information) from some Certificate Authorities. These problem may lead to the website getting a lower security level. We are looking into these problems together with the CAs. In last week's build some of the CRL problems will cause a "Fatal Error 50", in the most recent build that has been fixed. We may decide to work around some of these, but they should preferably be fixed by the CA.
  
• At least one CA (who is not in our repository) is using CRLs with a critical extension, which will cause the secure connection to fail with error code 554. In this case we are following the standard, although one might wonder why the specification says "Although the extension is critical, conforming implementations are not required to support this extension". The problem have been "fixed" internally by recognzing the extension, then ignore it, as we do not need it.
  

.

As I posted earlier on Opera Labs, work has been under way to create an improved process, Extended Validation (EV), for issuing web site certificates that can give a higher degree of assurance to the user that the SSL/TLS website in question really is who it claims it is, and how to tell the browsers that this process has been used.

Last week, after two years of work, the members of the CA/Browser Forum, a group consisting of many Certificate issuers (for example, Verisign, Comodo, and Entrust) and browser vendors (KDE, Microsoft, Mozilla, Opera), voted to approve Version 1.0 of the Extended Validation Guidelines.

These guidelines describe which steps a CA issuer must (at least) take in order to validate that the information given is correct, such as confirming the legal existence of a business or government agency, ownership of a domain, authorization to request a certificate, etc. Compliance with the guidelines is verified by regular independent audits.

This version of the guidelines also address certain concerns about what kind of businesses are eligible to get EV certificates.

When the certificate is issued, and installed on the server, a browser supporting EV will not just verify the signature on the certificate, it will also:

• Verify that the certificate is still valid, and has not been revoked because of some problem [link to revocation article],
  
• Check for the presence of one of the CA's EV policy indicators (EV-OIDs) in the
  certificate.
  

If all of this is OK, then the browser will display a visible indicator to the user that the certificate for the site has been issued in accordance with the guidelines. The indicator agreed upon by the browser vendors is a green security toolbar beside the address field, perhaps with a couple of other embellishments.

EV certificates have been issued for a few months based on a preliminary version of the guidelines, and have been recognized by IE7.

No public version of Opera currently supports EV, although we built a demo version with rudimentary EV support last year. Work is going on to produce a full version that supports EV, and we are planning to include support in "Kestrel".

Work in the CA/B Forum is by no means at an end, there are a number of other areas that need similar functionality as that provided by EV to SSL/TLS, as well as possible improvements of the current guidelines.

Stay tuned.

A few months ago I investigated a bugreport about a secure travel agency website that was causing Opera to display the omnious message "The certificate has been revoked by its issuer. The certificate was revoked because this site is no longer in operation". (Well, actually, due to a bug Opera 9.0 only displayed a less informative message and not that particular message, but 9.01 would have.)

What is recovation, and why is it important to you?

About revocation

Revocation of a certificate means that the Certificate Authority (CA) that issued the certificate for a website have decided that the certificate is no longer valid, even if it has not expired.

The information about revocation can be distributed in two ways: Certificate Revocation Lists (CRLs), or by using the Online Certificate Status Protocol (OCSP).

CRLs are (usually) large files that contain a list with information about all the currentely active (unexpired) certificates that are no longer valid. This file has to be downloaded from the CA by the client at regular intervals (usually at least a week apart), and may be quite large.

OCSP, on the other hand, means that the client asks the CA "Is this particular certificate still valid?", and the server responds "Yes" or "No". This method can usually be fairly well up to date, meaning the information is at most a few days old, as opposed to at least a week for CRLs.

All the major browsers support OCSP, but some (like Opera) does not currently support CRLs.

At present Opera is the only non-beta browser that has enabled revocation checking by default, but IE7 for Vista will also check revocation by default. I am unsure about the status of the other browsers, but if they have not already done so, it is only a question of time before they all enable at least OCSP by default.

Possible reasons for revocation

Why is revocation important enough that we actually stop the user from visiting a website?

A CA can revoke a certificate due to a number of reasons:

• A new certificate has been issued to the website, meaning the old one is not going to be used anymore.
  
• The website with the certificate is being used for purposes that are not accepted by the CA.
  
• The certificate was issued based on incorrect information.
  
• The owner is no longer able to use the private key associated with the certificate, for example the password is lost, the key storage was destroyed somehow, etc.
  
• The private key has been compromised or stolen, which means traffic to the site is no longer secure.
  
• The certificate and key have been stolen and is actually being used for fraud while posing as a legitimate website.
  

In the case I was investigating the revocation reason given by the CA was "The certificate was revoked because this site is no longer in operation". To all appearances this looked incorrect, after all the website was there, other browsers accessed it, and it was possible to order from it.

However, as mentioned above, the reason other browsers accessed the site was that, unlike Opera, they did not check the certificate status. Users of other browsers that have manually changed the OCSP and/or CRL settings would also have been barred from accessing the site.

Given this situation there were several possibilities:

• Somebody at the website development team had made a mistake, either revoking the certificate by accident or forgetting to update the certificate on the server, after all, it still worked in every browser they used. (According to my information, the revocation was requested by the website owner.)
  
• The company had indeed gone out of business, but somebody forgot to turn off the lights (and the servers) when everybody left. In such a case people ordering their vacation might have gotten a rather "exciting" start of their vacation when they found out payment had not been made to their hotel or airline. I'm pretty sure some lawyers would have found the aftermath interesting, if this had been the case.
  
• The website's private key had been stolen, and the perpetrator was able to update the DNS entries or the network so that they could host their own completely "valid" secure server and use it to commit fraud and to steal credit card information from unsuspecting customers.
  

Especially the latter possibility sounds scary, doesn't it?

What was really going on?

What all this means is that Opera 8 and 9 refused access to the site, because we checked the current status of the certificate, while most other clients were quite oblivious to the situation because they did not, by default, check the certificate's status.

As I usually do in such cases I informed the CA about the problem. Naturally, they cannot share much information with me, but telling them gives them an idea about how many active websites are actually using revoked certificates (There aren't that many; we encounter at most one or two each month).

Then I tried to get in contact with the website owners so that I could ask them to update the certificate, but that proved to be a bit more difficult than I expected. There was little or no contact information on the site for contacting the webmaster, the only contact method was a comment form, which I filled out and submitted.

Then I started investigating a bit more, and found the parent company and tried sending them an email too, and then the grandparent company. Unfortunately, there were no results to show for the effort.

A couple of days later I recruited a colleague to help get in contact with the grandparent company, because he speaks the language. After several phone calls, more emails, faxes, and being redirected from one person to another, a couple of days later we finally established contact with the travel agency, and within hours a new certificate was in place.

It turned out that the company owning the website had reorganized and changed its name or established a new company to handle the website. During this process all the old certificates had been canceled, but new ones had not been installed.

In other words: Nothing more sinister than a human mistake. Fortunately.

This incident does however highlight what is becoming more and more of a problem, in particular for major websites (just ask David Storey, our Web Opener): Not being able to report serious website problems in a timely manner to somebody that can do something about it. There may be a contact form on the site, but at least in this case it did not have any choice for "website problem", meaning I had to file it in another category which could mean it could be lost somewhere in the system.

Forunately, as more clients enable revocation checking, this problem will diminish, at least for legitimate sites, as they will find out very quickly that they have a problem.

So what should you do if you encounter a revoked site?

First: Don't open a different browser to continue your transaction, provided it will let you. Revocation means you cannot trust the site.

Second: Tell the website operator that they have a problem.

Third: While you wait, shop somewhere else.