https://www.networksolutions.com/ is not verified as EV (extended validation)
|Project Member Reported by email@example.com, Apr 28 2010||Back to list|
The server certificate for https://www.networksolutions.com/ is not verified as EV (extended validation). This is because CERT_PKIXVerifyCert returns a certificate chain that ends in the "wrong" root CA cerificate (CN=UTN-USERFirst-Hardware,OU=http://www.usertrust.com,O=The USERTRUST 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 x509_certificate_nss.cc 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. See http://mxr.mozilla.org/mozilla1.9.2/ident?i=getRootsForOid 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 (X509Certificate::VerifyEV) ukai, do you have time to work on this? If not, I can work on this.
Apr 28 2010,
I'm webkit gardener now, and will be on vacation for about a week (japanese holiday week). I can work after May 6th.
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 in https://bugzilla.mozilla.org/show_bug.cgi?id=562537 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.
May 10 2010,
It looks the server certificate for https://www.networksolutions.com/ 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 ev_root_ca_metadata.cc, and initializes trusted ev roots from issuer and serial, as did in http://mxr.mozilla.org/mozilla1.9.2/source/security/manager/ssl/src/nsIdentityCheckin g.cpp#819 - In VerifyEV() - get first EV policy from cert_handle_, as did in http://mxr.mozilla.org/mozilla1.9.2/source/security/manager/ssl/src/nsIdentityCheckin g.cpp#880 maybe, we should refactor GetFirstCertPolicy to have flag to extract first EV policy. - 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. http://mxr.mozilla.org/mozilla1.9.2/source/security/manager/ssl/src/nsIdentityCheckin g.cpp#795
May 11 2010,
Ah, sorry. I was wrong. https://www.networksolutions.com/ is verified, but failed as EV on latest Chrome (green key, but no EV info on omnibox).
May 11 2010,
Re: comment 3 ukai: thank you for looking into this. I don't know why https://www.networksolutions.com/ 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 220.127.116.11 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 https://bugzilla.mozilla.org/show_bug.cgi?id=524013 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.)
May 11 2010,
ukai: you can find issuers and serial numbers for all the root CA certs in http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/builtins/certdata.txt 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 http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification there are at least two root CAs (Izenpe and StartCom) that have more than one EV policy OID.
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 x509_certificate_win.cc as well?
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?
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 x509_certificate_win.cc as well.
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 www.networksolutions.com 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)
Jun 7 2010,
Jul 16 2010,
Sep 24 2010,
Oct 18 2010,
Nov 27 2010,
Please check our homepage www.goldenduas.com.Please cooperate and advertise to all persons,to allow all the communities in the world to visit and download from our website www.goldenduas.com. 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.
Dec 9 2010,
P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.
Feb 18 2011,
Apr 25 2011,
Jul 28 2011,
Punting out non-critical bugs. Please move back to 14 if you believe this was done in error.
Sep 8 2011,
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.
Oct 4 2011,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=104007 ------------------------------------------------------------------------ r104007 | firstname.lastname@example.org | Tue Oct 04 15:53:41 PDT 2011 Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ev_root_ca_metadata.cc?r1=104007&r2=104006&pathrev=104007 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 https://www.networksolutions.com is EV on all platforms. Review URL: http://codereview.chromium.org/8118033 ------------------------------------------------------------------------
Oct 24 2011,
Dec 19 2011,
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.
Oct 13 2012,
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.
Mar 10 2013,
Mar 13 2013,
Sign in to add a comment