Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)
Thanks Rob! I went through the list and filed a bug for each CA if there wasn't one already open (with one exception that I'm still researching). All open OCSP issues are included in the list at https://wiki.mozilla.org/CA/Incident_Dashboard Wayne On Mon, Dec 11, 2017 at 10:49 PM, Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Some example reports: > > 1. CAs / Responder URLs that are in scope for, but violate, the BR > prohibition on returning a signed a "Good" response for a random serial > number, and are also in scope for Mozilla's consideration: > https://crt.sh/ocsp-responders?trustedExclude=constrained% > 2Cexpired%2Conecrl=Mozilla=Server+Auth > entication=Good > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)
No. It has been prohibited for years in the Baseline Requirements. With an expectation that CAs monitor such requests in light of DigiNotar On Mon, Dec 11, 2017 at 8:54 PM Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Rob Stradling via dev-security-policy < > dev-security-policy@lists.mozilla.org> writes: > > >CAs / Responder URLs that are in scope for, but violate, the BR > prohibition > >on returning a signed a "Good" response for a random serial number > > Isn't that perfectly valid? Despite the misleading name, OCSP's "Good" > just > means "not revoked", and a not-revoked reply to a random serial number is > correct because it's not revoked. > > Peter. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)
Rob Stradling via dev-security-policywrites: >CAs / Responder URLs that are in scope for, but violate, the BR prohibition >on returning a signed a "Good" response for a random serial number Isn't that perfectly valid? Despite the misleading name, OCSP's "Good" just means "not revoked", and a not-revoked reply to a random serial number is correct because it's not revoked. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)
Inspired by Paul Kehrer's research a few months ago, I've added a continuous OCSP Monitoring feature to crt.sh: https://crt.sh/ocsp-responders This page shows the latest results of 3 OCSP checks (performed hourly) against each CA / Responder URL that crt.sh has ever encountered: 1. a GET request for an unexpired certificate. 2. a POST request for an unexpired certificate. 3. a POST request for a randomly-generated serial number. The results can be sorted and filtered in various ways: try editing the form at the top of the page and then clicking "Update"; or try clicking a value in any of the "Response" columns. The "B" (for "Bytes") column lists the size of each HTTP response. Click on any of these values and you'll see the actual OCSP response that crt.sh saw; each OCSP response can be viewed as a hex dump, ASN.1 dump, or in the text form used by "openssl ocsp -resp_text". There are many well behaved Responders, but there's also a wealth of interesting misbehaviours to explore! Some example reports: 1. CAs / Responder URLs that are in scope for, but violate, the BR prohibition on returning a signed a "Good" response for a random serial number, and are also in scope for Mozilla's consideration: https://crt.sh/ocsp-responders?trustedExclude=constrained%2Cexpired%2Conecrl=Mozilla=Server+Authentication=Good 2. All CAs / Responder URLs, sorted by GET response size (largest first): https://crt.sh/ocsp-responders?dir=^=6 3. All CAs / Responder URLs, sorted by GET response time (fastest first): https://crt.sh/ocsp-responders?dir=v=10 (No surprise that Comodo's OCSP Responders are fastest from this particular network perspective ;-) ). 4. All CAs / Responder URLs where 'comodo' is a substring of the Responder URL: https://crt.sh/ocsp-responders?url=%25comodo%25 On 15/11/17 00:19, Paul Kehrer via dev-security-policy wrote: Hi Ben, DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Downloading the issuer (https://crt.sh/?id=8949008) and then running: openssl ocsp -issuer 8949008.crt -serial 101010101010101101010101010 -no_nonce -url http://ocsp.root.cartaodecidadao.pt/publico/ocsp -noverify gives this response: 101010101010101101010101010: good This Update: Nov 14 23:59:47 2017 GMT So this does not appear to be resolved. DN: C=PT, O=SCEE, CN=ECRaizEstado The SCEE root for the Government of Portugal is now responding with unknown/revoked statuses. DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Accredited Certification Authority, CN=MULTICERT Certification Authority 002 Download https://crt.sh/?id=8642581 and run: openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010 -no_nonce -url http://ocsp.multicert.com/ocsp -noverify and openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010 -no_nonce -url http://ocsp.multicert.com/procsp -noverify and the responses are: 101010101010101101010101010: good This Update: Nov 15 00:03:40 2017 GMT Next Update: Nov 15 00:03:40 2017 GMT 101010101010101101010101010: good This Update: Nov 15 00:03:58 2017 GMT Next Update: Nov 15 00:03:58 2017 GMT Not fixed. DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de Certificação 001 (Issuer: https://crt.sh/?id=128496365) openssl ocsp -issuer 128496365.crt -serial 1010101010101010101002101010 -no_nonce -noverify -url http://ocsp.multicert.com/ocsp 1010101010101010101002101010: good This Update: Nov 15 00:15:45 2017 GMT Next Update: Nov 15 00:15:45 2017 GMT Also not fixed. I believe Kathleen has opened bugzilla issues for these so it would probably be good to copy this correspondence there as well. -Paul On November 15, 2017 at 6:50:43 AM, Ben Wilson (ben.wil...@digicert.com) wrote: Could someone re-check Multicert and SCEE? (See below.) They have indicated to us that they have now patched their OCSP responder systems. DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Example cert: https://crt.sh/?id=12729446 OCSP URI: http://ocsp.root.cartaodecidadao.pt/publico/ocsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Accredited Certification Authority, CN=MULTICERT Certification Authority 002 Example cert: https://crt.sh/?id=117934576 OCSP URI: http://ocsp.multicert.com/ocsp OCSP URI: http://ocsp.multicert.com/procsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de Certificação 001 Example cert: https://crt.sh/?id=11653177 OCSP URI: http://ocsp.multicert.com/ocsp DigiCert/Government of Portugal, Sistema de Certificação Electrónica do Estado (SCEE) / Electronic Certification System of the State: DN: C=PT, O=SCEE, CN=ECRaizEstado Example cert: https://crt.sh/?id=8322256 OCSP URI: http://ocsp.ecee.gov.pt -- Rob
RE: Violations of Baseline Requirements 4.9.10
Hi Ben, DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Downloading the issuer (https://crt.sh/?id=8949008) and then running: openssl ocsp -issuer 8949008.crt -serial 101010101010101101010101010 -no_nonce -url http://ocsp.root.cartaodecidadao.pt/publico/ocsp -noverify gives this response: 101010101010101101010101010: good This Update: Nov 14 23:59:47 2017 GMT So this does not appear to be resolved. DN: C=PT, O=SCEE, CN=ECRaizEstado The SCEE root for the Government of Portugal is now responding with unknown/revoked statuses. DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Accredited Certification Authority, CN=MULTICERT Certification Authority 002 Download https://crt.sh/?id=8642581 and run: openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010 -no_nonce -url http://ocsp.multicert.com/ocsp -noverify and openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010 -no_nonce -url http://ocsp.multicert.com/procsp -noverify and the responses are: 101010101010101101010101010: good This Update: Nov 15 00:03:40 2017 GMT Next Update: Nov 15 00:03:40 2017 GMT 101010101010101101010101010: good This Update: Nov 15 00:03:58 2017 GMT Next Update: Nov 15 00:03:58 2017 GMT Not fixed. DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de Certificação 001 (Issuer: https://crt.sh/?id=128496365) openssl ocsp -issuer 128496365.crt -serial 1010101010101010101002101010 -no_nonce -noverify -url http://ocsp.multicert.com/ocsp 1010101010101010101002101010: good This Update: Nov 15 00:15:45 2017 GMT Next Update: Nov 15 00:15:45 2017 GMT Also not fixed. I believe Kathleen has opened bugzilla issues for these so it would probably be good to copy this correspondence there as well. -Paul On November 15, 2017 at 6:50:43 AM, Ben Wilson (ben.wil...@digicert.com) wrote: Could someone re-check Multicert and SCEE? (See below.) They have indicated to us that they have now patched their OCSP responder systems. DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Example cert: https://crt.sh/?id=12729446 OCSP URI: http://ocsp.root.cartaodecidadao.pt/publico/ocsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Accredited Certification Authority, CN=MULTICERT Certification Authority 002 Example cert: https://crt.sh/?id=117934576 OCSP URI: http://ocsp.multicert.com/ocsp OCSP URI: http://ocsp.multicert.com/procsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de Certificação 001 Example cert: https://crt.sh/?id=11653177 OCSP URI: http://ocsp.multicert.com/ocsp DigiCert/Government of Portugal, Sistema de Certificação Electrónica do Estado (SCEE) / Electronic Certification System of the State: DN: C=PT, O=SCEE, CN=ECRaizEstado Example cert: https://crt.sh/?id=8322256 OCSP URI: http://ocsp.ecee.gov.pt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Violations of Baseline Requirements 4.9.10
Could someone re-check Multicert and SCEE? (See below.) They have indicated to us that they have now patched their OCSP responder systems. DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Example cert: https://crt.sh/?id=12729446 OCSP URI: http://ocsp.root.cartaodecidadao.pt/publico/ocsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Accredited Certification Authority, CN=MULTICERT Certification Authority 002 Example cert: https://crt.sh/?id=117934576 OCSP URI: http://ocsp.multicert.com/ocsp OCSP URI: http://ocsp.multicert.com/procsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de Certificação 001 Example cert: https://crt.sh/?id=11653177 OCSP URI: http://ocsp.multicert.com/ocsp DigiCert/Government of Portugal, Sistema de Certificação Electrónica do Estado (SCEE) / Electronic Certification System of the State: DN: C=PT, O=SCEE, CN=ECRaizEstado Example cert: https://crt.sh/?id=8322256 OCSP URI: http://ocsp.ecee.gov.pt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
> AS Sertifitseerimiskeskuse (SK) > > CCADB does not list an email address. Not CC'd. > > DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, > emailAddress=p...@sk.ee > Example cert: > https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f > OCSP URI: http://ocsp.sk.ee/CA Hello, Thank you for your attention to the problem. SK ID Solutions is aware of the OCSP issue and we are already making detailed action plan for resolving the bug reported #1398233. If needed planning is made we will provide also the incident report. Mihkel Tammsalu SK ID Solutions AS Service Manger ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Violations of Baseline Requirements 4.9.10
Hi Paul, In case you're not on the distribution for the DigiCert bug for this, here is my recent post. https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c2 Cheers, Ben -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Paul Kehrer via dev-security-policy Sent: Friday, September 8, 2017 6:19 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Violations of Baseline Requirements 4.9.10 On September 9, 2017 at 2:16:38 AM, Kathleen Wilson via dev-security-policy (dev-security-policy@lists.mozilla.org) wrote: Bugs filed… ~ Thanks, Kathleen Thank you very much Kathleen! If I receive additional responses I will update the bugs directly. -Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
On September 9, 2017 at 2:16:38 AM, Kathleen Wilson via dev-security-policy (dev-security-policy@lists.mozilla.org) wrote: Bugs filed… ~ Thanks, Kathleen Thank you very much Kathleen! If I receive additional responses I will update the bugs directly. -Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
Bugs filed… > > AS Sertifitseerimiskeskuse (SK) > Bug #1398233 > > Autoridad de Certificacion Firmaprofesional > Bug #1398240 > > CA Disig a.s. (Fixed as of 2017-08-31) > Bug #1398242 > > certSIGN (partially resolved) > Bug #1398243 > > Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) > Bug #1398246 > > DigiCert: > Bug #1398269 > > DocuSign (OpenTrust/Keynectis) > Bug #1398247 > > Government of The Netherlands, PKIoverheid (Logius) (Fixed as of 2017-08-31) > Bug #1398251 > > IdenTrust (fixed as of 2017-08-31) > Bug #1398255 > > Izenpe S.A. (fixed as of 2017-09-05) > Bug #1398258 > > PROCERT > Existing Bug: 1391058 > > SECOM Trust Systems Co. Ltd. > Bug #1398259 > > Visa > Bug #1398261 ~ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
> On Sep 8, 2017, at 12:27, Kathleen Wilson via dev-security-policy >wrote: > >> I have updated the list again to note the additional responders fixed (in >> this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly >> less enormous I've also started removing everything but the CA's name when >> I have confirmed that all the reported responders are now properly >> responding to my queries. > > Should I still file a bug for those, so that the incident report is recorded > in Bugzilla? Yes, it will be much easier to track there instead of being buried in this thread. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
I'm going to file the Bugzilla Bugs for each of these CAs, as follows. == Bug Summary: : Non-BR-Compliant OCSP Responders Bug Description: Problems have been found with OCSP responders for this CA, and reported in the mozilla.dev.security.policy forum here: https://groups.google.com/d/msg/mozilla.dev.security.policy/o1MX07iWDco/RuM1NK_0AQAJ As per section 4.9.10 of the BRs, OCSP responders MUST NOT respond with a “good” status for unissued certificates. The effective date for this requirement was 2013-08-01. Please provide an incident report in this bug, as described here: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report == > I have updated the list again to note the additional responders fixed (in > this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly > less enormous I've also started removing everything but the CA's name when > I have confirmed that all the reported responders are now properly > responding to my queries. Should I still file a bug for those, so that the incident report is recorded in Bugzilla? Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
I have updated the list again to note the additional responders fixed (in this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly less enormous I've also started removing everything but the CA's name when I have confirmed that all the reported responders are now properly responding to my queries. AS Sertifitseerimiskeskuse (SK) CCADB does not list an email address. Not CC'd. DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=p...@sk.ee Example cert: https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f OCSP URI: http://ocsp.sk.ee/CA Autoridad de Certificacion Firmaprofesional Email sent to i...@firmaprofesional.com DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 Example cert: https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244 Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC Firmaprofesional - CA1 Example cert: https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - AAPP Example cert: https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7 OCSP URI: http://ocsp.firmaprofesional.com CA Disig a.s. (Fixed as of 2017-08-31) --Data removed for brevity, see older emails for more info certSIGN (partially resolved) Email sent to off...@certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN Enterprise CA Class 3 G2 Example cert: https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 OCSP URI: http://ocsp.certsign.ro Notes: This is fixed as of 2017-08-31 DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c OCSP URI: http://ocsp.certsign.ro Notes: Per Cristian Garabet this will be resolved 2017-09-15 Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) CCADB does not list an email address. Not CC'd. DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions Locals de Catalunya, CN=EC-AL Example cert: https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions Locals de Catalunya, CN=EC-AL Example cert: https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Secretaria d'Administracio i Funcio Publica, CN=EC-SAFP Example cert: https://crt.sh/?q=15d3c7463f477e2627c4c9a158e429abd6bfe63101d6745560a36d1c03363d30 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Universitats i Recerca, CN=EC-UR Example cert: https://crt.sh/?q=7432b4c29e1360668814ec282ad78208cd521e62b8d8d60d5084fdf8daad57cb OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Universitats i Recerca, CN=EC-UR Example cert: https://crt.sh/?q=3148d57a495fd7bdf4653dfdd3d3c9d186547df42e296c4e1b6a7c679179d03f OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio, OU=Vegeu https://www.catcert.net/verCIC-3 (c)05, OU=Universitat Rovira i Virgili, CN=EC-URV Example cert: https://crt.sh/?q=caa2a1fe7756bd5e227add40c5e06808dc0a79f1e8c93e4bf982df4893b284e4 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), OU=Serveis Publics de Certificacio, OU=Vegeu https://www.catcert.net/verarrel (c)03, OU=Jerarquia Entitats de Certificacio Catalanes, CN=EC-ACC Example cert: https://crt.sh/?q=356a5f4d994e9efa7caefc491768911d65ec25977465b610e2f29aa4472631c3 OCSP URI: http://ocsp.catcert.net DN:
RE: Violations of Baseline Requirements 4.9.10
Hi Paul, Problem with OCSP response for RootCA (CA Disig Root R1 and CA Disig Root R2) was fixed on Thursday August 31, 2017. Regards Peter Miskovic From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] Sent: Tuesday, August 29, 2017 2:48 PM To: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Violations of Baseline Requirements 4.9.10 I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." This rule was put in place in the wake of the DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its infrastructure and has been a requirement for over 4 years now. The scan was performed by taking the list of responders (and valid issuer name hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is extremely unlikely to have been issued legitimately. The following OCSP responders appear to be non-compliant with the BRs (they respond GOOD and are not listed as technically constrained by crt.sh) but are embedded in certificates issued in paths that chain up to trusted roots in the Mozilla store. I have grouped them by owner where possible and put notes about whether they've been contacted: CA Disig a.s. Email sent to tspnot...@disig.sk<mailto:tspnot...@disig.sk> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 -Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
> Government of The Netherlands, PKIoverheid (Logius) > > DN: C=NL, O=KPN Corporate Market BV, CN=KPN Corporate Market CSP > Organisatie CA - G2 > Example cert: > https://crt.sh/?q=f821a600af00d2fa23f569e00fdf2379bc182920205a6b9b0276733cb2857c15 > OCSP URI: http://ocsp2.managedpki.com Dear community, My apologies for the delayed response. The last few days we’ve been in close contact with our TSP KPN to identify and remedy this issue. I can confirm that a fix for this issue has been deployed yesterday and that the OCSP responder (OCSP2) in question now responds as expected to these kind of requests. As to Nick’s question about how we and the auditor missed this: KPN switched to another OCSP responder (OCSP3) when BR requirement 4.9.10 became effective. Around that time KPN deployed a software update regarding OCSP2 which was necessary so this responder would also comply with BR requirement 4.9.10. Although the software upgrade took place, the configuration change to the OCSP2 responder was somehow never executed. Nevertheless, all TLS certificates issued after 10/25/2013 should be directing users to OCSP3. That responder was and is compliant with BR 4.9.10 from the effective date. Today we have published a new requirement for our PKIoverheid TSPs regarding audit criteria and scoping. See bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1391864 Result of this new requirement should be that ALL BR requirements are in scope of the audit including a technical requirement like BR 4.9.10. Furthermore, we have formulated a plan to prevent future issues like these, which involves active monitoring of the OCSP responses. Not only because of uptime requirements (that was already monitored), but also input/output validation to confirm OCSP responders are behaving like it should. Said mechanism would probably take the form of a fixed interval query which results would be reported by email to us and (possibly) the sub CA from the PKIoverheid TSP in question. This new measure will be effective no later than 10/1/2017. Please let me know if you have any questions. Best regards, Mark Janssen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
> Government of The Netherlands, PKIoverheid (Logius) > DN: C=NL, O=KPN Corporate Market BV, CN=KPN Corporate Market CSP > Organisatie CA - G2 > Example cert: > https://crt.sh/?q=f821a600af00d2fa23f569e00fdf2379bc182920205a6b9b0276733cb2857c15 > OCSP URI: http://ocsp2.managedpki.com Dear community, My apologies for the delayed response. The last few days we’ve been in close contact with our TSP KPN to identify and remedy this issue. I can confirm that a fix for this issue has been deployed yesterday and that the OCSP responder (OCSP2) in question now responds as expected to these kind of requests. As to Nick’s question about how we and the auditor missed this: KPN switched to another OCSP responder (OCSP3) when BR requirement 4.9.10 became effective. Around that time KPN deployed a software update regarding OCSP2 which was necessary so this responder would also comply with BR requirement 4.9.10. Although the software upgrade took place, the configuration change to the OCSP2 responder was somehow never executed. Nevertheless, all TLS certificates issued after 10/25/2013 should be directing users to OCSP3. That responder was and is compliant with BR 4.9.10 from the effective date. Today we have published a new requirement for PKIoverheid TSPs regarding audit criteria and scoping. See bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1391864 Result of this new requirement should be that ALL BR requirements are in scope of the audit including a technical requirement like BR 4.9.10. Furthermore, we have formulated a plan to prevent future issues like these, which involves active monitoring of the OCSP responses. Not only because of uptime requirements (that was already monitored), but also input/output validation to confirm OCSP responders are behaving like it should. Said mechanism would probably take the form of a fixed interval query which results would be reported by email to us. This new measure will be effective no later than 10/1/2017. Please let me know if you have any questions. Best regards, Mark Janssen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Violations of Baseline Requirements 4.9.10
※個人情報保護のため、宛先を非表示(BCC)にて送信しています。 - Paul-san, Thank you for the notice. We are going to investigate on this matter. Best regards, Hisashi Kamo Secom Trust Systems > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+h-kamo=secom.co...@lists.mozilla.org] On > Behalf Of Paul Kehrer > via dev-security-policy > Sent: Thursday, August 31, 2017 10:02 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Violations of Baseline Requirements 4.9.10 > > I have updated the list below to try to capture all the information provided > in this thread about which responders have been > fixed (and verified using another random serial number), which ones have a > date, and removed the ones that are actually under > technical constraint that I missed. > > I have received several responses from CAs that were CC'd informing me that > they are investigating but until the issues are > resolved or I have a date for resolution I have not noted those > communications below. > > > AS Sertifitseerimiskeskuse (SK) > > CCADB does not list an email address. Not CC'd. > > DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, > emailAddress=p...@sk.ee Example cert: > https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f > OCSP URI: http://ocsp.sk.ee/CA > > Autoridad de Certificacion Firmaprofesional > > Email sent to i...@firmaprofesional.com > > DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 > Example cert: > https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35 > OCSP URI: http://ocsp.firmaprofesional.com > > DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244 > Barcelona, OU=Consulte http://www.firmaprofesional.com, > OU=Jerarquia de Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF > A-62634068, CN=AC Firmaprofesional - CA1 Example > cert: > https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796 > OCSP URI: http://ocsp.firmaprofesional.com > > DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la > Administracion Publica, serialNumber=A62634068, CN=AC > Firmaprofesional - AAPP Example cert: > https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7 > OCSP URI: http://ocsp.firmaprofesional.com > > CA Disig a.s. > > Email sent to tspnot...@disig.sk > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service > Example cert: > https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 > OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service > Example cert: > https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 > OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: > https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 > OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: > https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 > OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 > > certSIGN > > Email sent to off...@certsign.ro > > DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN > Enterprise CA Class 3 G2 Example cert: > https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 > OCSP URI: http://ocsp.certsign.ro > Notes: This is fixed as of 2017-08-31 > > DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert: > https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c > OCSP URI: http://ocsp.certsign.ro > Notes: Per Cristian Garabet this will be resolved 2017-09-15 > > Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) > > CCADB does not list an email address. Not CC'd. > > DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de > la Concepcio 11 08008 Barcelona, OU=Serveis Publics > de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, > OU=Administracions Locals de Catalunya, CN=EC-AL > Example cert: > https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4 > OCSP URI: http://ocsp.catcert.net > > DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de > la Concepcio 11 08008 Barcelona, OU=Serveis Publics > de Certificacio ECV-2, OU=Veg
Re: Violations of Baseline Requirements 4.9.10
Kurt, I think both the past experiences of m.d.s.policy with incidents that went undetected by auditors, and my own personal experience (not as part of the Web PKI) with professional audit firms is that they're not strong on the sort of technical requirements that we've seen here. If the rule says I ought to have annual meeting at which I must keep minutes, the auditors are likely to remember to ask to see the minutes and to identify "did not hold required meetings" as a problem. If the rule says I mustn't issue certs with a "foo" extension it's very unlikely the auditors will inspect any certs - let alone all of them - specifically to check for that extension. This is definitely a limitation that we need to keep in mind and which CAs themselves must keep in mind if relying on audits in their own business - as for example Symantec did. As a rule of thumb, audit is good at identifying certain types of policy problems but not effective for detecting criminality or bugs. If you want to detect those (and we do) you need other measures in place. That said, I would like to see feedback from CAs on why *they* missed this and what they've done to try not to be on the list next time something like this happens. They too need to be aware that passing audit is the low bar, if it's the extent of their goals then Mozilla's root programme probably isn't for them. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
El miércoles, 30 de agosto de 2017, 10:58:34 (UTC+2), Paul Kehrer escribió: > Hi David, > > If you use the cert at https://crt.sh/?id=1616324 as issuer (the root > itself) and run this command: > > openssl ocsp -issuer 1616324.crt -serial 10101010101010111101001101 > -url http://ocsp.izenpe.com -noverify > > You will get back > > This Update: Jun 22 11:06:43 2017 GMT > Next Update: Jun 22 11:06:43 2018 GMT > > Of course, no serverAuth certificates should be issued directly off the > root, but the root is still enabled for that purpose so the responder > should respond UNAUTHORIZED here (UNAUTHORIZED instead of UNKNOWN to allow > the root to stay offline). > > On August 30, 2017 at 4:42:10 PM, David Fernandez via dev-security-policy ( > dev-security-policy@lists.mozilla.org) wrote: > > Hi Paul, > can you provide what you posted, for example attaching the ocsp response. I > mean if I query for a non-existant certificate, I get the following answer: > > openssl ocsp -no_cert_verify -no_signature_verify -issuer SSLEV_IZENPE.cer > -serial 0x295990755083049101712519384020072382191 -url > http://ocsp.izenpe.com > > Response verify OK > 0x295990755083049101712519384020072382191: revoked > This Update: Aug 30 08:36:05 2017 GMT > Next Update: Sep 1 08:36:05 2017 GMT > Reason: certificateHold > Revocation Time: Jan 1 00:00:00 1970 GMT > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy Hi Paul, We have been looking for the same problem in all our IZENPE's Subordinate CAs, and found that the problem was only affecting to our Root. After performing the changes to fix the problem and validations in our Development system, we have fix the problem in our production enviroment a couple of hours ago. Thank you for warning all of us. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
On 2017-08-29 14:47, Paul Kehrer wrote: I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." I have to wonder why you were able to find so many. Is this not covered in the audit? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
On 31/08/2017 07:24, Peter Miškovič wrote: Hi Paul, we found the problem with OCSP response for SubCA R1I1 and SubCA R2I2 and fixed it yesterday afternoon. Problem with OCSP response for RootCA will be fixed to the end of next week. They are offline and there is no real possibility to issue a SSL certificate directly by them even if they are enabled for issuing. Please be aware that the requirement is there to avoid positive responses for fake certificates that were never issued by the real CA (such as in the DigiNotar incident). But I understand the need to use slower, more careful update procedures for root CA related infrastructure. (I don't speak for Mozilla). Regards Peter Miskovic From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] Sent: Tuesday, August 29, 2017 2:48 PM To: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Violations of Baseline Requirements 4.9.10 I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." This rule was put in place in the wake of the DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its infrastructure and has been a requirement for over 4 years now. The scan was performed by taking the list of responders (and valid issuer name hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is extremely unlikely to have been issued legitimately. The following OCSP responders appear to be non-compliant with the BRs (they respond GOOD and are not listed as technically constrained by crt.sh) but are embedded in certificates issued in paths that chain up to trusted roots in the Mozilla store. I have grouped them by owner where possible and put notes about whether they've been contacted: CA Disig a.s. Email sent to tspnot...@disig.sk<mailto:tspnot...@disig.sk> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 -Paul Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
I have updated the list below to try to capture all the information provided in this thread about which responders have been fixed (and verified using another random serial number), which ones have a date, and removed the ones that are actually under technical constraint that I missed. I have received several responses from CAs that were CC'd informing me that they are investigating but until the issues are resolved or I have a date for resolution I have not noted those communications below. AS Sertifitseerimiskeskuse (SK) CCADB does not list an email address. Not CC'd. DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=p...@sk.ee Example cert: https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f OCSP URI: http://ocsp.sk.ee/CA Autoridad de Certificacion Firmaprofesional Email sent to i...@firmaprofesional.com DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 Example cert: https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244 Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC Firmaprofesional - CA1 Example cert: https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - AAPP Example cert: https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7 OCSP URI: http://ocsp.firmaprofesional.com CA Disig a.s. Email sent to tspnot...@disig.sk DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 certSIGN Email sent to off...@certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN Enterprise CA Class 3 G2 Example cert: https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 OCSP URI: http://ocsp.certsign.ro Notes: This is fixed as of 2017-08-31 DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c OCSP URI: http://ocsp.certsign.ro Notes: Per Cristian Garabet this will be resolved 2017-09-15 Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) CCADB does not list an email address. Not CC'd. DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions Locals de Catalunya, CN=EC-AL Example cert: https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions Locals de Catalunya, CN=EC-AL Example cert: https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Secretaria d'Administracio i Funcio Publica, CN=EC-SAFP Example cert: https://crt.sh/?q=15d3c7463f477e2627c4c9a158e429abd6bfe63101d6745560a36d1c03363d30 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Universitats i Recerca, CN=EC-UR Example cert: https://crt.sh/?q=7432b4c29e1360668814ec282ad78208cd521e62b8d8d60d5084fdf8daad57cb OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11
RE: Violations of Baseline Requirements 4.9.10
Hi Paul, we found the problem with OCSP response for SubCA R1I1 and SubCA R2I2 and fixed it yesterday afternoon. Problem with OCSP response for RootCA will be fixed to the end of next week. They are offline and there is no real possibility to issue a SSL certificate directly by them even if they are enabled for issuing. Regards Peter Miskovic From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] Sent: Tuesday, August 29, 2017 2:48 PM To: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Violations of Baseline Requirements 4.9.10 I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." This rule was put in place in the wake of the DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its infrastructure and has been a requirement for over 4 years now. The scan was performed by taking the list of responders (and valid issuer name hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is extremely unlikely to have been issued legitimately. The following OCSP responders appear to be non-compliant with the BRs (they respond GOOD and are not listed as technically constrained by crt.sh) but are embedded in certificates issued in paths that chain up to trusted roots in the Mozilla store. I have grouped them by owner where possible and put notes about whether they've been contacted: CA Disig a.s. Email sent to tspnot...@disig.sk<mailto:tspnot...@disig.sk> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 -Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Violations of Baseline Requirements 4.9.10
On August 30, 2017 at 4:53:54 AM, Ben Wilson via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: This CA is technically constrained: DN: C=CH, L=Zurich, O=ABB, CN=ABB Issuing CA 6 Hi Ben, ABB Intermediate CA 3 (https://crt.sh/?id=7739892), which issued ABB Issuing CA 6, does have a name constraints extension. Unfortunately that NC extension does not comply with BR 7.1.5 because it fails to encode an IPv6 exclusion: The Subordinate CA Certificate MUST also include within excludedSubtrees an iPAddress GeneralName of 32 zero octets (covering the IPv6 address range of ::0/0) This is an interesting edge case since the CA is partially, but not fully constrained. -Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
On Tuesday, August 29, 2017 at 9:41:07 AM UTC-4, Paul Kehrer wrote: > I've recently completed a scan of OCSP responders with a focus on checking > whether they are compliant with BR section 4.9.10's requirement: "Effective > 1 August 2013, OCSP responders for CAs which are not Technically > Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" > status for such certificates." This rule was put in place in the wake of > the DigiNotar incident as an additional method of ensuring the CA is aware > of all issuances in its infrastructure and has been a requirement for over > 4 years now. > > The scan was performed by taking the list of responders (and valid issuer > name hash/issuer key hashes) that Andrew Ayer has aggregated and making an > OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". > This serial is extremely unlikely to have been issued legitimately. > > The following OCSP responders appear to be non-compliant with the BRs (they > respond GOOD and are not listed as technically constrained by crt.sh) but > are embedded in certificates issued in paths that chain up to trusted roots > in the Mozilla store. I have grouped them by owner where possible and put > notes about whether they've been contacted: > > AS Sertifitseerimiskeskuse (SK) > > CCADB does not list an email address. Not CC'd. > > DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, > emailAddress=p...@sk.ee > Example cert: > https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f > OCSP URI: http://ocsp.sk.ee/CA > > Autoridad de Certificacion Firmaprofesional > > Email sent to i...@firmaprofesional.com > > DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 > Example cert: > https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35 > OCSP URI: http://ocsp.firmaprofesional.com > > DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244 > Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de > Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, > CN=AC Firmaprofesional - CA1 > Example cert: > https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796 > OCSP URI: http://ocsp.firmaprofesional.com > > DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la > Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - > AAPP > Example cert: > https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7 > OCSP URI: http://ocsp.firmaprofesional.com > > CA Disig a.s. > > Email sent to tspnot...@disig.sk > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service > Example cert: > https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 > OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service > Example cert: > https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 > OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 > Example cert: > https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 > OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 > Example cert: > https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 > OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 > > certSIGN > > Email sent to off...@certsign.ro > > DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN > Enterprise CA Class 3 G2 > Example cert: > https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 > OCSP URI: http://ocsp.certsign.ro > > DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA > Example cert: > https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c > OCSP URI: http://ocsp.certsign.ro > > Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) > > CCADB does not list an email address. Not CC'd. > > DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge > de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio > ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions > Locals de Catalunya, CN=EC-AL > Example cert: > https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4 > OCSP URI: http://ocsp.catcert.net > > DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge > de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio > ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions > Locals de Catalunya, CN=EC-AL > Example cert: > https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208 > OCSP URI: http://ocsp.catcert.net > > DN:
FW: Violations of Baseline Requirements 4.9.10
Hi Paul, Thank you for feedback. We acknowledge the reported issues. Regarding the OCSP for certSIGN Enterprise CA Class 3 G2 subCA, the problem was due to a misconfiguration and has been fixed today. Regarding the OCSP for certSIGN ROOT CA the problem is due to a software limitation and will be fixed until 15.09.2017. Kind regards, Cristian Garabet From: Paul Kehrer Sent: Tuesday, August 29, 2017 3:47:41 PM (UTC+02:00) Athens, Bucharest To: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Violations of Baseline Requirements 4.9.10 I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." This rule was put in place in the wake of the DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its infrastructure and has been a requirement for over 4 years now. The scan was performed by taking the list of responders (and valid issuer name hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is extremely unlikely to have been issued legitimately. The following OCSP responders appear to be non-compliant with the BRs (they respond GOOD and are not listed as technically constrained by crt.sh) but are embedded in certificates issued in paths that chain up to trusted roots in the Mozilla store. I have grouped them by owner where possible and put notes about whether they've been contacted: …. certSIGN Email sent to off...@certsign.ro<mailto:off...@certsign.ro> DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN Enterprise CA Class 3 G2 Example cert: https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 OCSP URI: http://ocsp.certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c OCSP URI: http://ocsp.certsign.ro … ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Violations of Baseline Requirements 4.9.10
___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
Hi Paul, thank you for the clarification, I thought you were talking about subordinates. Regards, El miércoles, 30 de agosto de 2017, 10:58:34 (UTC+2), Paul Kehrer escribió: > Hi David, > > If you use the cert at https://crt.sh/?id=1616324 as issuer (the root > itself) and run this command: > > openssl ocsp -issuer 1616324.crt -serial 10101010101010111101001101 > -url http://ocsp.izenpe.com -noverify > > You will get back > > This Update: Jun 22 11:06:43 2017 GMT > Next Update: Jun 22 11:06:43 2018 GMT > > Of course, no serverAuth certificates should be issued directly off the > root, but the root is still enabled for that purpose so the responder > should respond UNAUTHORIZED here (UNAUTHORIZED instead of UNKNOWN to allow > the root to stay offline). > > On August 30, 2017 at 4:42:10 PM, David Fernandez via dev-security-policy ( > dev-security-policy@lists.mozilla.org) wrote: > > Hi Paul, > can you provide what you posted, for example attaching the ocsp response. I > mean if I query for a non-existant certificate, I get the following answer: > > openssl ocsp -no_cert_verify -no_signature_verify -issuer SSLEV_IZENPE.cer > -serial 0x295990755083049101712519384020072382191 -url > http://ocsp.izenpe.com > > Response verify OK > 0x295990755083049101712519384020072382191: revoked > This Update: Aug 30 08:36:05 2017 GMT > Next Update: Sep 1 08:36:05 2017 GMT > Reason: certificateHold > Revocation Time: Jan 1 00:00:00 1970 GMT > ___ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
Hi David, If you use the cert at https://crt.sh/?id=1616324 as issuer (the root itself) and run this command: openssl ocsp -issuer 1616324.crt -serial 10101010101010111101001101 -url http://ocsp.izenpe.com -noverify You will get back This Update: Jun 22 11:06:43 2017 GMT Next Update: Jun 22 11:06:43 2018 GMT Of course, no serverAuth certificates should be issued directly off the root, but the root is still enabled for that purpose so the responder should respond UNAUTHORIZED here (UNAUTHORIZED instead of UNKNOWN to allow the root to stay offline). On August 30, 2017 at 4:42:10 PM, David Fernandez via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: Hi Paul, can you provide what you posted, for example attaching the ocsp response. I mean if I query for a non-existant certificate, I get the following answer: openssl ocsp -no_cert_verify -no_signature_verify -issuer SSLEV_IZENPE.cer -serial 0x295990755083049101712519384020072382191 -url http://ocsp.izenpe.com Response verify OK 0x295990755083049101712519384020072382191: revoked This Update: Aug 30 08:36:05 2017 GMT Next Update: Sep 1 08:36:05 2017 GMT Reason: certificateHold Revocation Time: Jan 1 00:00:00 1970 GMT ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
Hi Paul, can you provide what you posted, for example attaching the ocsp response. I mean if I query for a non-existant certificate, I get the following answer: openssl ocsp -no_cert_verify -no_signature_verify -issuer SSLEV_IZENPE.cer -serial 0x295990755083049101712519384020072382191 -url http://ocsp.izenpe.com Response verify OK 0x295990755083049101712519384020072382191: revoked This Update: Aug 30 08:36:05 2017 GMT Next Update: Sep 1 08:36:05 2017 GMT Reason: certificateHold Revocation Time: Jan 1 00:00:00 1970 GMT ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Violations of Baseline Requirements 4.9.10
Hi Paul, thank you for the information. We had yesterday a holiday here in Slovakia. We are starting the investigation of this problem now. Regards. Peter Miskovic From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] Sent: Tuesday, August 29, 2017 2:48 PM To: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Violations of Baseline Requirements 4.9.10 I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." This rule was put in place in the wake of the DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its infrastructure and has been a requirement for over 4 years now. The scan was performed by taking the list of responders (and valid issuer name hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is extremely unlikely to have been issued legitimately. The following OCSP responders appear to be non-compliant with the BRs (they respond GOOD and are not listed as technically constrained by crt.sh) but are embedded in certificates issued in paths that chain up to trusted roots in the Mozilla store. I have grouped them by owner where possible and put notes about whether they've been contacted: AS Sertifitseerimiskeskuse (SK) CCADB does not list an email address. Not CC'd. DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=p...@sk.ee<mailto:p...@sk.ee> Example cert: https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f OCSP URI: http://ocsp.sk.ee/CA Autoridad de Certificacion Firmaprofesional Email sent to i...@firmaprofesional.com<mailto:i...@firmaprofesional.com> DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 Example cert: https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, emailAddress=c...@firmaprofesional.com<mailto:c...@firmaprofesional.com>, L=C/ Muntaner 244 Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC Firmaprofesional - CA1 Example cert: https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - AAPP Example cert: https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7 OCSP URI: http://ocsp.firmaprofesional.com CA Disig a.s. Email sent to tspnot...@disig.sk<mailto:tspnot...@disig.sk> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 certSIGN Email sent to off...@certsign.ro<mailto:off...@certsign.ro> DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN Enterprise CA Class 3 G2 Example cert: https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 OCSP URI: http://ocsp.certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c OCSP URI: http://ocsp.certsign.ro Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) CCADB does not list an email address. Not CC'd. DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions Locals de Catalunya, CN=EC-AL Example cert: https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana
Re: Violations of Baseline Requirements 4.9.10
Hi Ben, I'm not sure it should matter that a CA _does_ only issue client certs -- in the DigiNotar-style situation for which this rule was envisioned, the relevant thing is whether the cert is _capable_ of issuing server certs. Alex On Tue, Aug 29, 2017 at 12:43 PM, Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This CA only issues client certificates: > > > > DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de > Certificação Electrónica do Estado, C=PT > > > > > > Ben Wilson, JD, CISA, CISSP > > VP Compliance > > +1 801 701 9678 > > > > > > From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] > Sent: Tuesday, August 29, 2017 6:48 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Violations of Baseline Requirements 4.9.10 > > > > I've recently completed a scan of OCSP responders with a focus on checking > whether they are compliant with BR section 4.9.10's requirement: "Effective > 1 August 2013, OCSP responders for CAs which are not Technically > Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" > status for such certificates." This rule was put in place in the wake of > the DigiNotar incident as an additional method of ensuring the CA is aware > of all issuances in its infrastructure and has been a requirement for over > 4 years now. > > > > The scan was performed by taking the list of responders (and valid issuer > name hash/issuer key hashes) that Andrew Ayer has aggregated and making an > OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". > This serial is extremely unlikely to have been issued legitimately. > > > > The following OCSP responders appear to be non-compliant with the BRs > (they respond GOOD and are not listed as technically constrained by crt.sh) > but are embedded in certificates issued in paths that chain up to trusted > roots in the Mozilla store. I have grouped them by owner where possible and > put notes about whether they've been contacted: > > > > AS Sertifitseerimiskeskuse (SK) > > > > CCADB does not list an email address. Not CC'd. > > > > DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, > emailAddress=p...@sk.ee <mailto:p...@sk.ee> > > Example cert: https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91e > aeb4f41f3da6394d78b8c43672d43f4f0f > > OCSP URI: http://ocsp.sk.ee/CA > > > > Autoridad de Certificacion Firmaprofesional > > > > Email sent to i...@firmaprofesional.com <mailto:i...@firmaprofesional.com> > > > > DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 > > Example cert: https://crt.sh/?q=cd74198d4c23e4701dea579892321b > 9e4f47a08bd8374710b899aad1495a4b35 > > OCSP URI: http://ocsp.firmaprofesional.com > > > > DN: C=ES, emailAddress=c...@firmaprofesional.com c...@firmaprofesional.com> , L=C/ Muntaner 244 Barcelona, OU=Consulte > http://www.firmaprofesional.com, OU=Jerarquia de Certificacion > Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC > Firmaprofesional - CA1 > > Example cert: https://crt.sh/?q=649d5190f9fff58de60313c2f05983 > 93f9dba05368b1dbfe93ec806015fb8796 > > OCSP URI: http://ocsp.firmaprofesional.com > > > > DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la > Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - > AAPP > > Example cert: https://crt.sh/?q=d4ef928ee32c3838d40e5756b52382 > 9b1dafcd46fd84428ba03d59330a4ae5e7 > > OCSP URI: http://ocsp.firmaprofesional.com > > > > CA Disig a.s. > > > > Email sent to tspnot...@disig.sk <mailto:tspnot...@disig.sk> > > > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification > Service > > Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294 > de19e441dcaa6913627261752199c302a2 > > OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 > > > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification > Service > > Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1 > ce0dcfab170e007e551f63231c76975417 > > OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 > > > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 > > Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df0 > 3a507e346b9716442463ed61106aff6947 > > OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 > > > > DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 > > Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d8 > 7e8421aedd5910b786928b6a1248
Re: Violations of Baseline Requirements 4.9.10
On 2017-08-30 08:46, Adriano Santoni wrote: >> - 2 are technically constrained sub-CAs ( https://crt.sh/?id=147626411 / https://crt.sh/?id=47081615 ) Those two are actually the same certificate; it's not clear to me why they appear twice on crt.sh I didn't look if all the name constrains match, but they're at least in a different order. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
>> - 2 are technically constrained sub-CAs ( https://crt.sh/?id=147626411 / https://crt.sh/?id=47081615 ) Those two are actually the same certificate; it's not clear to me why they appear twice on crt.sh Il 29/08/2017 18:50, Ryan Sleevi via dev-security-policy ha scritto: On Tue, Aug 29, 2017 at 8:47 AM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Symantec / GeoTrust CCADB does not list an email address. Not CC'd. DN: C=IT, O=UniCredit S.p.A., CN=UniCredit Subordinate External Example cert: https://crt.sh/?q=049462100743d2bcb10780e7c4eb2c e1197a3f8bea7fad5ef9141f008eb1e6ca OCSP URI: http://ocsp.unicredit.eu/ocsp Note: There are 7 associated certificates for this CA ( https://crt.sh/?caid=294 ) Of those: 5 are issued by Symantec / GeoTrust: - 1 is expired ( https://crt.sh/?id=9219 ) - 4 are revoked ( https://crt.sh/?id=12722071 / https://crt.sh/?id=6941850 / https://crt.sh/?id=47086214 / https://crt.sh/?id=12165934) 2 are issued by Actalis - 2 are technically constrained sub-CAs ( https://crt.sh/?id=147626411 / https://crt.sh/?id=47081615 ) As they are technically-constrained subordinate CAs, they are (presently) exempted from that MUST requirement. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: Firma crittografica S/MIME ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Violations of Baseline Requirements 4.9.10
This CA is technically constrained: DN: C=CH, L=Zurich, O=ABB, CN=ABB Issuing CA 6 From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] Sent: Tuesday, August 29, 2017 6:48 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Violations of Baseline Requirements 4.9.10 I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." This rule was put in place in the wake of the DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its infrastructure and has been a requirement for over 4 years now. The scan was performed by taking the list of responders (and valid issuer name hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is extremely unlikely to have been issued legitimately. The following OCSP responders appear to be non-compliant with the BRs (they respond GOOD and are not listed as technically constrained by crt.sh) but are embedded in certificates issued in paths that chain up to trusted roots in the Mozilla store. I have grouped them by owner where possible and put notes about whether they've been contacted: AS Sertifitseerimiskeskuse (SK) CCADB does not list an email address. Not CC'd. DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=p...@sk.ee <mailto:p...@sk.ee> Example cert: https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f OCSP URI: http://ocsp.sk.ee/CA Autoridad de Certificacion Firmaprofesional Email sent to i...@firmaprofesional.com <mailto:i...@firmaprofesional.com> DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 Example cert: https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, emailAddress=c...@firmaprofesional.com <mailto:c...@firmaprofesional.com> , L=C/ Muntaner 244 Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC Firmaprofesional - CA1 Example cert: https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - AAPP Example cert: https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7 OCSP URI: http://ocsp.firmaprofesional.com CA Disig a.s. Email sent to tspnot...@disig.sk <mailto:tspnot...@disig.sk> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 certSIGN Email sent to off...@certsign.ro <mailto:off...@certsign.ro> DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN Enterprise CA Class 3 G2 Example cert: https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 OCSP URI: http://ocsp.certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c OCSP URI: http://ocsp.certsign.ro Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) CCADB does not list an email address. Not CC'd. DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions Locals de Catalunya, CN=EC-AL Example cert: https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-08
Re: Violations of Baseline Requirements 4.9.10
> Government of The Netherlands, PKIoverheid (Logius) > > DN: C=NL, O=KPN Corporate Market BV, CN=KPN Corporate Market CSP > Organisatie CA - G2 > Example cert: > https://crt.sh/?q=f821a600af00d2fa23f569e00fdf2379bc182920205a6b9b0276733cb2857c15 > OCSP URI: http://ocsp2.managedpki.com Hi Paul, Thanks for bringing this to our attention! We will look into it asap. Regards, Mark Janssen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
On Tuesday, August 29, 2017 at 12:51:05 PM UTC-4, Ryan Sleevi wrote: > On Tue, Aug 29, 2017 at 8:47 AM, Paul Kehrer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > Symantec / GeoTrust > > > > CCADB does not list an email address. Not CC'd. > > > > DN: C=IT, O=UniCredit S.p.A., CN=UniCredit Subordinate External > > Example cert: > > https://crt.sh/?q=049462100743d2bcb10780e7c4eb2c > > e1197a3f8bea7fad5ef9141f008eb1e6ca > > OCSP URI: http://ocsp.unicredit.eu/ocsp > > > Note: There are 7 associated certificates for this CA ( > https://crt.sh/?caid=294 ) > > Of those: > 5 are issued by Symantec / GeoTrust: > - 1 is expired ( https://crt.sh/?id=9219 ) > - 4 are revoked ( https://crt.sh/?id=12722071 / https://crt.sh/?id=6941850 > / https://crt.sh/?id=47086214 / https://crt.sh/?id=12165934) > 2 are issued by Actalis > - 2 are technically constrained sub-CAs ( https://crt.sh/?id=147626411 / > https://crt.sh/?id=47081615 ) > > As they are technically-constrained subordinate CAs, they are (presently) > exempted from that MUST requirement. IdenTrust acknowledge this post and will begin reviewing. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
On Tue, Aug 29, 2017 at 8:47 AM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Symantec / GeoTrust > > CCADB does not list an email address. Not CC'd. > > DN: C=IT, O=UniCredit S.p.A., CN=UniCredit Subordinate External > Example cert: > https://crt.sh/?q=049462100743d2bcb10780e7c4eb2c > e1197a3f8bea7fad5ef9141f008eb1e6ca > OCSP URI: http://ocsp.unicredit.eu/ocsp Note: There are 7 associated certificates for this CA ( https://crt.sh/?caid=294 ) Of those: 5 are issued by Symantec / GeoTrust: - 1 is expired ( https://crt.sh/?id=9219 ) - 4 are revoked ( https://crt.sh/?id=12722071 / https://crt.sh/?id=6941850 / https://crt.sh/?id=47086214 / https://crt.sh/?id=12165934) 2 are issued by Actalis - 2 are technically constrained sub-CAs ( https://crt.sh/?id=147626411 / https://crt.sh/?id=47081615 ) As they are technically-constrained subordinate CAs, they are (presently) exempted from that MUST requirement. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Violations of Baseline Requirements 4.9.10
This CA only issues client certificates: DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Ben Wilson, JD, CISA, CISSP VP Compliance +1 801 701 9678 From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] Sent: Tuesday, August 29, 2017 6:48 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Violations of Baseline Requirements 4.9.10 I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." This rule was put in place in the wake of the DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its infrastructure and has been a requirement for over 4 years now. The scan was performed by taking the list of responders (and valid issuer name hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is extremely unlikely to have been issued legitimately. The following OCSP responders appear to be non-compliant with the BRs (they respond GOOD and are not listed as technically constrained by crt.sh) but are embedded in certificates issued in paths that chain up to trusted roots in the Mozilla store. I have grouped them by owner where possible and put notes about whether they've been contacted: AS Sertifitseerimiskeskuse (SK) CCADB does not list an email address. Not CC'd. DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=p...@sk.ee <mailto:p...@sk.ee> Example cert: https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f OCSP URI: http://ocsp.sk.ee/CA Autoridad de Certificacion Firmaprofesional Email sent to i...@firmaprofesional.com <mailto:i...@firmaprofesional.com> DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 Example cert: https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, emailAddress=c...@firmaprofesional.com <mailto:c...@firmaprofesional.com> , L=C/ Muntaner 244 Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC Firmaprofesional - CA1 Example cert: https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - AAPP Example cert: https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7 OCSP URI: http://ocsp.firmaprofesional.com CA Disig a.s. Email sent to tspnot...@disig.sk <mailto:tspnot...@disig.sk> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 certSIGN Email sent to off...@certsign.ro <mailto:off...@certsign.ro> DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN Enterprise CA Class 3 G2 Example cert: https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 OCSP URI: http://ocsp.certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c OCSP URI: http://ocsp.certsign.ro Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) CCADB does not list an email address. Not CC'd. DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions Locals de Catalunya, CN=EC-AL Example cert: https://crt.sh/?q=88f6298c5a8cc66cefb8
RE: Violations of Baseline Requirements 4.9.10
Hello: Many thanks. The CA listed for Government of The Netherlands, PKIoverheid (Logius) is operated by KPN Corporate Market not QuoVadis. We will pass on the information to PKIoverheid. Government of The Netherlands, PKIoverheid (Logius) Email sent to supp...@quovadisglobal.com DN: C=NL, O=KPN Corporate Market BV, CN=KPN Corporate Market CSP Organisatie CA - G2 Example cert: https://crt.sh/?q=f821a600af00d2fa23f569e00fdf2379bc182920205a6b9b0276733cb2857c15 OCSP URI: http://ocsp2.managedpki.com Kind regards, Stephen Davidson From: dev-security-policy [dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozilla.org] on behalf of Paul Kehrer via dev-security-policy [dev-security-policy@lists.mozilla.org] Sent: Tuesday, August 29, 2017 10:41 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Violations of Baseline Requirements 4.9.10 I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." This rule was put in place in the wake of the DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its infrastructure and has been a requirement for over 4 years now. The scan was performed by taking the list of responders (and valid issuer name hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is extremely unlikely to have been issued legitimately. The following OCSP responders appear to be non-compliant with the BRs (they respond GOOD and are not listed as technically constrained by crt.sh) but are embedded in certificates issued in paths that chain up to trusted roots in the Mozilla store. I have grouped them by owner where possible and put notes about whether they've been contacted: AS Sertifitseerimiskeskuse (SK) CCADB does not list an email address. Not CC'd. DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=p...@sk.ee Example cert: https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f OCSP URI: http://ocsp.sk.ee/CA Autoridad de Certificacion Firmaprofesional Email sent to i...@firmaprofesional.com DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 Example cert: https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244 Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC Firmaprofesional - CA1 Example cert: https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - AAPP Example cert: https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7 OCSP URI: http://ocsp.firmaprofesional.com CA Disig a.s. Email sent to tspnot...@disig.sk DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 certSIGN Email sent to off...@certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN Enterprise CA Class 3 G2 Example cert: https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 OCSP URI: http://ocsp.certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c OCSP URI: http://ocsp.certsign.ro Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) CCADB does not list an email address. Not CC'd. DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=S
Violations of Baseline Requirements 4.9.10
I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such certificates." This rule was put in place in the wake of the DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its infrastructure and has been a requirement for over 4 years now. The scan was performed by taking the list of responders (and valid issuer name hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is extremely unlikely to have been issued legitimately. The following OCSP responders appear to be non-compliant with the BRs (they respond GOOD and are not listed as technically constrained by crt.sh) but are embedded in certificates issued in paths that chain up to trusted roots in the Mozilla store. I have grouped them by owner where possible and put notes about whether they've been contacted: AS Sertifitseerimiskeskuse (SK) CCADB does not list an email address. Not CC'd. DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=p...@sk.ee Example cert: https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f OCSP URI: http://ocsp.sk.ee/CA Autoridad de Certificacion Firmaprofesional Email sent to i...@firmaprofesional.com DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 Example cert: https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244 Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC Firmaprofesional - CA1 Example cert: https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796 OCSP URI: http://ocsp.firmaprofesional.com DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - AAPP Example cert: https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7 OCSP URI: http://ocsp.firmaprofesional.com CA Disig a.s. Email sent to tspnot...@disig.sk DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2 OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417 OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947 OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1 DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341 OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2 certSIGN Email sent to off...@certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN Enterprise CA Class 3 G2 Example cert: https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355 OCSP URI: http://ocsp.certsign.ro DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c OCSP URI: http://ocsp.certsign.ro Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) CCADB does not list an email address. Not CC'd. DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions Locals de Catalunya, CN=EC-AL Example cert: https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Administracions Locals de Catalunya, CN=EC-AL Example cert: https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208 OCSP URI: http://ocsp.catcert.net DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Secretaria d'Administracio i Funcio Publica, CN=EC-SAFP Example cert: