Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Violations of Baseline Requirements 4.9.10

1,549 views
Skip to first unread message

Paul Kehrer

unread,
Aug 29, 2017, 9:41:07 AM8/29/17
to mozilla-dev-s...@lists.mozilla.org
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 in...@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 tspn...@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:
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: 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=20d082b1f53252e33cee5991be8650b414f11f3af16a14295c2fee0c9ab558c2
OCSP URI: http://ocsp.catcert.net

DigiCert:

Email sent to rev...@digicert.com

DN: C=CH, L=Zurich, O=ABB, CN=ABB Issuing CA 6
Example cert: https://crt.sh/?id=16963460
OCSP URI: http://aia.pki.abb.com/ocsp

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

DN: DC=com, DC=sanpaoloimi, DC=corp, CN=Intesa Sanpaolo CA Servizi Esterni
Example cert: https://crt.sh/?id=10915119
OCSP URI: http://ocsp.intesasanpaolo.com

DN: DC=com, DC=sanpaoloimi, DC=corp, CN=Intesa Sanpaolo CA Servizi Esterni
Enhanced
Example cert: https://crt.sh/?id=119601976
OCSP URI: http://ocsp.intesasanpaolo.com

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

DigiCert/Wells Fargo Bank, N.A.:

DN: Wells Fargo WellsSecure, OU=Wells Fargo Bank NA, CN=WellsSecure Public
Root Certification Authority 01 G2
Example cert: https://crt.sh/?id=2029493
OCSP URI: http://validator.wellsfargo.com/

DocuSign (OpenTrust/Keynectis)

CCADB does not list an email address. Not CC'd.

DN: C=FR, O=OpenTrust, OU=0002 478217318, CN=OpenTrust CA for AATL G1
Example cert:
https://crt.sh/?q=8e409aaa332930d32acbab3b514c3e116b1b4d8cc6cf3dfc016a05f9c266f597
OCSP URI: http://get-ocsp.certificat.com/opentrustcaforaatlg1

Government of The Netherlands, PKIoverheid (Logius)

Email sent to sup...@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

IdenTrust

CCADB does not list an email address. Not CC'd.

DN: C=US, O=Digital Signature Trust, OU=DST ACES, CN=DST ACES CA X6
Example cert: https://crt.sh/?id=136954
OCSP URI: https://publicsector.ocsp.identrust.com (note this is https as
well)

Izenpe S.A.

CCADB does not list an email address. Not CC'd.

DN: C=ES, O=IZENPE S.A., CN=Izenpe.com
Example cert:
https://crt.sh?q=b08c196a2ed1e84f9892db1b61219ceb642882478f39b08719603d0735fa03d1
OCSP URI: http://ocsp.izenpe.com
OCSP URI: http://ocsp.izenpe.com:8094

PROCERT

CCADB does not list an email address. Not CC'd. However, this is already
under discussion (among other issues) in
https://bugzilla.mozilla.org/show_bug.cgi?id=1391058


DN: emailAddress=cont...@procert.net.ve, L=Chacao, ST=Miranda,
OU=Proveedor de Certificados PROCERT, O=Sistema Nacional de Certificacion
Electronica, C=VE, CN=PSCProcert
Example cert: https://crt.sh/?id=109516168
OCSP URI: http://ura.procert.net.ve/ocsp

SECOM Trust Systems Co. Ltd.

Email sent to ca-su...@ml.secom-sts.co.jp

DN: C=JP, L=Academe, O=National Institute of Informatics, CN=NII Open
Domain CA - G4
Example cert:
https://crt.sh/?q=fc1c83a714148a269d787b4cd306b8f19165f1829b1b280c40315f03f85a9964
OCSP URI: http://niig4.ocsp.secomtrust.net

DN: C=JP, O=CrossTrust, CN=CrossTrust DV CA3
Example cert:
https://crt.sh/?q=525ae2e9fc4901507d30f7f381af765a81bd7276353651594be323205f5c93ef
OCSP URI: http://dvca3.ocsp.crosstrust.net

