1242086 - Firefox doesn't handle multiple certificatePolicies OIDs in EV certs

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Rick Andrews]

Attachment: noev.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160105164030

Steps to reproduce:

TLS certificates may contain zero or more policy OIDs in the certificatePolicies extension. Up until now, all our EV TLS certificates contained Symantec’s EV certificatePolicies OID of 2.16.840.1.113733.1.7.23.6. Recently, Microsoft’s Root Policy program [1] required all CAs to use the CA/Browser Forum EV certificatePolicies OID (2.23.140.1.1, from [2]) in EV TLS certificates. In order to continue to support EV treatment of our certificates, we decided to *add* the CA/Browser Forum EV certificatePolicies OID to our certificates, not replace our Symantec certificatePolicies OID with the CA/Browser Forum EV certificatePolicies OID.

Eventually, once all browsers support the CA/Browser Forum EV certificatePolicies OID, we will drop the Symantec EV certificatePolicies OID. But for now, we need to put both OIDs in each EV certificate to continue to provide EV treatment, and comply with Microsoft’s root program requirements.

So we added the CA/Browser Forum EV certificatePolicies OID as the first certificatePolicies OID in the certificatePolicies extension, and pushed Symantec’s EV certificatePolicies OID to be second in the list.

[1] http://aka.ms/rootcert, Section 4.A.15
[2] https://cabforum.org/object-registry/


Actual results:

Firefox treated the certificate as trusted, but failed to provide the EV treatment for that certificate. See attachment noev.jpg.


Expected results:

Firefox should have provided the EV treatment for that certificate.

When we reversed the order of the certificatePolicies OIDs (Symantec’s first, CA/Browser Forum’s OID second), then Firefox provided EV treatment. We conclude that Firefox is not expecting multiple certificatePolicies OIDs, and is only looking at the first certificatePolicies OID in the list.

Test sites:
https://ssltest21.bbtest.net/ (Symantec OID in the second position, no EV treatment given)
https://ssltest22.bbtest.net/ (Symantec OID in the first position, EV treatment given)

There are really two bugs here:
1) Firefox is only examining the first certificatePolicies policy OID and ignoring any others
2) Firefox should add the CA/Browser Forum EV certificatePolicies OID (2.23.140.1.1) to the list of EV certificatePolicies OIDs expected in valid EV certificates. This should be done for all roots capable of issuing EV certificates. For the next few years, Firefox should expect either OID (the EV certificatePolicies OID currently configured for each root, plus the CA/Browser Forum EV certificatePolicies OID).

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: Screenshot from 2016-01-25 14-16-52.png

With regard to the first issue, I suspect the problem is actually due to a misconfigured OCSP responder. Try with the about:config pref security.OCSP.require set to true.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(see comment 1)

Comment 3

[hoang_nguyen1]

Not sure if that is the cause.  

With the about:config pref security.OCSP.require set to false, the issue is:

  https://ssltest21.bbtest.net/ shows the lock but no EV treatment (organization name not shown in the green bar)

  https://ssltest21.bbtest.net/ shows the lock AND EV treatment (organization name shown in the green bar)


Why did EV treatment show up in one but not the other?

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(In reply to hoang_nguyen1 from comment #3)
> Not sure if that is the cause.  
> 
> With the about:config pref security.OCSP.require set to false, the issue is:

For EV, OCSP is required regardless of the pref value. If OCSP verification fails, Firefox won't show the EV indicator.

>   https://ssltest21.bbtest.net/ shows the lock but no EV treatment
> (organization name not shown in the green bar)
> 
>   https://ssltest21.bbtest.net/ shows the lock AND EV treatment
> (organization name shown in the green bar)
> 
> 
> Why did EV treatment show up in one but not the other?

I'm assuming the second host was intended to be ssltest22.bbtest.net there. In any case, it looks like the responder for ssltest21 is not configured correctly (at least for that certificate). See the following:

$ openssl ocsp -CAfile GeoTrust-roots.pem -issuer GeoTrustExtendedValidationSHA256SSLCA.pem -cert ssltest21.bbtest.net.pem -host gk.symcd.com:80
Responder Error: unauthorized (6)

compared to:

$ openssl ocsp -CAfile GeoTrust-roots.pem -issuer GeoTrustEVSSLCA-G4.pem -cert ssltest22.bbtest.net.pem -host gm.symcd.com:80
WARNING: no nonce in response
Response verify OK
ssltest22.bbtest.net.pem: good
        This Update: Jan 25 18:23:45 2016 GMT
        Next Update: Feb  1 18:23:45 2016 GMT

Comment 5

[hoang_nguyen1]

After generating an OCSP response for ssltest21.bbtest.net, the EV treatment looks good on FireFox.  Sorry for the false alarm!  Please close this ticket.  Thanks!

Comment 6

[hoang_nguyen1]

Could you please add CABF EV OID as a valid EV OID so that we can eventually get rid of the Symantec OID in the certificate?  Thanks!

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Ok - I filed bug 1243923 for that.