New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users

Issue metadata

Status: Fixed
Closed: Jan 2012
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment is not verified as EV (extended validation)

Project Member Reported by, Apr 28 2010 Back to list

Issue description

The server certificate for is not
verified as EV (extended validation).  This is because CERT_PKIXVerifyCert
returns a certificate chain that ends in the "wrong" root CA cerificate
Network,L=Salt Lake City,ST=UT,C=US).  The server certificate has multiple
valid certificate chains, but only one of them is good for EV verification.

Our EV verification code in needs to match the
Firefox code more closely.  In particular, we should pass the desired
root CA certificate as the cert_pi_trustAnchors input to CERT_PKIXVerifyCert.

Right now we do not specify cert_pi_trustAnchors, which means all root
CA certificates are acceptable.  While this is OK for normal verification,
we should restrict the cert_pi_trustAnchors for EV verification

ukai, do you have time to work on this?  If not, I can work on this.

Comment 1 by, Apr 28 2010

I'm webkit gardener now, and will be on vacation for about a week (japanese holiday 
I can work after May 6th.

Comment 2 by, Apr 29 2010

ukai: it may be possible to fix this particular case by allowing a root
CA to have more than one EV policy OID.  I noted this possible solution

I am not sure if that's the right thing to do though because we'd need
to associate the EV policy OID of one root CA with an "unrelated" root
CA that cross-certifies the first root CA.

Comment 3 by, May 10 2010

It looks the server certificate for is verified as 
EV on Chromium	6.0.400.0 (Developer Build 46804).
Is it fixed, or happened to success verification?

If we need to fix, is this the right path to fix?
 - adds issuer and serial number in EVMetadata in, and 
initializes trusted ev roots from issuer and serial, as did in
 - In VerifyEV()
   - get first EV policy from cert_handle_, as did in
     maybe, we should refactor GetFirstCertPolicy to have flag to extract first EV 
   - get root list from EVRootCAMetadata for the ev policy
   - use the root list as cert_pi_trustAnchors for verify ev cert.
   - check trustAnchor (issuerCert) is matched with info in EVRootCAMetadata.

Comment 4 by, May 11 2010

Ah, sorry.
I was wrong. is verified, but failed as EV on latest 
Chrome (green key, but no EV info on omnibox).

Comment 5 by, May 11 2010

Re: comment 3

ukai: thank you for looking into this.  I don't know why
is verified as EV (because NSS can construct the desired certificate chain) on your Linux
computer.  I suspect it's because you're using NSS but I was using NSS 3.12.6
(or even the tip of NSS) when I filed this bug report.  (My recent fix for NSS bug definitely changed how NSS
constructs certificate chains for certs issued by Network Solutions CA.)

You are right -- to implement the solution I originally proposed (emulate the Firefox
function getRootsForOid), we will need to add issuer and serial number to the entries
in our ev_root_ca_metadata, because we need a way to look up the root certs (by
their issuer and serial number).  I didn't realize this is necessary.  This makes me
like that solution less.  But I'm not sure if the alternative solution I proposed in
comment 2 is correct.

In any case, the fix you outlined is exactly what Firefox does.

As for refactoring GetFirstCertPolicy, it's a good idea.  However, I compared 
GetFirstCertPolicy with Firefox's getFirstEVPolicy.  I'm afraid that the only code
they can share is our DecodeCertPolicies function.  So we may not be able
to refactor it further.  (Firefox doesn't call CERT_FindCertExtension, but its
code is equivalent.)

Comment 6 by, May 11 2010

ukai: you can find issuers and serial numbers for all the root CA certs in

They are in binary form though.  Because of the \ooo escaping, they are longer (in
C++ source code) than the base64 representations that Firefox uses, but after
compilation they are shorter than base64 and no base64 decoding is needed.

If you think this is too much tedious work, you can just implement the
alternative solution I proposed in comment 2.  In general we should be able to
support a root CA that has more than one EV policy OID.  According to the
Wikipedia article
there are at least two root CAs (Izenpe and StartCom) that have more than
one EV policy OID.

Comment 7 by, May 11 2010

