Closed Bug 1001913 Opened 11 years ago Closed 11 years ago

Trend Micro EV certificates not showing EV indicators in Firefox 28 and above

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: gerv, Unassigned)

Details

Kirk Hall writes: Kathleen and Gerv – we have a very serious Firefox problem that appears to have started with Firefox 28, and also exists in Firefox 29 beta. Our EV certificates are no longer showing the green bar, and in fact they seem to be treated as if they were only DV certificates. Can you figure out why, and get it fixes? One of our technical people has been investigating this issue this morning for a known, good EV cert, https://www.floridahospital.com. As you see below, the cert for that page used to display EV green in earlier versions of Firefox. Now, it displays as DV. If you click many times to get to Subject, you can see all the EV data is there. It displays as EV in Chrome, IE, and Opera. You can see the same result for the test sites for our four roots at http://webappsecurity.trendmicro.com/resources/root-certs/ -- shows as EV in all the other browsers (and used to show as EV in Firefox), now shows as DV. But again, if you click many times to get to Subject, you can see all the EV data is there. What happened? Is there any way we can get this fixed by the time of Firefox 29’s release on April 29? Our customers will be very unhappy… What more can we do to get this going? Thanks. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 Kathleen suggested one of these two changes might be the cause: https://wiki.mozilla.org/CA:ImprovingRevocation#No_EV_Treatment_when_OCSP_Fails_or_Not_Provided https://wiki.mozilla.org/CA:ImprovingRevocation#Reduce_OCSP_Network_Timeout_for_EV_and_Soft-Fail However, I've used Live HTTP Headers, and it seems that Trend Micro's OCSP server is returning an OCSP response, and is returning it within the appropriate time. (I can't see what the response says exactly, of course.) I tried turning on OCSP logging: https://wiki.mozilla.org/NSS:Tracing but it didn't work. So I'm out of ideas. Over to you guys. Gerv
OK, we figured out what happened. The issuing sub-CA for the affected EV certificates, Trend Micro CA, was put online in October 2011. The first version of the BRs, v1.0, was published Nov. 2011, with an effective date of July 2012. Our development team assumed the new requirement of an AIA extension in the issuing sub-CA would only apply to sub-CAs created after the BR effective date, and so made no change. (Other issuing sub-CAs we have created after the BR effective date do contain the required AIA URL.) We will re-sign the issuing sub-CA in question to include the AIA URL as soon as possible and put up a corresponding OCSP responder. This bug can now be closed. Kirk Hall kirk_hall @ trendmicro.com
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
This reads to me like something we did in the BRs is affecting the EV-ness or otherwise of certs. Can you walk me through how that works, with references? If the BRs require sub-CAs to have an AIA extension with an OCSP responder, and we are now enforcing that, surely the chain should have failed entirely? Or... is this because we are using libpkix for EV, which does check this, but if EV fails, we fall back to classic, which doesn't? Ah! Gerv
In August, 2010, I requested the change to not provide EV treatment when end-entity and intermediate certs (issued after 2010) don't have an AIA OCSP URI. https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/mYKaLIcP70I/255h8y4-0YYJ A good explanation of why this change was recently made is here: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 This is a good time to also note: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes "EV treatment will not be given when the OCSP response for the intermediate certificate is more than 10 days old." This change should probably be brought up with the CAB Forum...
(In reply to Kathleen Wilson from comment #3) > A good explanation of why this change was recently made is here: > https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 The logic there has a loophole. "So, now we have OCSP stapling enabled. Also, the EV guidelines have said for more than 27 months that end-entity certificates MUST have an OCSP responder URI. Further, the EV guidelines have said for more than 27 months that intermediate CA certificates SHOULD have an OCSP responder URI. Further, 27 months is the maximum lifetime of an EV certificate, according to the EV guidelines." However, the maximum lifetime of an EV _intermediate_ is not as little as 27 months. And this is the issue that Trend Micro have hit. Gerv
Fair enough. But I still think this change of requiring an intermediate OCSP response in order to get EV treatment is a step in the right direction. I asked for it back in 2010, and now in 2014 it finally happened. While we may find a few more of these instances of intermediate certs not having the OCSP URI in the AIA, the sites still work, they just don't get EV treatment. For EV, most CAs internally-operate the intermediate certificates, so I think it is reasonable to have the CA update the intermediate cert to have the OCSP URI in the AIA.
Kathleen: I'm not arguing strongly against doing what we did; I'm just pointing out the reason why it was not as side-effect-free as the original statement assumed it would be. Gerv
(In reply to Gervase Markham [:gerv] from comment #4) > (In reply to Kathleen Wilson from comment #3) > > A good explanation of why this change was recently made is here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 > > The logic there has a loophole. > > "So, now we have OCSP stapling enabled. Also, the EV guidelines have said > for more than 27 months that end-entity certificates MUST have an OCSP > responder URI. Further, the EV guidelines have said for more than 27 months > that intermediate CA certificates SHOULD have an OCSP responder URI. > Further, 27 months is the maximum lifetime of an EV certificate, according > to the EV guidelines." > > However, the maximum lifetime of an EV _intermediate_ is not as little as 27 > months. And this is the issue that Trend Micro have hit. In order to comply with the EV rules, the CA needs to issue the EV certificate from an intermediate that complies with the rules. In particular, even if they had an existing intermediate that was missing the OCSP AIA URI and had not yet expired, they still should have switched to a different intermediate that did have the OCSP AIA URI.
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #7) <snip> > In order to comply with the EV rules, the CA needs to issue the EV > certificate from an intermediate that complies with the rules. In > particular, even if they had an existing intermediate that was missing the > OCSP AIA URI and had not yet expired, they still should have switched to a > different intermediate that did have the OCSP AIA URI. Brian, where in the EVGs and/or BRs is this requirement stated? I can't find it. Thanks.
Flags: needinfo?(brian)
(In reply to Rob Stradling from comment #8) > Brian, where in the EVGs and/or BRs is this requirement stated? I can't > find it. Thanks. Hi Rob, I think you are saying that there is a way that a reasonable person may interpret the EV/baseline requirements such that a certificate that is issued (only) by an old that doesn't meet the current baseline requirements should still get the EV indicator. In the interest of saving effort, I will not argue that that interpretation is unreasonable. However, I also won't bother to expend effort to support that interpretation in Gecko. Instead, let's all try to think about what's the best thing to do to improve users' safety online and spend time doing those things.
Flags: needinfo?(brian)
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #9) > (In reply to Rob Stradling from comment #8) > > Brian, where in the EVGs and/or BRs is this requirement stated? I can't > > find it. Thanks. > > Hi Rob, I think you are saying that there is a way that a reasonable person > may interpret the EV/baseline requirements such that a certificate that is > issued (only) by an old that doesn't meet the current baseline requirements > should still get the EV indicator. I'm saying that, IMHO, continuing to use an old intermediate that lacks an AIA OCSP URL to issue EV certs is definitely compliant with the EVGs/BRs. Appendix B of the BRs clearly says "This appendix specifies the requirements for Certificate extensions for Certificates _generated after the Effective Date_." > In the interest of saving effort, I will > not argue that that interpretation is unreasonable. However, I also won't > bother to expend effort to support that interpretation in Gecko. Well, TBH, I think your interpretation is (currently) unreasonable. However, the BRs/EVGs (or, failing that, the Mozilla CA Policy) could be updated so that your interpretation becomes the correct interpretation. > let's all try to think about what's the best thing to do to improve users' > safety online and spend time doing those things. +1, but please don't take the CAs by surprise!
You need to log in before you can comment on or make changes to this bug.