DN: C=JP, O=CrossTrust, CN=CrossTrust OV CA3
Example cert:
https://crt.sh/?q=1857ba98deb0a30c2f6e5f064381420bae0a3bd1df2b6652a525a66b7030d505
OCSP URI: http://ovca3.ocsp.crosstrust.net

DN: C=JP, O="FreeBit Co.,Ltd.", CN=YourNet SSL for business2
Example cert:
https://crt.sh/?q=70a530cc67a67a1d1b010aad8370609f407d2d91987b59e5f71e51921f58a346
OCSP URI: http://freebitov2.ocsp.secomtrust.net

DN: C=JP, O="FreeBit Co.,Ltd.", CN=YourNet SSL for domain2
Example cert:
https://crt.sh/?q=731421bd0429723c8bb562ea469dba90095e790ed8c22482b32cbcd26f7c4235
OCSP URI: http://freebitdv2.ocsp.secomtrust.net

DN: C=JP, O=FUJIFILM, CN=FUJIFILM Fnet CA - S
Example cert:
https://crt.sh/?q=3e1b4f7a037a7c8d830329b02f91a37405bb369639bebeb777b2b150204b995b
OCSP URI: http://fnetcas.ocsp.secomtrust.net

DN: C=JP, O=Fuji Xerox, CN=Fuji Xerox Xnet CA - S
Example cert:
https://crt.sh/?q=78606d4c88f75e783d39139d664889a4910d7146ae3b1da7b24c81f3df909b39
OCSP URI: http://xnetcas.ocsp.secomtrust.net

DN: C=JP, O=INTEC INC., CN=EINS/PKI Public Certification Authority V2
Example cert:
https://crt.sh/?q=90f07f5ae79e83cf8c75f946df031a165fa2553f3a3d04ae62368f81773a717f
OCSP URI: http://intec.ocsp.secomtrust.net

DN: C=JP, O=INTEC INC., CN=EINS/PKI Public Certification Authority V3
Example cert:
https://crt.sh/?q=ad72b76954165daf1b9021c1fb2b9b648e978dc9862a525a88274ec1b7e9f61f
OCSP URI: http://intec2.ocsp.secomtrust.net

DN: C=JP, O="Japan Registry Services Co., Ltd.", CN=JPRS Domain Validation
Authority - G1
Example cert:
https://crt.sh/?q=22a04b51e2be5e12726357431ee2568d707515c1f3f094123a391acb540acebb
OCSP URI: http://dv.ocsp.pubcert.jprs.jp

DN: C=JP, O="Japan Registry Services Co., Ltd.", CN=JPRS Organization
Validation Authority - G1
Example cert:
https://crt.sh/?q=30748bde0a6fc2802e638511516745141f95c08b8bdf44e69bfb96b0ff2d7ad2
OCSP URI: http://ov.ocsp.pubcert.jprs.jp

DN: C=JP, O=KAGOYA JAPAN Inc., CN=KAGOYA JAPAN Certification Authority
Example cert:
https://crt.sh/?q=5d2c95d1995e2dbce6f6db38eee7fbe5782965b3e24cec3c483761a4b09cf1a2
OCSP URI: http://kagoya.ocsp.secomtrust.net

DN: C=JP, O=KDDI Web Communications Inc., CN=KDDI Web Communications
Certification Authority
Example cert:
https://crt.sh/?q=0edc6f278d94a6a0c58f39169ba369b3e0273813bdad4c43e4a525c73ff9ed66
OCSP URI: http://kddiweb.ocsp.secomtrust.net

DN: C=JP, O="Nijimo, Inc.", CN=FujiSSL Public Certification Authority - G1
Example cert:
https://crt.sh/?q=460d994d73ed6b1db484dac0d525fcb3fbfdd2a0982183788c917c4b1d03d839
OCSP URI: http://nijimo.ocsp.secomtrust.net

DN: C=JP, O=SECOM Trust.net, OU=Security Communication RootCA1
Example cert:
https://crt.sh/?q=c415cebfa3fc2ef3c74092b84265bad64c3fc9994c91177965667d7abee90588
OCSP URI: http://scrootca1.ocsp.secomtrust.net

DN: C=JP, O="SECOM Trust Systems CO.,LTD.", CN=SECOM Passport for Web EV
2.0 CA
Example cert:
https://crt.sh/?q=9cf126826bb66aa8b40cc33ca6410e789982373342218d4fd8d6da7d71a88914
OCSP URI: http://ev2.ocsp.secomtrust.net

DN: C=JP, O="SECOM Trust Systems CO.,LTD.", CN=SECOM Passport for Web EV CA
Example cert:
https://crt.sh/?q=92ad0dd7ae67012cb96b33a96d24207f883af033d587deab402c70644d98e5be
OCSP URI: http://ev.ocsp.secomtrust.net

DN: C=JP, O="SECOM Trust Systems CO.,LTD.", CN=SECOM Passport for Web MH CA
Example cert:
https://crt.sh/?q=06ea91549c4c2d7aaf1b8c4b7c13ca25dc9456b2c187900b7c196a52561d08c0
OCSP URI: http://mh.ocsp.secomtrust.net

DN: C=JP, O="SECOM Trust Systems CO.,LTD.", CN=SECOM Passport for Web SR
3.0 CA
Example cert:
https://crt.sh/?q=625ee6aaca95caf9d8b130bc0ce1903286e90ccf32d014b1410e0fc8ad9a34c2
OCSP URI: http://sr30.ocsp.secomtrust.net

DN: C=JP, O="SECOM Trust Systems CO.,LTD.", OU=Security Communication EV
RootCA1
Example cert:
https://crt.sh/?q=cbe221580a9800b7e4608d21f7d59e539a64d5c3996c722cf2cde908aa89d4ba
OCSP URI: http://evroot.ocsp.secomtrust.net

DN: C=JP, O="SECOM Trust Systems CO.,LTD.", OU=Security Communication
RootCA2
Example cert:
https://crt.sh/?q=7cf75f006ccff8da30d6ea2a2f7c50d0447aa2513ff4a4a37bf292470bba8c85
OCSP URI: http://scrootca2.ocsp.secomtrust.net

DN: C=JP, O=XiPS, CN=XiPS CA2
Example cert:
https://crt.sh/?q=ae7a6dcb4ead3fae08aa340576595bd02261c2e002f016a83374b3a70446cd06
OCSP URI: http://xips2.ocsp.secomtrust.net

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=049462100743d2bcb10780e7c4eb2ce1197a3f8bea7fad5ef9141f008eb1e6ca
OCSP URI: http://ocsp.unicredit.eu/ocsp

Visa

Email sent to PKIP...@visa.com

DN: C=US, O=VISA, OU=Visa International Service Association, CN=Visa
eCommerce Issuing CA
Example cert: https://crt.sh/?id=53550125
OCSP URI: http://ocsp.visa.com/ocsp

-Paul

Stephen Davidson

unread,
Aug 29, 2017, 11:24:40 AM8/29/17
to Paul Kehrer, mozilla-dev-s...@lists.mozilla.org, Barry Kilborn
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 sup...@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=quovadisg...@lists.mozilla.org] on behalf of Paul Kehrer via dev-security-policy [dev-secur...@lists.mozilla.org]
Sent: Tuesday, August 29, 2017 10:41 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Violations of Baseline Requirements 4.9.10

AS Sertifitseerimiskeskuse (SK)

Autoridad de Certificacion Firmaprofesional

Email sent to in...@firmaprofesional.com

CA Disig a.s.

Email sent to tspn...@disig.sk

certSIGN

Email sent to off...@certsign.ro