wtc: Ok, I'll try alternative solution first.
support more than one EV policy OIDs for a fingerprint in EVMetadata and checks one 
of them is used in the certificate.

maybe, we'll change EVRootCAMetadata::GetPolicyOID to 
 const vector<PolicyOID>& GetPolicyOID(const X509Certificate::Fingerprint& 
fingerprint) const
or so.

Do we need to fix as well?

Comment 8 by, May 11 2010

wtc: Izenpe and StartCom have more than one EV policy OIDs, but we don't have them in 
ev_root_ca_metadata (yet)?  Should we add them?

Comment 9 by, May 11 2010

ukai: don't add Izenpe and StartCom yet.  EV policy OIDs need to be reviewed by
Ian Fette before we can add them.

Re: your proposal in comment 7: Yes, we can change EVRootCAMetadata::GetPolicyOID
to return a vector of PolicyOID.  But it seems better to replace it with a different function:
    bool EVRootCAMetadata::IsEVPolicyForRoot(GetPolicyOID(
        PolicyOID policy,
        const X509Certificate::Fingerprint& fingerprint) const;

This is similar to the Firefox isApprovedForEV function, but we can implement it
more efficiently.  We do need to change the PolicyOidMap type to map a certificate
fingerprint to a vector or list of PolicyOID.

Yes, I believe we need to change as well.

Comment 10 by, May 11 2010

wtc: if we don't add Izanpe and StartCom, how does supporting more than one EV policy 
OIDs solve the issue?

I investigated it more detail and found CERT_PKIXVerifyCert for failed with nss_error=-8180 (SEC_ERROR_REVOKED_CERTIFICATE) 
for VerifyEV.

If we loose revocation_method_flags to CERT_REV_M_SKIP_TEST_ON_MISSING_SOURCE, we'll 
get nss_error=-8182 (SEC_ERROR_BAD_SIGNATURE)
Status: Assigned

Comment 12 by, Jul 16 2010

Labels: -Mstone-6 Mstone-7

Comment 13 by, Sep 24 2010

Labels: -Mstone-7 Mstone-8
Labels: -Mstone-8 Mstone-10

Comment 15 by Deleted ...@, Nov 27 2010

Please check our homepage
cooperate and advertise to all persons,to allow all the communities in
the world to visit and download from our website
in the interest of public peace,humanity,jobs,business,security,health and wealth of mankind in the world and oblige.

With Kind Regards,
Ibrahim Ali.

Comment 16 by, Dec 9 2010

Labels: -Mstone-10 MovedFrom-10 Mstone-11
P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.

Comment 17 by, Feb 18 2011

Labels: -Mstone-11 Mstone-12
Labels: -Mstone-12 Mstone-14

Comment 19 by, Jul 28 2011

Labels: -Mstone-14 Mstone-15 MovedFrom-14
Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.

Comment 20 by, Sep 8 2011

Labels: MovedFrom15 bulkmove Mstone-16
moving all non-essential bugs from 15 to 16. please feel free to move back if this was an error and your bug is a release blocker.
Project Member

Comment 21 by, Oct 4 2011

The following revision refers to this bug:

r104007 | | Tue Oct 04 15:53:41 PDT 2011

Changed paths:

net: add NetSol's EV OIDs to cross-certifying roots.

Chain building for certificates issued by Network Solutions can end up at a
cross-certifying root. This change adds the NetSol EV OIDs to the roots which
cross-sign it so that we still recognise them as EV.

BUG= 42702 
TEST=Check that is EV on all platforms.

Review URL:

Comment 22 by, Oct 24 2011

Labels: -Mstone-16 MovedFrom-16 Mstone-17

Comment 23 by, Dec 19 2011

Labels: -Mstone-17 Mstone-18 MovedFrom-17
Moving bugs marked as Assigned but not blockers from M17 to M18.  Please move back if you think this is a blocker, and add the ReleaseBlock-Stable label.  If you're able.

Comment 24 by, Jan 20 2012

Status: Fixed
I believe agl fixed this at r104007.
current chromium/linux shows that is verified as EV.

Project Member

Comment 25 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 26 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network -Mstone-18 M-18 Cr-Internals Cr-Internals-Network
Project Member

Comment 27 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment