Closed Bug 493709 Opened 15 years ago Closed 15 years ago

Combined EV enablement

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
1.9.1 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.1

People

(Reporter: eddy_nigg, Assigned: KaiE)

References

Details

(Keywords: fixed1.9.1, verified1.9.0.15)

Attachments

(1 file)

Combined EV OID patch
3.00 KB, patch
KaiE
: review+
dveditz
: approval1.9.0.15+
Details | Diff | Splinter Review 
This bug is a single address for enabling EV according to the following bugs:

bug 449394 (WellsSecure)
bug 477145 (SECOM Trust)
bug 490492 (StartCom)
bug 492077 (SwissSign)
bug 493259 (Cybertrust)
bug 493265 (DigiNotar)
Tested against URLs:

https://nerys.wellsfargo.com/
https://repo2.secomtrust.net/
https://cert.startcom.org/
https://testevg2.swisssign.net/
https://secure.ichotelsgroup.com/
https://www.polisdirect.nl/

(Latest doesn't show the EV UI, reason might be OCSP or CRL?)

Bob or Kai, please review and approve.
Attachment #378295 - Flags: review?(rrelyea)
Attachment #378295 - Flags: review?(kaie)
Target Milestone: --- → mozilla1.9.1
Depends on: 493660
Comment on attachment 378295 [details] [diff] [review]
Combined EV OID patch

I verified that all fingerprints and all EV OIDs match the information in the respective 6 bugs, and that a reasonable OID name is used in the patch.

r=kaie

I trust that Eddy did correct testing and added the right encodings of subject/serials.
Attachment #378295 - Flags: review?(rrelyea)
Attachment #378295 - Flags: review?(kaie)
Attachment #378295 - Flags: review+
Depends on: 494236
a191=beltzner after it's had a green cycle on mozilla-central
Flags: wanted1.9.1?
Mike, my wanted1.9.1 ? flag coincided with your approval above. Shall I remove it?
Yeah, clearing that - this has approval once we get our ducks here, and in bug 494236 into a row.
Flags: wanted1.9.1?
I think the patch author may not have a CVS account, and so a checkin will
be needed by someone who does.  I hope it's not too late now.
For the sake of consistency, I would recommend to add new myTrustedEVInfos entries at the end (before the sample entry), rather than insert them before the existing ones.
Landed on central along with bug 493660

http://hg.mozilla.org/mozilla-central/rev/0b821db9a67e

After baking on central for a cycle, I will land this with bug 493660's branch version.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
*that should read bug 494236, not bug 493660
mozilla-central was clean (minus known oranges) - landed on mozilla-1.9.1

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/269ebc5616a1

Forgot the a=beltzner comment.  :(
Keywords: fixed1.9.1
This isn't fixed in the latest 1.9.1 nightly: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090523 Shiretoko/3.5pre ID:20090523044232

Only 2 of the 6 URL's show the EV UI

Works:
https://nerys.wellsfargo.com/
https://cert.startcom.org/

Does not work
https://repo2.secomtrust.net/
https://testevg2.swisssign.net/
https://secure.ichotelsgroup.com/
https://www.polisdirect.nl/

All URL's work in the latest Minefield:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090523 Minefield/3.6a1pre ID:20090523042428
One of the solutions for this behavior might be in bug 477244. CyberTrust and SecomTrust don't provide an OCSP URL (and working OCSP responder) including EE cert, the others don't provide and OCSP URL in the chain. Firefox doesn't fetch yet CRLs to all of my knowledge.

The EV UI works correctly with this patch and latest FF3 which has a different policy on revocation checking.
In reply to comment 11,
These behavioral differences are known and understood.  
We've intentionally chosen to delay the fix for some of them until after 
FF 3.5.0 is released.  They will probably be fixed in an early update 
fix for FF 3.5, e.g. FF 3.5.1 (or 3.5.0.1 :).
Hi,

what is not ok for the https://testevg2.swisssign.net ?

Initially we created ourself a patch in order to verify that all will be fine. That worked already with FF 3.0.4.:
diff -ru firefox-3.0.4/security/manager/ssl/src/nsIdentityChecking.cpp firefox-3.0.4-swisssign/security/manager/ssl/src/nsIdentityChecking.cpp
--- firefox-3.0.4/security/manager/ssl/src/nsIdentityChecking.cpp	2008-10-23 01:06:29.000000000 +0200
+++ firefox-3.0.4-swisssign/security/manager/ssl/src/nsIdentityChecking.cpp	2008-12-06 18:24:07.000000000 +0100
@@ -82,6 +82,16 @@
 
 static struct nsMyTrustedEVInfo myTrustedEVInfos[] = {
   {
+    // CN=SwissSign Gold CA - G2,O=SwissSign AG,C=CH
+    "2.16.756.1.89.1.2.1.1",
+    "SwissSign EV OID",
+    SEC_OID_UNKNOWN,
+    "D8:C5:38:8A:B7:30:1B:1B:6E:D4:7A:E6:45:25:3A:6F:9F:1A:27:61",
+    "MEUxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxHzAdBgNVBAMTFlN3aXNzU2lnbiBHb2xkIENBIC0gRzI=",
+    "ALtAHEP1Xk+w",
+    nsnull
+  },
+  {
     // CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
     "2.16.840.1.113733.1.7.23.6",
     "VeriSign EV OID",

What is making now the issue, especially that our Endcertificates have CRL and OCSP information in it?
The specific issue with your CA is, that your intermediate CA which issues the EV certificates doesn't have an OCSP responder URI in the AIA extension of the certificate (not sure if an OCSP responder exists). In FF 3.5 (as opposed to FF 3.0.x) a different policy for revocation status checking is applied. Because Firefox currently can only check revocation status with OCSP responders, the status of the intermediate CA certificate is unknown and therefore refuses to show the EV UI.

Possible solution would be to issue an intermediate CA with OCSP URI in the AIA extension. At some point, a future version of NSS will apparently support also CRL fetching. Also, if this patch is going to be applied to the FF 3.0.x version, the EV UI will most likely show as well (due to the different policy). Hope this helps.
Ok I'll submit this internaly to create a new intermediate issuing CA with OCSP in it. In the meantime is it possible to add the fix also to the FF 3.0.x branch?
I suppose that if and once bug 495033 is approved for checkin, we could apply this patch also to 1.9.0.12? I'll file a new bug for this.
Do you recommend to create new issuing CA and reissue all issued EV Certfificates in order to get the Green Bar with FF 3.5 or is there a quicker answer from your side in order to have FF 3.5 working lie FF 3.0?
Filed bug 495044 for 1.9.0.x branch.
FF 3.5 will not have the same policy as FF 3.0, but NSS is supposed to support CRL fetching at some point - and with it the EV UI should show again with your CA. Maybe Nelson can give some estimates when this potentially could be, as per comment 13. His answer could give you some indication if it's worth the effort to re-issue all EV certificate, but I'd recommend to issue a new EV issuer with an OCSP URI in the AIA extension and issue any new EV certificate from there (if that's possible for you).
Thanks for the infos - where will this be visible in Firefox 3.0? Update 11 or 12?
Hi we added the OCSP to our Issuing CA, could you just check and confirm that this will be fine now?
 https://testevg2.swisssign.net
All green ;-)
Attachment #378295 - Flags: approval1.9.0.14?
Comment on attachment 378295 [details] [diff] [review]
Combined EV OID patch

It has been requested in bug 495044 to add this patch to Firefox 3.0.x, requesting approval for 1.9.0.x
Comment on attachment 378295 [details] [diff] [review]
Combined EV OID patch

1.9.0.14 is frozen right now, so moving request to 1.9.0.15.
Attachment #378295 - Flags: approval1.9.0.14? → approval1.9.0.15?
Comment on attachment 378295 [details] [diff] [review]
Combined EV OID patch

Approved for 1.9.0.15, a=dveditz for release-drivers
Attachment #378295 - Flags: approval1.9.0.15? → approval1.9.0.15+
Keywords: fixed1.9.0.15
fixed 1.9.0.15

Checking in nsIdentityChecking.cpp;
/cvsroot/mozilla/security/manager/ssl/src/nsIdentityChecking.cpp,v  <--  nsIdentityChecking.cpp
new revision: 1.26; previous revision: 1.25
(In reply to comment #1)
> Tested against URLs:
> 
> https://nerys.wellsfargo.com/
> https://repo2.secomtrust.net/
> https://cert.startcom.org/
> https://testevg2.swisssign.net/
> https://secure.ichotelsgroup.com/
> https://www.polisdirect.nl/

Looking at these in the 1.9.0.15pre build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.15pre) Gecko/2009092205 GranParadiso/3.0.15pre (.NET CLR 3.5.30729), the following do not show the EV UI:

https://secure.ichotelsgroup.com/
https://repo2.secomtrust.net/

https://nerys.wellsfargo.com/ shows the EV UI but is a 404 page.

Is there a better way to test all of this for 1.9.0?
(In reply to comment #29)
> Looking at these in the 1.9.0.15pre build (Mozilla/5.0 (Windows; U; Windows NT
> 5.1; en-US; rv:1.9.0.15pre) Gecko/2009092205 GranParadiso/3.0.15pre (.NET CLR
> 3.5.30729), the following do not show the EV UI:
> 
> https://secure.ichotelsgroup.com/
> https://repo2.secomtrust.net/

These two use CRLs for revocation information instead of OCSP, and 1.9.0 doesn't support CRLs. In the absence of revocation information, we downgrade from EV (green) to DV (blue), so these certs, despite their roots being "EV enabled" aren't going to show up as EV unless and until NSS 3.12.4 is backported to 1.9.0.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: