Skip navigation.

Implementer's notes

What might get caught in the gears under the hood?

Posts tagged with "Extended Validation"

Extended Validation Update

, , , ...

Today we have formally EV-enabled the first two CAs.

For more information, please see The Rootstore's announcement

Lowering the EV bar

, , , ...

Last week at the W3C's Web Security Context Working Group's meeting at Opera HQ here in Oslo we discussed what should be the criteria for displaying the Extended Validation (EV) indicator, or the Augmented Assurance (AA) indicator, as the WG has decided to call this technology.

As I have said earlier, we are of the opinion that the EV indicator should not be displayed unless all content is loaded from EV servers.

The opposing view is that, so long as all content is loaded over secure connections, the displayed document is what the author of the main document intended (bugs, vulnerabilities, and all), and that it is therefore only necessary to verify that the main document is served from an EV server, as this will provide the information necessary to identify the author.

The decision of the WG was in favour of the less restrictive position: if an AA/EV document loads all resources over strongly TLS-protected connections, then the document can be displayed with an AA/EV indicator.

In the interest of providing a common user experience with respect to EV we have decided to follow this recommendation, and today's Kestrel snapshot include this policy change.

We have, however, left the old logic in place, controlled by a preference that can be updated remotely. This permits us to quickly change to a stricter mode if the consensus about what constitutes an AA/EV site changes in the future.

As a consequence of this policy change a large number of sites, such as Paypal, with mixed EV and non-EV content will now get the "Green Bar" in Opera:

More testing: Updated EV information and new Roots

, , , ...

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:


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:


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.
.

New in Kestrel: End of the Extended (Validation) wait

, , , ...

Today we're releasing the first Kestrel Weekly with Extended Validation (EV) support.

As I've written before, Extended Validation is a new way to indicate, in a Web site certificate, that the identity of the company behind the Web site has been verified according to a rigorous standard. The guidelines for this process is defined by the CA/Browser forum, which is a group consisting of many certificate issuers (CAs), browser vendors, and others.

We are now ready to start public alpha testing.

So, how does it work?

When a Web site is recognized as an EV site, Opera will change the background color of the security toolbar to green, instead of yellow as it is for normal secure Web sites. There will be a few further adjustments done in this area, the most major being that we have stopped displaying the Organization Name field and country in the security toolbar for non-EV sites, because this name might not have been properly verified for non-EV certificates.


What is required to be permitted to issue EV certificates?

Root CAs that want to issue EV certificates must first pass a rigorous audit to prove that they have the proper procedures in place to identify accurately the company requesting a certificate, and that this company is in control of the given server. Further, an agreement between the Root CA and the browser vendor is required before the browser can recognize the CA's certificates as EV certificates.

How does Opera know it is an EV certificate?

All EV certificates contain an identifier (called an EV-OID, actually a Certificate Policy identifier). The CA will insert this identifier when it has verified all the information. Only certificates issued from specific Roots are allowed to use these identifiers.

How does Opera know that a Root is allowed to issue EV certificates?

Each Opera instance will regularly download a digitally-signed list identifying the CA, its certificate, and which EV-OID(s) it is permitted to use (different CAs can use different EV-OIDs). When Opera verifies a certificate issued from this Root, it will "sift" through the data where the EV-OIDs are stored to see if it contains one of the EV-OIDs recognized for this Root. If such an EV-OID is present, Opera will proceed to check if the other requirements (see below) for saying the Web site is an EV site are fulfilled.

What is required by a Web site to be considered an EV site?

The primary requirement is, of course, that it is eligible to get an EV certificate, and that it has purchased and installed one. The certificate, and all the intermediate certificates must (of course) still be valid, and cannot have been revoked by the issuer (we now check both OCSP and CRLs). Further, there must be no problems verifying the certificate; that is, there must be no unknown issuers, no mismatch of server name, and no weak encryption.

