RE: Certificates with subject stateOrProvinceName "Some-State"

[Cristian Garabet via dev-security-policy]

Hi Alex,


Thank you for reporting this issue. The certificate has been revoked. We will provide an incident report after the internal investigation is finished.


Kind regards,
Cristian Garabet 
CISO




Sent from my Samsung Galaxy smartphone.



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

FW: Violations of Baseline Requirements 4.9.10

[Cristian Garabet via dev-security-policy]

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
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

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