DigiCert:

Email sent to rev...@digicert.com

DigiCert/Wells Fargo Bank, N.A.:

DocuSign (OpenTrust/Keynectis)

Email sent to sup...@quovadisglobal.com

IdenTrust

Izenpe S.A.

PROCERT

Email sent to ca-su...@ml.secom-sts.co.jp

Symantec / GeoTrust

Visa

Email sent to PKIP...@visa.com

-Paul
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Ben Wilson

unread,
Aug 29, 2017, 12:50:08 PM8/29/17
to Paul Kehrer, mozilla-dev-s...@lists.mozilla.org
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...@gmail.com]
Sent: Tuesday, August 29, 2017 6:48 AM
To: mozilla-dev-s...@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 in...@firmaprofesional.com <mailto:in...@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 tspn...@disig.sk <mailto:tspn...@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>
Email sent to rev...@digicert.com <mailto:rev...@digicert.com>
Email sent to sup...@quovadisglobal.com <mailto:sup...@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



IdenTrust



CCADB does not list an email address. Not CC'd.



DN: C=US, O=Digital Signature Trust, OU=DST ACES, CN=DST ACES CA X6

Example cert: https://crt.sh/?id=136954

OCSP URI: https://publicsector.ocsp.identrust.com (note this is https as well)



Izenpe S.A.



CCADB does not list an email address. Not CC'd.



DN: C=ES, O=IZENPE S.A., CN=Izenpe.com

Example cert: https://crt.sh?q=b08c196a2ed1e84f9892db1b61219ceb642882478f39b08719603d0735fa03d1

OCSP URI: http://ocsp.izenpe.com

OCSP URI: http://ocsp.izenpe.com:8094



PROCERT



CCADB does not list an email address. Not CC'd. However, this is already under discussion (among other issues) in https://bugzilla.mozilla.org/show_bug.cgi?id=1391058





DN: emailAddress=cont...@procert.net.ve <mailto:cont...@procert.net.ve> , L=Chacao, ST=Miranda, OU=Proveedor de Certificados PROCERT, O=Sistema Nacional de Certificacion Electronica, C=VE, CN=PSCProcert

Example cert: https://crt.sh/?id=109516168

OCSP URI: http://ura.procert.net.ve/ocsp



SECOM Trust Systems Co. Ltd.



Email sent to ca-su...@ml.secom-sts.co.jp <mailto:ca-su...@ml.secom-sts.co.jp>
Email sent to PKIP...@visa.com <mailto:PKIP...@visa.com>

Ryan Sleevi

unread,
Aug 29, 2017, 12:51:05 PM8/29/17
to Paul Kehrer, mozilla-dev-security-policy
On Tue, Aug 29, 2017 at 8:47 AM, Paul Kehrer via dev-security-policy <
dev-secur...@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.

iden...@gmail.com

unread,
Aug 29, 2017, 1:05:07 PM8/29/17
to mozilla-dev-s...@lists.mozilla.org
IdenTrust acknowledge this post and will begin reviewing.

Policy Authority PKIoverheid

unread,
Aug 29, 2017, 2:28:44 PM8/29/17
to mozilla-dev-s...@lists.mozilla.org
> 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

Ben Wilson

unread,
Aug 29, 2017, 4:53:44 PM8/29/17
to mozilla-dev-s...@lists.mozilla.org
This CA is technically constrained:



DN: C=CH, L=Zurich, O=ABB, CN=ABB Issuing CA 6





From: Paul Kehrer [mailto:paul.l...@gmail.com]
Sent: Tuesday, August 29, 2017 6:48 AM
To: mozilla-dev-s...@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.



CCADB does not list an email address. Not CC'd.



CCADB does not list an email address. Not CC'd.



DN: C=FR, O=OpenTrust, OU=0002 478217318, CN=OpenTrust CA for AATL G1

Example cert: https://crt.sh/?q=8e409aaa332930d32acbab3b514c3e116b1b4d8cc6cf3dfc016a05f9c266f597

OCSP URI: http://get-ocsp.certificat.com/opentrustcaforaatlg1



Government of The Netherlands, PKIoverheid (Logius)



Email sent to sup...@quovadisglobal.com <mailto:sup...@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



IdenTrust



CCADB does not list an email address. Not CC'd.



DN: C=US, O=Digital Signature Trust, OU=DST ACES, CN=DST ACES CA X6

Example cert: https://crt.sh/?id=136954

OCSP URI: https://publicsector.ocsp.identrust.com (note this is https as well)



Izenpe S.A.



CCADB does not list an email address. Not CC'd.



Symantec / GeoTrust



CCADB does not list an email address. Not CC'd.



DN: C=IT, O=UniCredit S.p.A., CN=UniCredit Subordinate External

Adriano Santoni

unread,
Aug 30, 2017, 2:47:32 AM8/30/17
to dev-secur...@lists.mozilla.org
>>  - 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-secur...@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.

Kurt Roeckx

unread,
Aug 30, 2017, 3:40:26 AM8/30/17
to mozilla-dev-s...@lists.mozilla.org
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

Alex Gaynor

unread,
Aug 30, 2017, 4:29:19 AM8/30/17
to Ben Wilson, mozilla-dev-s...@lists.mozilla.org, Paul Kehrer
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-secur...@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...@gmail.com]
> Sent: Tuesday, August 29, 2017 6:48 AM
> To: mozilla-dev-s...@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.
>
>
>
> CCADB does not list an email address. Not CC'd.
>
>
>
> Example cert: https://crt.sh/?q=3148d57a495fd7bdf4653dfdd3d3c9
> d186547df42e296c4e1b6a7c679179d03f
>
> 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=caa2a1fe7756bd5e227add40c5e068
> 08dc0a79f1e8c93e4bf982df4893b284e4
>
> 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=356a5f4d994e9efa7caefc49176891
> 1d65ec25977465b610e2f29aa4472631c3
>
> 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=20d082b1f53252e33cee5991be8650
> CCADB does not list an email address. Not CC'd.
>
>
>
> DN: C=FR, O=OpenTrust, OU=0002 478217318, CN=OpenTrust CA for AATL G1
>
> Example cert: https://crt.sh/?q=8e409aaa332930d32acbab3b514c3e
> 116b1b4d8cc6cf3dfc016a05f9c266f597
>
> OCSP URI: http://get-ocsp.certificat.com/opentrustcaforaatlg1
>
>
>
> Government of The Netherlands, PKIoverheid (Logius)
>
>
>
> Email sent to sup...@quovadisglobal.com <mailto:support@
> quovadisglobal.com>
>
>
>
> DN: C=NL, O=KPN Corporate Market BV, CN=KPN Corporate Market CSP
> Organisatie CA - G2
>
> Example cert: https://crt.sh/?q=f821a600af00d2fa23f569e00fdf23
> 79bc182920205a6b9b0276733cb2857c15
>
> OCSP URI: http://ocsp2.managedpki.com
>
>
>
> IdenTrust
>
>
>
> CCADB does not list an email address. Not CC'd.
>
>
>
> DN: C=US, O=Digital Signature Trust, OU=DST ACES, CN=DST ACES CA X6
>
> Example cert: https://crt.sh/?id=136954
>
> OCSP URI: https://publicsector.ocsp.identrust.com (note this is https as
> well)
>
>
>
> Izenpe S.A.
>
>
>
> CCADB does not list an email address. Not CC'd.
>
>
>
> 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
>
>
>
> Visa
>
>
>
> Email sent to PKIP...@visa.com <mailto:PKIP...@visa.com>
>
>
>
> DN: C=US, O=VISA, OU=Visa International Service Association, CN=Visa
> eCommerce Issuing CA
>
> Example cert: https://crt.sh/?id=53550125
>
> OCSP URI: http://ocsp.visa.com/ocsp
>
>
>
> -Paul
>
>

