Implementer's notes

For some time now Opera has supported the Certificate Status Request Extension to TLS, although we did have a false start which was fixed in Opera 9.26.

What this extention does is to provide a way for a client to ask the server to do the OCSP revocation check for its own certificate, rather than the client doing a separate connection to the issuer's OCSP responder. The benefit of this policy is that the client saves time completing the connection since it does not have to wait for the OCSP responder. Also, if the server stores the OCSP response for a while, then the traffic to the OCSP responder becomes much lower (and much less expensive). Mostly servers will request updates and not all the clients visiting the site. This is called TLS OCSP stapling.

This mechanism only works for the server's own certificate. It does not work for any of the other certificates in the chain, and these days most Certificate Authorities (CAs) use at least one intermediate certificate, and some use four, or more. Today all the revocation information about these are retrieved using CRLs, not OCSP. This means that the information is not as up-to-date as is possible for OCSP, as CRLs (particularly for intermediates) are valid for much longer periods than OCSP. This may not be an issue today because most intermediates are controlled by the CA or other relatively big CAs, but it could become a problem if CAs start issuing large numbers of intermediate CA certificates that they do not control, for example to corporate customers. This might become a possibility if/when better domain limitations are widely implementated in browsers. If one of those corporate customers or an independent sub-CA starts issuing bad certificates, it is imperative to be able to revoke those CA certifiates quickly, which would be difficult if the CRL was updated every 12 months. On the other hand, OCSP responses are usually valid for less than a week.

Some intermediate CA certificates are now issued with OCSP URLs specified, but no browsers are currently using them. It is my recommendation that they do not start using them. The reason is that for all clients to use OCSP to check intermediate CA certificates would increase traffic to those
servers multifold, perhaps dozens of times when TLS OCSP Stapling becomes widespread, meaning the bandwidth cost for the CA will increase significantly. A number of CAs have already been concerned about the cost of supporting OCSP just for server certificates while waiting for stapling to become widespread; they would not like the cost of supporting OCSP for one or more intermediate certificates.

The solution, of course, is to expand the TLS Extension to support multiple OCSP responses, which should have been a fairly straightforward task, which it was for the handling of the responses. It turned out, however, that it was not practical to use the existing Certificate Status Request extension in TLS, since it does not allow multiple methods to be specified (but only a single method), which would be necessary to support servers that do not support the new response format. The limitation is due to both a hard restriction in TLS, as only one entry for a given extension can be sent in any extension list, and the request extension only permits a single format to be specified, not multiple.

The solution in the end was to create a new extension that permits multiple formats to be specified, not just a single one as before.

I have just submitted an Internet Draft to the IETF TLS Working Group defining such an extension and new response format. The draft is based on the existing definition with enhancements for the new requirements.

I hope the TLS WG will take on the work to help me complete the draft so that we can get this new functionality into all new clients and servers as soon as possible.

Comments intended as contributions to the draft should also be posted at the TLS WG mailing list.

draft-pettersen-tls-ext-multiple-ocsp-00.txt (archive)

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.
  

.

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.