There are also a couple of specific encryption key requirements: The Web site's key should (for RSA) be at least 2048 bits long, but non-root certificates which expire before 23:59:59 UTC/GMT December 31, 2010 MAY use RSA keys of at least 1024 bits. Except for the Root key, which (for RSA) must be at least 2048 bit long, all signing keys must be at least as long as the key of the certificate it is used to sign.

And lastly, if the Web site includes content from other Web servers, those servers must *also* be hosting EV-sites. This is a point at which we are much stricter than the other EV-capable browsers currently. As I said earlier: "It ain't EV 'til it is EV, all EV".

The reason for this requirement is that these other servers may provide content that directly controls the appearance of the entire site, either through frames or external Ecmascript embedded in the page (and the latter has full control of the site's content).

Considering how many click-wrap licensed Web services (such as for Web statistics) there are, it is not likely that the Web designers signing their sites up for these services will have done anything close to good-enough legal identity check of the service. Also, don't forget all the liability disclaimers such contracts include. It is impossible to check the contracts, but we can check that the sites have been able to get an EV certificate.

EV is intended to give you better information about who provided the content with which you are viewing and interacting. If not all the servers providing the content are providing this kind of information, do you really know who provided the important part of the content? Our answer is that you don't, therefore such sites, which at the moment include Paypal.com, will not get the EV indication unless they either remove all references to the non-EV content, or those providers upgrade to provide EV content, as well.

Which Root CAs are currently recognized as issuing EV certificates?

During the test period starting with this release we have provisonally configured three Roots as EV Roots (in alphabetic order)

  • Entrust's EV Root
  • GlobalSign's EV Root
  • VeriSign's G5 Class 3 (EV) Root

Other CAs and Roots may be added later.

About the online repository

As mentioned above, Opera retrieves information about which CAs are recognized as EV-issuers from an online repository. This repository, hosted at https://certs.opera.com/, contains a digitally-signed file listing all the EV issuers and a (separately) signed list of the EV-OIDs they are using.

This repository is refreshed every 6 hours, so we can start updating clients very quickly. At present Opera will check this repository immediately when it starts, but the final version will only check once a week at the same time as we check for other updates.

Examples of EV sites

The EV indicator: Now you see it, now you don't

, , , ...

Two weeks ago I posted a screenshot of Opera 9.5 with EV support.

Late last week I got a surprise while testing some new functionality in the same area (No, I am not going to tell you what it is, yet :devil: ). The Stardock store, the site I used in the screenshot, no longer got an EV status, even after I had eliminated all the bugs in the new functionality.

It turns out that, since I tested this site last, probably during last week, the site was redesigned. And now it includes content from non-EV sites such as Google Analytics and (ironically) "HackerSafe". Neither site is currently EV certified, and they therefore "drag" the main site "down" to their level.

As I said two weeks ago: "It ain't EV 'til it's EV, all EV".

It ain't EV 'til it's EV, all EV

, , , ...

In the past couple of weeks I have been sewing up most of the loose threads in Opera's support for Extended Validation (EV) certificates, and have actually started testing something that resembles the final system.

The work to add Extended Validation has been going on for a while, the basic functionality was implemented last year, but there hasn't been time to build the surrounding infrastructure until this year.

Now, we are finally starting to see the end of the road.

However, I have started to notice something that could become a problem: Not all EV sites, such as Verisign's and PayPal's sites, are coded the way I think they should be coded, or the way Opera's EV support need to be able to recognize them as EV sites.

The sites themselves and the content they serve are not the problem. The thirdparty content they have chosen to include on their site is; Content that is NOT served from EV servers. Apparently, MSIE 7 does not take this external content into consideration when deciding to show the EV indication.

One of the most prominent examples of this third-party content is Google Analytics, which is added to a web page by an external Javascript from a non-EV secure server hosted by Google. Since Google's servers are not using EV certificates, Opera's EV support does not consider the site to be an EV site.

This is due to how Opera's security evaluation system works. Each URL loaded is evaluated based on which protocol was used, what kind of encryption, keylengths, and whether or not the certificate validated correctly. All of this is summed up as a Level in the range of 0 to 3 as follows

  • 0: No encryption (example, plain HTTP)
  • 1: Weak encryption (40 and 56 bit symmetric methods), weak keys (less than 900 bits RSA/DH/DSA), certificate errors, authentiction only. Additionally a combination of problems that would result in Level 2 security being displayed if only one of them were encountered.
  • 2: One, and only one, of these: medium strength keys (900-999 bit RSA/DH/DSA) or failure to get a valid OCSP response. A combination of both results in Level 1 being chosen.
  • 3: Only when using 128 bit encryption, 1000 bit or more RSA/DH/DSA keys, no certificate validation problems.


EV is implemented as Level 4 in this ranking, and a Level 3 resource is only escalated to Level 4 if it contains the necessary EV identificator.

For a group of URLs, such as a web page with redirects, images, CSS, scripts, frames, and so on, the URL with the weakest security level determines the security level for the entire document. This means that a web page with a single unencrypted 1-by-1 image gets Level 0, and that an EV website which includes a 1-by-1 image from a Level 3 non-EV site does not get the EV status. The only exception to this rule is that, on certain conditions, the first request may be a HTTP to HTTPS redirect.

The reason for this design is simple:

  • It is difficult, and in most cases impossible, for a web browser to determine how sensitive a particular element of a page is.
  • Some elements can affect the meaning of the site (for example, a big image, a script, or a frame).
  • In some cases, such as unencrypted requests, analyzing that traffic may reveal what the user is working on (for example, evaluating a stock transaction).


One can make the argument that since the page is secure we can assume that the owners of the site know what they are doing, and that any use of less secure resources is intentional and does not represent a security problem. That assumption is wrong. They may know what they are doing, and have no intention of lowering the security level, but they can still make a mistake somewhere. In at least two cases I have seen, misconfiguration of proxies or redirects caused content that was not secure to be included in otherwise secure banking/payment pages. In one of the cases this content was an external JavaScript used in a payment page, and an attacker could have gotten full access to the secure page if he had changed the JavaScript in transit.

With respect to EV one can make the same argument, but it is flawed in this case, too:

  • The primary point of using an EV certificate on a site is to know the identity of the site's owner.
  • The EV site's owner may or may not know who owns a non-EV third-party site, the client has no way of determining that. We do not know, and cannot know, if the agreement is just a click-wrap or the result of months long lawyer negotiations.
  • In several of the observed cases the third-party content was external JavaScript, which means the third-party is essentially granted full access to manipulate the site's content, and all of it.
  • By allowing non-EV third-party content in a EV site it becomes possible to set up EV "redirector" sites that let non-EV sites look like they are using EV by embedding their content in a frame.


Part of the reason for creating Extended Validation certificates was raising the bar for identification on the Internet, so that is what we will do: Raise the bar.

When Opera ships a version with EV, probably in Kestrel, a site will not be considered as having EV unless all resources used in the rendered page are using Extended Validation certificates.

"It ain't EV 'til it's EV, all EV"

A first look at EV in Opera

, , , ...

Here is a first look at Opera 9.5 ("Kestrel") with full support for Extended Validation (EV) certificates enabled.

This is the implementation in its current form, although the design may be slightly modified before release.


(Click for larger image)

Extended Validation v1.0 approved

, , , ...

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.

Extended Validation certificates and Small Business

, , , ...

Recently there's been a few articles1,2,3, as well as a couple of Slashdot discussions4,5, where some people claim that Extended Validation certificate will somehow make life more difficult for small businesses. Others, like Larry Seltzer are a bit more positive to the development.

As I've posted earlier6, Extended Validation certificates are certificates issued after the information they contain has been through extensive checks to verify that the certificate is not issued to the wrong website and its owner can readily be found. The certificate issuers are regularly audited to ensure they have good procedures when issuing such certificates.

Using additional information embedded in the certificate, the browsers will be able to recognize these certificates and change the UI (such as a green security toolbar or other distinguishing UI features) to reflect the extra quality of the certificate's information.

As I also mentioned, EV certificates do not and cannot vouch for the honesty and trustfulness of the website's owner, but the process of issuing them collects enough information that in the event there is a problem it should be relatively easy to contact or locate the owner.

The articles against EV make a few allegations about what the "problems" with Extended Validation are:
  • Only incorporated companies will currently be able to get EV certificates, sole proprietorships cannot currently buy such certificates. Critics claim this will give the "big" companies an unfair advantage because they are able to get the green security toolbar.

  • The EV certificates will be "much more" expensive than ordinary certificates, which is also supposed to give an unfair advantage to "big" companies.

  • Small new companies that are eligible must meet stricter requirements than older established companies.


Let me answer these below:

Who can get EV certificates?

Currently, as defined in Draft 11 (PDF) of the EV guidelines (which Microsoft will base its support on for the time being) it is quite correct that only incorporated companies can buy EV certificates. The reason for this is that such a company's existence is (in many countries) much easier to verify because of the legal requirements for such companies than it is for companies organized as sole proprietorships.

An incorporated company must be registered with the government, and in many cases (such as Norway) certain requirements must be met, such as having an auditor and regular filing of results to the government. Such requirements make it easier to verify the company's legal and physical existence.

Sole proprietors (one person doing business alone) are not subject to such requirements, and there may or may not be any registration requirements with the local government. (In Norway, all businesses, even sole proprietors must register with the government, but requirements are lower for sole proprietors.) This variability makes it difficult to securely identify such a business as a legal entity.

Non-incorporated entities with banking facilities and the ability to handle e-commerce themselves are actually quite rare. Normally this is contracted to some third-party which is already incorporated, and many small/medium incorporated companies and even some larger ones will do this as well.

Nevertheless, the CA/Browser forum has no intention of letting this situation continue indefinitely, and is actively working to develop procedures that will permit sole proprietors and similar businesses to purchase EV certificates.

Price of EV certificates

The EV certificate routines specify a number of steps that the Certificate Authority must follow before issuing a certificate, as well as other requirements such as a yearly audit for compliance with the guidelines.

Many of these steps and requirements are not part of the current certificate issuing procedures, and each such step or requirment may carry some additional cost. This will, of course, increase the price of the certificate, but how much depends on the business model and cost-structure of the CA, as well as their own choice of price level.

One of the side effects of these extra verification steps is that somebody who wants to use an EV certificate for criminal purposes and somehow manages to get a certificate will have left so many details about themselves that it should be easier for the police to track them down.

While most of the current criminal activity on the net is done using unsecure sites, there have been an increasing number of cases where secure sites have been used, but those sites have used minimal validation certificates that only authenticate the name of the server, and do not
contain any information about the owner.

As users become more careful about where they enter information, criminals will try to get certificates for their phishing sites. EV certificates are also intended to raise the bar to make it more difficult to impersonate websites, and thus head off this development before it becomes a serious problem.

As a side effect, the increased effort required to obtain EV certificates should deter some lazy criminals currently profiting from the unsecure habits some sites have instilled in users.

Stricter requirements for small and new companies

Larger companies naturally have a much larger footprint in economical databases than smaller and newer companies. This means that their existence will be easier to verify than smaller companies.

This will not prevent small/new companies from getting an EV certificate, but it may mean that these companies will have to use slightly more time to provide details to the CA than the bigger companies.

This is unfortunate for a small legitimate business, but it is the basic cost of being able to secure the web for consumers.

However, in many cases small and new businesses will contract payment processing to a third-party, which in most cases is the part of the service that would be secured using an EV certificate. I'll write more about this below.

"The cost of EV certificates is unfair to small businesses"

Yes, big companies may not need to worry about cost to the same degree as smaller companies.

This is simply a recognition of the world in general.

Which businesses/activities really need an EV Certificate?

Generally I'd say that the following areas really need an EV certificate

  • Payment services, all websites where you enter credit card, name and shipping details in combination should have an EV certificate.
  • Web services handling sensitive data. For example netbanking, insurance sites, and government sites managing personal data. As sensitive data I consider name, address and Social security numbers and other personally sensitive data, in particular when parts of
    the information can be used to impersonate the individual.


Both of the above types of services are the kind of applications that should be handled by professionals. Even big companies or government agencies doing the job "inhouse" should tread carefully, because it is far too easy to leave a hole in the system, as has been seen too many times recently (also among the professionals).

For small online shops I recommend that you do not try to implement the payment system yourself (and you probably should not try to create the webshop yourself either). There are several reasons for this:

  • Security: It is very easy to let something dangerous slip into the system.
  • Performance: Shopping systems created by professional developers and hosted on dedicated enterprise hardware are likely to be more efficient than your own (no offense intended).
  • Economy: A third-party shopping system that does what you want probably already exists. Why should you spend time and money better spent improving your business, trying to reinvent the wheel? (Don't get me wrong, if you really have a system that works as well as, or better than, what is already out there, you should definitely start a new business selling your system.)


A couple of the articles mentioned above use as examples a couple of small business entrepreneurs that are worried about the effect of EV certificates on their business.

One of them, a sole proprietor, is (as pointed out by an IE Blog entry) already using two major third-party systems for payment and shopping, both of which are very likely to be eligible for an EV certificate, meaning that her checkout pages will get the green "light" without any action on her part.

The second one, which is incorporated, but not currently having any online business, is eligible for an EV certificate according to the current guidelines and should be able to get an EV certificate if she truly needs it. However, I think she can spend her money and resources better by using a third-party to manage the webshop and the payment services. Such third-parties should also be able to get an EV certificate, and can also spread the cost across far more transactions than the small business can.

So, how will EV certificates affect small business?

EV certificates were not created to hamper small business, and I think most small businesses will either be relatively unaffected by EV certificates, or gain by it if they are using third-party services that are eligible for EV certificates. While most secure websites do not need an EV certificate, if a business does need to have a EV certificate for their own service its business will in most cases be profitable enough that the extra cost isn't insurmountable.

Overall, while the EV certificate isn't a silver bullet, it will help to increase trust on the Internet, and in the long run this will be a major benefit for small businesses on the Internet.

Introducing Extended Validation Certificates

, , , ...

Last year it became clear that the procedures for verifying data used to issue SSL certificates (and other types of certificates) were not as uniform as might be desired. This led to a situation where information in certificates might be misleading.

Certificates are specially formatted documents used to identify certain entities -- persons, companies or (in our case) Web sites -- and associate them with a given public encryption key and its associated private key. A user can use this public key to verify documents digitally signed by the associated private key held by the identified entity. Alternatively, the user can use the public key to send encrypted information to the certificate's owner that can only be decrypted by that private key.

Certificates are valid for a certain period and are signed by a Certificate Authority (CA), whose name is identified in the Web site's certificate. This certificate is either signed by another CA, or it is (self)signed by the CA itself, with the private key assiociated with the public key in the certificate. In the first case the CA is called an intermediate CA (one that has been authorized to act as a CA by another CA), in the other case the certificate is called selfsigned, and the CA is called a Root CA. The Root CA certificates are the certificates that are preinstalled in clients because your only way to verify the Root CA is to have your own copy that you can use as a reference.

This sequence of Web site certificate, intermediate CAs and the Root CA is called a certificate chain. This certificate chain links the Web site's certificate to a trusted root in the browser's root certificate store through a chain of digital signatures. If it does not, your browser will tell you so.

To increase the usefulness of (in particular) SSL certificates and reduce the likelihood of misleading or incorrect information being placed in certificates, the browser vendors, the Certificate Authorities (CAs) and several others, such as the Information Security Committee of the American Bar Association, WebTrust and the Anti Phishing Working Group created the CA Browser Forum.

The forum's goal is to create a set of guidelines for how certificates used for sensitive online transactions, such as payments, are created and how the information contained in them is checked before the certificate can be issued. The guidlines also specify what kind of controls browsers should perform before indicating that the certificates have been issued according to these guidelines.

Some details, like the general UI (for example a green security toolbar, as suggested by Microsoft) and how the certificates should be identified were decided early, when the browser vendors met in Toronto1, 2, 3, 4 last year.

That was the easy part.

The more difficult part was finding methods that to a reasonable and satisfactory degree can confirm that

  • A Web site is owned and controlled by a given legal entity.
  • That this entity has the right to control the Web site.
  • Collect enough information so that it would be easier to find the Web site owner if necessary.


All of these procedures must also be possible for an auditor to verify.

There were some things that were not realistic to achieve, such as proving that the Web site owner is a law-abiding citizen, is trusthworty and reputable, and so on, or that it is safe to do business with the owner. These are critera that are far too subjective, and even if they are true at one point, that might change very quickly.

These guidelines are intended to raise the information quality of the certificates. For anyone wanting to engage in criminal activity, the guidelines also raise the bar in terms of cost, time-wise and financial, and the risk of getting caught.

What do the EV Guidelines demand?

Before issuing a certificate a CA must (for example) make sure that

  • The company is a valid legal entity in its jurisdiction
  • The person(s) signing the contract are authorized to do so.
  • The company owns the domain of the server, or is authorized by the owner to use the given server or domain.


There are also requirements for the procedures the CA must use when issuing a certificate, and what data must be included in the certificate.

All of the procedures must be audited regularly (yearly) by a WebTrust auditor (or equivalent), and if the CA fails an audit, the certificates it has issued can no longer be recognized as EV certificates.

On the browser side we must perform several checks of the certificate before we can turn on the Extended Validation indicator:

  • We must (of course) check that the certificates verify correctly (that is, the signatures are OK, and trace back to a known Root CA, and none of the certificates have expired).
  • Additionally there are requirements for the level of encryption that must be used in the certificate, as well as for the connection.
  • Then we must verify that not just the site's certificate, but all the intermediate CA certificates in the chain (but not the root) are still valid, and has not been revoked by the issuer. This will be done using OCSP (Online Certificate Status Protocol) and/or CRLs (Certificate Revocation Lists) which are regularly updated by the CA to include certificates that for some reason are no longer valid and has been revoked. A certificate can be revoked for many reasons such as when a new certificate has been issued, the private key has been stolen, or that fake data was used to get the certificate.
  • Each EV certificate will contain at least one special identifier that marks it as an EV certificate, an EV-OID, that must also be included in all the intermediate CA certificates.
  • To be recognized by the client as an EV certificate the EV-OID must be associated in the certificate store with the certificate of the Root CA. This association is contingent on the Root CA passing the yearly EV compliance audit. If the audit fails and the problems are not quickly resolved so that the CA passes a new audit, the EV-OIDs associated with the Root CA are removed during a regular update of the associations, and the certificates issued from this Root CA will no longer be recognized as EV certificates


Once a certificate has passed all these checks, the client can turn on the Extended Validation indicator, usually a green security toolbar (which in Opera is normally yellow).

Implementation plans

Current plans among the CAs are to start offering EV early 2007, when the first EV update of IE7 is planned.

Opera has not yet implemented complete support for what is needed for Extended Validation, but work is underway:

  • Opera has supported OCSP verification of certificates since version 8.0, but CRL support is not yet implemented.
  • Some of the necessary functionality have been tested in an internal demo version (see screenshot), based on a weekly release from March 2006.


There is a lot more that needs to be implemented before we can release a version with support for EV, but we will do so When It's Ready.

Stay tuned.


This article is also available on Opera Labs.
November 2009
S M T W T F S
October 2009December 2009
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30