Peter Miškovič

unread,
Aug 30, 2017, 4:29:30 AM8/30/17
to paul.l...@gmail.com, mozilla-dev-s...@lists.mozilla.org
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
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: 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=20d082b1f53252e33cee5991be8650b414f11f3af16a14295c2fee0c9ab558c2
Email sent to sup...@quovadisglobal.com<mailto:sup...@quovadisglobal.com>

David Fernandez

unread,
Aug 30, 2017, 4:42:00 AM8/30/17
to mozilla-dev-s...@lists.mozilla.org
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

Paul Kehrer

unread,
Aug 30, 2017, 4:58:34 AM8/30/17
to mozilla-dev-s...@lists.mozilla.org, David Fernandez
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 101010101010101100001101001101
-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 (

David Fernandez

unread,
Aug 30, 2017, 6:25:05 AM8/30/17
to mozilla-dev-s...@lists.mozilla.org
Hi Paul,
thank you for the clarification, I thought you were talking about subordinates.
Regards,

Peter Miškovič

unread,
Aug 30, 2017, 12:29:01 PM8/30/17
to Paul Kehrer, mozilla-dev-s...@lists.mozilla.org

Cristian Garabet

unread,
Aug 30, 2017, 1:02:47 PM8/30/17
to mozilla-dev-s...@lists.mozilla.org
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-s...@lists.mozilla.org<mailto:mozilla-dev-s...@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:

….
…

iden...@gmail.com

unread,
Aug 30, 2017, 6:03:47 PM8/30/17
to mozilla-dev-s...@lists.mozilla.org
IdenTrust has corrected a configuration issue for this OCSP responder.

Paul Kehrer

unread,
Aug 30, 2017, 8:53:58 PM8/30/17
to mozilla-dev-s...@lists.mozilla.org
On August 30, 2017 at 4:53:54 AM, Ben Wilson via dev-security-policy (
dev-secur...@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

Peter Miškovič

unread,
Aug 31, 2017, 1:25:06 AM8/31/17
to Paul Kehrer, mozilla-dev-s...@lists.mozilla.org
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...@gmail.com]
Sent: Tuesday, August 29, 2017 2:48 PM
To: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@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 tspn...@disig.sk<mailto:tspn...@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

Paul Kehrer

unread,
Aug 31, 2017, 4:21:43 AM8/31/17
to mozilla-dev-s...@lists.mozilla.org
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.
CA Disig a.s.

Email sent to tspn...@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
DN: C=CH, L=Zurich, O=ABB, CN=ABB Issuing CA 6
Example cert: https://crt.sh/?id=16963460
OCSP URI: http://aia.pki.abb.com/ocsp
Notes: This CA is technically constrained via NC except under IPv6. The BRs
require IPv6 exclusion to be considered constrained so I believe this is
still an issue at this time.

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
Notes: Per Ben Wilson this CA only issues client certificates. It is,
however, trusted for serverAuth.
IdenTrust (fixed as of 2017-08-31)

DN: C=US, O=Digital Signature Trust, OU=DST ACES, CN=DST ACES CA X6
Example cert: https://crt.sh/?id=136954
OCSP URI: https://publicsector.ocsp.identrust.com (note this is https as
well)
Notes: This is fixed as of 2017-08-31
*Removed from the list as Ryan Sleevi noted the subordinates in question
are technically constrained*

Jakob Bohm

unread,
Aug 31, 2017, 8:09:05 AM8/31/17
to mozilla-dev-s...@lists.mozilla.org
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...@gmail.com]
> Sent: Tuesday, August 29, 2017 2:48 PM
> To: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@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 tspn...@disig.sk<mailto:tspn...@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

Kurt Roeckx

unread,
Aug 31, 2017, 8:17:28 AM8/31/17
to mozilla-dev-s...@lists.mozilla.org
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

