Closed
Bug 1007891
Opened 10 years ago
Closed 7 years ago
Some sites chaining to Cybertrust root give sec_error_ocsp_malformed_response when mozilla::pkix on and OCSP enforced
Categories
(CA Program :: CA Certificate Root Program, task)
CA Program
CA Certificate Root Program
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mwobensmith, Assigned: jeremy.rowley)
References
Details
(Whiteboard: BR Compliance)
Found via automated testing of mozilla::pkix, the following sites don't load with security.OCSP.require=true: https://www.zurich.com/ https://www.zurich.co.uk/ https://www.carive.it/ https://www.cariromagna.it/ https://www.cariri.it/ https://www.bancaprossima.com/ https://www.bancadelladriatico.it/ https://piuscelta.coopfirenze.it/ https://infoeuropa.eurocid.pt/
Reporter | ||
Updated•10 years ago
|
Blocks: mozilla::pkix-beta
I'm getting old responses from all of these except the last one, which throws a server error.
Reporter | ||
Comment 2•10 years ago
|
||
I re-tested and now I'm getting sec_error_ocsp_unauthorized_request for all but the last site. The last site gives sec_error_ocsp_malformed_request. This is different than when I examined these sites on 2014-05-07. I'm using the same build I did then - Fx31 2014-05-08 - for comparison. Is this what you see?
Comment 3•10 years ago
|
||
for: https://www.zurich.com/ https://www.zurich.co.uk/ https://www.carive.it/ https://www.cariromagna.it/ https://www.cariri.it/ https://www.bancaprossima.com/ https://www.bancadelladriatico.it/ https://piuscelta.coopfirenze.it/ The cause is the same a very old ocsp response (3.5 months duration producedAt: 2014-05-14 (OK), thisUpdate 2014-04-01 nextUpdate 2014-07-15.) the chain of trust of all these certs is i:/O=Verizon Cybertrust Security/CN=Cybertrust SureServer EV OCSP CA 1 s:/O=Verizon Cybertrust Security/CN=Cybertrust SureServer EV OCSP CA i:/O=Cybertrust, Inc/CN=Cybertrust Global Root 2 s:/O=Cybertrust, Inc/CN=Cybertrust Global Root i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root 3 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root So verizon is not following the BR section 13.2.2 which states that ocsp responses cannot be longer than 10 days. Kathleen: contact the CA? The last server infoeuropa.eurocid.pt has several issues, but the most important is that the ocsp responder is not even in the DNS space. With classic this site also fails to load, so no regression here. This seems like an invalid from FF perspective
Flags: needinfo?(kwilson)
Comment 4•10 years ago
|
||
(In reply to Camilo Viecco (:cviecco) from comment #3) > The cause is the same a very old ocsp response (3.5 months duration > producedAt: 2014-05-14 (OK), thisUpdate 2014-04-01 nextUpdate 2014-07-15.) > the chain of trust of all these certs is > > i:/O=Verizon Cybertrust Security/CN=Cybertrust SureServer EV OCSP CA > 1 s:/O=Verizon Cybertrust Security/CN=Cybertrust SureServer EV OCSP CA > i:/O=Cybertrust, Inc/CN=Cybertrust Global Root > 2 s:/O=Cybertrust, Inc/CN=Cybertrust Global Root > i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > 3 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > > So verizon is not following the BR section 13.2.2 which states that ocsp > responses cannot be longer than 10 days. > > Kathleen: contact the CA? Steven, would you please take a look at this bug?
Flags: needinfo?(kwilson)
Comment 5•10 years ago
|
||
Thank you for this helpful report. I have escalated this and we are actively looking at it. In a quick check, the listed problem sites are also showing errors in FF29 and causing an urgent response. They are not just a mozilla::pkix discovery. In a quick openSSL check, which does not enforce freshness rules, we are seeing more basic errors than response update dates. Before we close this issue, we will ensure that our end entity responses are created within 4 days and valid for no more than 10 days and our subordinate CA responses are current to within 12 months as specified by BR 13.2.2. In parallel to these listed sites with errors, we have sites under the same issuer that have valid and fresh OCSP responses and operate correctly in FF29. We will also work with the operating issuer for the last certificate on the list as we also see several concerns. As we make progress, we will update the status of this bugzilla.
Comment 6•10 years ago
|
||
Camilo, Aren't you confusing end-entity and intermediate CA? The end-entity OCSP response has a lifetime of 12h. The intermediate CA (issuer of the end-entity) has a lifetime of 3 months. Note that previously OCSP responses for the end-entity were not working, that has now been corrected.
Comment 7•10 years ago
|
||
I am making these comments on behalf of my collegue Steve Medin. We have completed our internal investigations of this bug and we have corrected the end-entity OCSP responses. In addition, we have contacted our customer. To urged them to contact again all entities to whom they have issued certificates in order to immediately update to the subordinate CA certificate to the new one, issued last year on Baltimore's certification path. Regarding the OCSP in question, they informed us that the service is unavailable and they are taking immediate actions to make it available. We are continuing to work with our customer towards final resolution. Regards, Damon Hopley (In reply to Steven Medin from comment #5) > Thank you for this helpful report. I have escalated this and we are > actively looking at it. In a quick check, the listed problem sites are also > showing errors in FF29 and causing an urgent response. They are not just a > mozilla::pkix discovery. > > In a quick openSSL check, which does not enforce freshness rules, we are > seeing more basic errors than response update dates. Before we close this > issue, we will ensure that our end entity responses are created within 4 > days and valid for no more than 10 days and our subordinate CA responses are > current to within 12 months as specified by BR 13.2.2. > > In parallel to these listed sites with errors, we have sites under the same > issuer that have valid and fresh OCSP responses and operate correctly in > FF29. > > We will also work with the operating issuer for the last certificate on the > list as we also see several concerns. > > As we make progress, we will update the status of this bugzilla.
Updated•10 years ago
|
Assignee: nobody → kwilson
Component: Security: PSM → CA Certificates
Product: Core → mozilla.org
Version: 31 Branch → other
Updated•10 years ago
|
Summary: With security.OCSP.require=true, some sites display error: sec_error_ocsp_malformed_response → Some sites chaining to Cybertrust root give sec_error_ocsp_malformed_response when mozilla::pkix on and OCSP enforced
Updated•10 years ago
|
No longer blocks: mozilla::pkix-beta
Updated•7 years ago
|
Blocks: BR-Compliance
Whiteboard: BR Compliance
Comment 8•7 years ago
|
||
I believe this bug may be closed as fixed. Jeremy, please confirm.
Assignee: kwilson → jeremy.rowley
Assignee | ||
Comment 9•7 years ago
|
||
Yes - it is fixed.
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: mozilla.org → NSS
Updated•1 year ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•