David Fernandez

unread,
Aug 31, 2017, 9:17:56 AM8/31/17
to mozilla-dev-s...@lists.mozilla.org
El miércoles, 30 de agosto de 2017, 10:58:34 (UTC+2), Paul Kehrer escribió:
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.

Nick Lamb

unread,
Aug 31, 2017, 12:48:31 PM8/31/17
to mozilla-dev-s...@lists.mozilla.org
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.

加毛 寿

unread,
Sep 1, 2017, 6:09:34 AM9/1/17
to 加毛 寿
※個人情報保護のため、宛先を非表示（ＢＣＣ）にて送信しています。
-----------------------------------------------------

Paul-san,

Thank you for the notice.
We are going to investigate on this matter.

Best regards,
Hisashi Kamo
Secom Trust Systems
> CA Disig a.s.
>
> Email sent to tspn...@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
>
> https://crt.sh/?id=53550125 OCSP URI: http://ocsp.visa.com/ocsp _______________________________________________

Policy Authority PKIoverheid

unread,
Sep 1, 2017, 11:08:58 AM9/1/17
to mozilla-dev-s...@lists.mozilla.org
> 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

Peter Miškovič

unread,
Sep 4, 2017, 5:42:48 AM9/4/17
to Paul Kehrer, mozilla-dev-s...@lists.mozilla.org
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...@gmail.com]
Sent: Tuesday, August 29, 2017 2:48 PM
To: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@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 tspn...@disig.sk<mailto:tspn...@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

Paul Kehrer

unread,
Sep 5, 2017, 4:27:04 AM9/5/17
to mozilla-dev-s...@lists.mozilla.org
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.
CA Disig a.s. (Fixed as of 2017-08-31)

--Data removed for brevity, see older emails for more info

certSIGN (partially resolved)
Government of The Netherlands, PKIoverheid (Logius) (Fixed as of 2017-08-31)

-Data removed for brevity

IdenTrust (fixed as of 2017-08-31)

-Data removed for brevity

Izenpe S.A. (fixed as of 2017-09-05)

-Data removed for brevity

Kathleen Wilson

unread,
Sep 8, 2017, 12:28:05 PM9/8/17
to mozilla-dev-s...@lists.mozilla.org
I'm going to file the Bugzilla Bugs for each of these CAs, as follows.

==
Bug Summary: <CA Name>: 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

Jonathan Rudenberg

unread,
Sep 8, 2017, 12:50:16 PM9/8/17
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org

> On Sep 8, 2017, at 12:27, Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> 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.

Kathleen Wilson

unread,
Sep 8, 2017, 2:16:32 PM9/8/17
to mozilla-dev-s...@lists.mozilla.org
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



Paul Kehrer

unread,
Sep 8, 2017, 8:18:56 PM9/8/17
to mozilla-dev-s...@lists.mozilla.org
On September 9, 2017 at 2:16:38 AM, Kathleen Wilson via dev-security-policy
(dev-secur...@lists.mozilla.org) wrote:

Bugs filed…

<snip>

~

Thanks,
Kathleen


Thank you very much Kathleen! If I receive additional responses I will
update the bugs directly.

-Paul

Ben Wilson

unread,
Sep 8, 2017, 9:37:27 PM9/8/17
to Paul Kehrer, mozilla-dev-s...@lists.mozilla.org
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

mihkelt...@gmail.com

unread,
Sep 14, 2017, 10:15:53 AM9/14/17
to mozilla-dev-s...@lists.mozilla.org

> 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

Ben Wilson

unread,
Nov 14, 2017, 5:51:20 PM11/14/17
to Paul Kehrer, mozilla-dev-s...@lists.mozilla.org
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



Paul Kehrer

unread,
Nov 14, 2017, 7:20:12 PM11/14/17
to mozilla-dev-s...@lists.mozilla.org
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.w...@digicert.com)
wrote:
0 new messages