RE: QuoVadis: Failure to revoke key-compromised certificates within 24 hours

[Stephen Davidson via dev-security-policy]

Hi Ryan:
As you wish.  I will start an incident report.  I do not believe there is a 
compliance failure here.
Regards, Stephen


From: Ryan Sleevi 
Sent: Monday, March 23, 2020 1:57 PM
To: Stephen Davidson 
Cc: Mozilla ; Matt Palmer 

Subject: Re: QuoVadis: Failure to revoke key-compromised certificates within 24 
hours



On Sun, Mar 22, 2020 at 10:03 PM Stephen Davidson via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Hello:
(Apologies if multiple copies of this are received.  The initial send was 
bounced by mdsp.)

Summary:  The certificates noted in Matt Palmer's email below were not in his 
original problem report to QuoVadis.  The certificates he reported were revoked 
in a time manner, and we acknowledged that additional certificates existed 
using the compromised private keys, and that they would be revoked as we 
identified them.  The client was notified of these additional certificates this 
morning which are scheduled to be revoked tonight.

Stephen:

This seems like a valid incident report, and worth following up on in Bugzilla. 
Would you like to open one with your preliminary findings, or would you like me 
to create one to be filled in by QuoVadis?

When it comes to reports of private key compromises, it seems the CA should be 
able to effectively determine the affected certificates (based on SPKI) and 
ensure these are all revoked in a timely fashion. Revoking some of them, but 
not all of them, seems like a BR violation.

It may be there are facts or understanding that's missing, and an incident 
report can help identify those, as well as any root causes or systemic 
mitigations to be deployed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: QuoVadis: Failure to revoke key-compromised certificates within 24 hours

[Stephen Davidson via dev-security-policy]

Hello:
(Apologies if multiple copies of this are received.  The initial send was 
bounced by mdsp.)

Summary:  The certificates noted in Matt Palmer's email below were not in his 
original problem report to QuoVadis.  The certificates he reported were revoked 
in a time manner, and we acknowledged that additional certificates existed 
using the compromised private keys, and that they would be revoked as we 
identified them.  The client was notified of these additional certificates this 
morning which are scheduled to be revoked tonight.

Detail:  An email was received from Matt Palmer on Friday 3/20/2020 at 12:05 AM 
AST reporting compromised private keys for certificates with the following SPKI 
fingerprints.  

6ca25b96d613ed380d4285a450b1737346ab167bb32dcd8289f4bb9445e4521f
051c7cd46144458d508021dd721460b718c8bf5b3a4a20cfb2a7d9dd1f25470e
1737e8265beefa81310deaacb8e957231fc412f1babb5c3b4fe59b0dcae09cf7
1e71edcb5c1c93180ce063cb50e11ea5867638ec8af9f0be39c8da618e41dd3a
37c5f57216ce204702c60587e0f0b6c821f9ebb145129a780512f444e48d79fe
4a92dfd0de92af47e2a0b90f50854316bb07cc58ceb5dd82f817de51f7f8851d
5eef28fbfe1e59b19d4b7db546d95701ea618aef0ed355a2b7f41ebaf5bd07d7
7cf87d510b4bd8899ea9c48956e8fdc6893778c613148fd174d7d1a030797dc1
8317e90c1fcc6398b4530554d298a4d9268ca115806e231a1b7e9744930ea535
84adaec99f45eb4412fab4b4553670c56e920d998d7bc7611193568f88a000a0
91c1befee55e20f7d972aef5305083cf4ee0c9c951e17516fcfe51a372450839
9f6d02a745bfcc796d3270ed25f5a01654d503f464f50d2274c297b58567193e
aad925a8b38626c0b16eeb6e7d4aba571bd4f0d0232a34b9315c1034920b451e
bec0799a6122e65be89ca6f992b62ef71c3d1c566fd7d55438d88a75d685436f
bf7ee7afb5a618e9c67ef188f6ccb9f9a1d909b0e3958ad860b32d4db9cd181d
c39395e26c5401740fc4d3aef6feab97dda7509be7608b4029d7ea08b33c46d5
cc10498794c701df174e7cdeaeaa15c891f9b8ec8babe58138ae3fffc3b720cc
d03309be836b28243fa9a3a97d0e8d85ebe9e4a93e21f8842e261550f042f78d
da443e4cadd5109e564676ade6140a3f18ce36550be207006d672e808f9fdf17
dbc3dc447144ad3d9da596527fa8dfb86e6b4d7dc2919ea5b45c91679e250619
e5582b0b3dc60008bacc27e484934439c1a4ba12b328ed45e9628772ff40f1b8
ea87fa7963c0c97c98a6595da74ce650325eeb8d8d44c1aabf2239db376b3412
ebc35ec62cb941ada24fd53376c80bb76650aeab27e969174978e848adb5a776

A response was sent by QuoVadis to Matt Palmer on Saturday 3/20/2020 at 10:05 
AM AST stating "We acknowledge receipt of your problem report relating to the 
below certificates this morning.
We will investigate the certificates and, if they are found to be noncompliant, 
will revoke the certificates within the stipulated 24 hours.
We will update you with the outcome at that time."

Following investigation and coordination with the customers, the certificates 
were revoked late on Saturday evening.

A response was sent by QuoVadis to Matt Palmer on Saturday 3/21/2020 at 12:07 
AM AST stating "These certificates have been revoked.  In the process, I 
identified some additional certificates which share certain of these Public 
Keys.  I require additional assistance to research this thoroughly, which will 
take place tomorrow.  Additional certificates we identify will be revoked in a 
further 24 hr cycle."
 
We notified the clients of these additional certificates this morning, and they 
will be revoked later tonight.

Many thanks, Stephen
QuoVadis


-Original Message-
From: dev-security-policy  On 
Behalf Of Matt Palmer via dev-security-policy
Sent: Sunday, March 22, 2020 2:23 AM
To: Mozilla 
Subject: QuoVadis: Failure to revoke key-compromised certificates within 24 
hours

Three certificates were reported as having private keys which had been publicly 
disclosed, by e-mailing complia...@quovadisglobal.com at
2020-03-20 03:05:14 UTC.  E-mail was received by a QuoVadis server at
2020-03-20 03:05:18 UTC.  As of 2020-03-22 05:17:37, OCSP still shows all of 
these certificates as being "Good".

The unrevoked certificates are:

https://crt.sh/?id=2605016622
https://crt.sh/?id=1757153116
https://crt.sh/?id=1432019792

Interestingly, at least one other certificate using the same private key as 
each of the above certificates, and also issued by QuoVadis, are now showing as 
revoked, suggesting that (a) QuoVadis did indeed consider the private keys as 
compromised, and (b) there are no caching or delayed publishing issues at play 
here.

- Matt

___
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: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Stephen Davidson via dev-security-policy]

Hello Wayne:



The current wording in section 2.2 "Validation Practices" of the Mozilla Root 
Store Policy says:



2.  For a certificate capable of being used for digitally signing or encrypting 
email messages, the CA takes reasonable measures to verify that the entity 
submitting the request controls the email account associated with the email 
address referenced in the certificate or has been authorized by the email 
account holder to act on the account holder's behalf. The CA's CP/CPS must 
clearly specify the procedure(s) that the CA employs to perform this 
verification.



Does the proposed change seek to replace that text - or to clarify that only 
the CA may perform the verifications?  Something like this ...



2.  For a certificate capable of being used for digitally signing or encrypting 
email messages, the CA takes reasonable measures, which must not be delegated 
to a third party, to verify that the entity submitting the request controls the 
email account associated with the email address referenced in the certificate 
or has been authorized by the email account holder to act on the account 
holder's behalf. The CA's CP/CPS must clearly specify the procedure(s) that the 
CA employs to perform this verification.



Regards, Stephen





-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Monday, May 13, 2019 2:25 PM
To: Mozilla 
Subject: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME 
Certificates



The BRs forbid delegation of domain and IP address validation to third parties. 
However, the BRs don't forbid delegation of email address validation nor do 
they apply to S/MIME certificates.



Delegation of email address validation is already addressed by Mozilla's 
Forbidden Practices [1] state:



"Domain and Email validation are core requirements of the Mozilla's Root Store 
Policy and should always be incorporated into the issuing CA's procedures. 
Delegating this function to 3rd parties is not permitted."



I propose that we move this statement (changing "the Mozilla's Root Store 
Policy" to "this policy") into policy section 2.2 "Validation Practices".



This is https://github.com/mozilla/pkipolicy/issues/175



I will appreciate everyone's input on this proposal.



- Wayne



[1]

https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties

___

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: Discovering unlogged certificates in internet-wide scans

[Stephen Davidson via dev-security-policy]

Hello,



Many thanks for the research - this CT analysis is both fascinating and useful. 
 I'd like to address the following statement:



"Noncompliance already visible from previously logged certificates.  The 
HydrantID SSL ICA G2 CA is trusted by Mozilla (via QuoVadis) for TLS 
authentication, but issues certs intended for IPSEC and which lack serverAuth 
and clientAuth EKU values, which are not BR-compliant (7.1.2.3.f)."



For the sake of reference, here's a link to one of the certificates referenced: 
 https://crt.sh/?id=380352272=zlint.  Responding to the two points:



1. IPSEC EKU

These certificates contain extKeyUsage values for IPSEC due to a customer 
requirement.  This is allowed under the Baseline Requirements:



"7.1.2.3.f. extKeyUsage (required) Either the value id-kp-serverAuth [RFC5280] 
or id-kp-clientAuth [RFC5280] or both values MUST be present. 
id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be 
present."



RFC 2119 defines SHOULD NOT as:



4. SHOULD NOT
This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid 
reasons in particular circumstances when the particular behavior is acceptable 
or even useful, but the full implications should be understood and the case 
carefully weighed before implementing any behavior described with this label.



2.  serverAuth and clientAuth EKU

These certificates are compliant with the BR and contain the required 
extKeyUsage values for both id-kp-serverAuth or id-kp-clientAuth.  It appears 
that zLint "w_sub_cert_eku_extra_values" provides an incomplete message 
relating to the BR 7.1.2.3:



*

* ZLint showing just w_sub_cert_eku_extra_values description

*

$ zlint -list-lints-json | grep 'w_sub_cert_eku_extra_values'

{"name":"w_sub_cert_eku_extra_values","description":"Subscriber Certificate: 
extKeyUsage either the value id-kp-serverAuth or id-kp-clientAuth or both 
values MUST be present.","citation":"BRs: 7.1.2.3"}



This lint shows a warning due to the inclusion of additional extKeyUsage 
values. The zLint description ideally should include the "Other values SHOULD 
NOT be present" portion of the BR to reflect that the warning may be generated 
even though the cert is compliant with the BR.



Regards,

Stephen Davidson

QuoVadis







-Original Message-
From: dev-security-policy 
 
On Behalf Of Tim Smith via dev-security-policy
Sent: Saturday, March 31, 2018 7:15 PM
To: Mozilla 
Subject: Discovering unlogged certificates in internet-wide scans



Hi MDSP,



I went looking for corpuses of certificates that may not have been previously 
logged to CT and found some in the Rapid7 "More SSL" dataset, which captures 
certificates from their scans of non-HTTPS ports for TLS-speaking services.



I wrote up some findings at

http://blog.tim-smith.us/2018/03/moressl-spelunking/.



A few highlights include:

- of the ~10 million certificates in the corpus, about 20% had valid signatures 
and chained to roots included in the Mozilla trust store

- about 50,000 of the 2 million trusted certificates had not previously been 
logged

- about half of the novel certificates were unexpired



There were interesting examples of unexpired, non-compliant, trusted 
certificates chaining to issuers including GoDaddy, NetLock, Logius, and 
Entrust. (I have not taken any action to inform issuers of these findings, 
other than this message and by publishing the certificates to CT logs.)



I welcome any feedback or questions about the value of the approach and the 
findings.



Thanks,

Tim

___

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: Root Store Policy 2.6

[Stephen Davidson via dev-security-policy]

Hello:

 

I am following up regarding Ryan's comments relating to the DarkMatter external 
CAs signed by QuoVadis.  In short:

 

*   QuoVadis has been transparent with Mozilla regarding these CAs 
throughout their existence, with the latest discussion occurring in the autumn 
of 2017 (see below).
*   The DarkMatter CAs have continuous WebTrust audit coverage, while 
initially under our managed operation and subsequently on a standalone basis.
*   The DarkMatter CAs are logging all new trusted SSL in CT.

 

Regards, Stephen

 

 

 

 -Original Message-

From: Stephen Davidson 
Sent: Thursday, October 26, 2017 11:37 AM
To: g...@mozilla.com; Kathleen Wilson 
Cc: Barry Kilborn ; Tony Nagel 

Subject: Moving (root signed) issuing CAs

 

Hello:



 I am writing to provide information on a long-planned project with a QuoVadis 
client, taking into mind the requirements of Section 8.3 of the Mozilla Root 
Store Policy.

 

QuoVadis has worked with DarkMatter for a number of years to build and operate 
a number of CAs – some of which were root signed by QuoVadis roots and hosted 
by QuoVadis in our PKI trustcentre. 

 

Those trusted CAs shown below. DarkMatter has been in control of those CAs, 
although QuoVadis has conducted its own vetting of SSL domains and 
organisations in parallel.  The CAs have been included in QuoVadis’ own 
WebTrust.

 

The plan has always been to eventually relocate those CAs to the UAE, and 
DarkMatter has built a team and prepared facilities.  You probably know their 
team leader, Scott Rea, from the CABF and elsewhere in the PKI world.

 

We believe that Dark Matter are now prepared to transition to being a “publicly 
audited and disclosed” external CA.  We have taken great care to adhere to the 
Mozilla policies in planning this transition.  Following the transition, 
DarkMatter will take control of validation.

 

To summarise:

 

*  EY formally audited phase 1 of the migration and produced a formal audit 
report.  Phase 1 was just a transfer of some key material (that will be used in 
Phase 2).  The CAs continued to operate in QV Bermuda.  DarkMatter CAs were 
included in the 2016 QuoVadis WebTrust.  They will be also named in the 2017 
QuoVadis WebTrust

 

*  DarkMatter have successfully completed a PITA WebTrust (that includes 
the location where the ICAs will be migrated to). 

 

*  Phase 2 of the migration is due to happen soon.  This will be formally 
audited by KPMG (both in Bermuda, CH and UAE) and a report will be produced.
We will have our auditors EY on hand too.

 

*  DarkMatter are finalizing their initial period of time WebTrust reports. 
 Note that these ones won’t mention the CAs to be migrated since the initial 
period ends before the migration will take place. 

 

Going forward, KPMG will conduct – continuous coverage – WebTrust for CAs, 
WebTrust for BR, and WebTrust for EV audits of the DarkMatter CAs.  QuoVadis 
will continue ongoing monitoring and internal audits of their issuance, per 
requirements.

 

We expect the move to occur in the first week of November. We have not been 
aware of discussion regarding a move such as this involved a trusted issuing 
CA.  We are requesting information on the degree of disclosure you would like 
regarding this move.

 

Best regards, Stephen

 

Background on the CA Certs

In April 2016 we had the first DarkMatter ceremony.  These had .ae constraints 
in them.  (They didn’t count as fully technically constrained though).   EY 
audited fully.  These CA were on the QuoVadis WebTrust 2016 report.

 

Original Certs


 

 

 

 


CN

DarkMatter Assured CA

DarkMatter Secure CA

DarkMatter High Assurance CA


Serial

‎05 a6 22 7d 59 9c 95 fe b5 5a 33 3a 9b 6b 54 13 45 12 db 63

‎62 3f 50 d8 3a 11 19 2f 11 16 cc 4b 12 78 5e 12 b0 39 6b 24

‎62 06 5c 48 9e a2 37 c7 c4 0b b7 a3 38 9b 1d 0e b9 b9 a3 58


Valid from

‎Friday, ‎April ‎29, ‎2016 7:53:00 PM

‎Friday, ‎April ‎29, ‎2016 7:45:18 PM

‎Friday, ‎April ‎29, ‎2016 7:38:11 PM


Valid to

‎Monday, ‎April ‎29, ‎2024 7:53:00 PM

‎Monday, ‎April ‎29, ‎2024 7:45:18 PM

‎Monday, ‎April ‎29, ‎2024 7:38:11 PM


Issuer

QuoVadis Root CA 3 G3

QuoVadis Root CA 2 G3

QuoVadis Root CA 2 G3


Sha1 thumb

‎‎6b 6f a6 5b 1b dc 2a 0f 3a 7e 66 b5 90 f9 32 97 b8 eb 56 b9

‎6a 2c 69 17 67 c2 f1 99 9b 8c 02 0c ba b4 47 56 a9 9a 0c 41

‎88 35 43 7d 38 7b bb 1b 58 ff 5a 0f f8 d0 03 d8 fe 04 ae d4


Sha256 thumb

60 F0 66 DC 78 A4 E2 E9 29 A1 C8 ED 10 2E DB 70 7D F0 31 81 F8 2F DF 50 D5 3A 
52 DA C3 55 C6 5B

A0 19 81 1E 43 69 CA 4C 62 AA A8 0A 15 49 61 3E 60 F6 C5 CE D3 83 AF 9D 79 DF 
8F 8F 19 3F 1D FE

E0 A6 70 F4 F1 05 7E 91 79 E9 DB 45 E3 33 CE 37 E3 EE 31 C3 49 9F 1C 58 4A 58 
7B D9 A5 F5 36 40

 

Renewed Certs

In April 2017 we renewed these CAs to remove the .ae constraints.  These CAs 
will be in the QuoVadis WebTrust 2017 report (as well as the 2016 CAs)

 


 

Misissued certificate with improper characters in DNSname

[Stephen Davidson via dev-security-policy]

On Dec 21 at 1715 UST we received a problem report (below) by email to 
complia...@quovadisglobal.com from Alex Gaynor relating to a TLS/SSL 
certificate issued by Swiss Government Public Trust Standard CA 02, a 
technically constrained external CA operated by Bundesamt fuer Informatik und 
Telekommunikation (BIT).

Specifically, a SAN in that certificate included a dNSName that ended with two 
\n characters:
https://crt.sh/?id=282646337=cablinthttps://crt.sh/?id=282646337=cablint

The certificate was revoked by the CA on Dec 22 at 1125 UST.

Upon investigation, the CA reports that the misissuance was the result of 
administrator error during the manual input of the SAN entry.  The misissuance 
will be reported to the CAs external auditors.  The CA has undertaken to add 
linting as part of the issuance of their TLS/SSL certificates.

Thanks to Alex Gaynor for reporting the issue.

Regards,
Stephen Davidson
QuoVadis, a WISeKey company

--

From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Thursday, December 21, 2017 1:15 PM
To: Group - QuoVadis Compliance 
>
Subject: Misissued certificate

Hi,

I'm reporting a misissued certificate from one of your sub CAs: 
https://crt.sh/?id=282646337=cablint

Specifically, one of the dNSNames ends with two newline (\n) chracters, which 
are not valid is a DNS label.

I am requesting you revoke this certificate and provide a post-mortem to MDSP.
___
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

[Stephen Davidson via dev-security-policy]

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=Serveis Publics de Certificacio

RE: Certificates with less than 64 bits of entropy

[Stephen Davidson via dev-security-policy]

Ah, my apologies.

https://bugzilla.mozilla.org/attachment.cgi?id=8898848

Regards, Stephen



From: dev-security-policy 
[dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozilla.org] 
on behalf of Eric Mill via dev-security-policy 
[dev-security-policy@lists.mozilla.org]
Sent: Saturday, August 19, 2017 12:06 PM
To: Stephen Davidson
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with less than 64 bits of entropy

On Fri, Aug 18, 2017 at 12:04 PM, Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> 4)  The list of affected certificates is attached in spreadsheet
> form;  they will be uploaded to CT as well.  You will note that the number
> has declined – Siemens' previous report did not take into account that some
> of the certificates had already previously been revoked for other
> reasons.   The spreadsheet also includes certificates issued during the
> Digicert/Verizon root signing period.
>

Would you mind posting this to a public URL or to a Bugzilla bug? The list
doesn't transmit attachments.

-- Eric


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



--
konklone.com | @konklone <https://twitter.com/konklone>
___
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: Certificates with less than 64 bits of entropy

[Stephen Davidson via dev-security-policy]

Thanks Ryan, and I note your further posting regarding prompt response.  Noting 
your desire for detail, I have hesitated to respond with partial answers as 
both Siemens and QuoVadis are working hard to fix the issues with the Siemens 
CA and to replace the certificates as quickly as possible.

However, I don’t wish to delay getting more information to you, and ask for 
your patience if complete information comes in iterations.

Siemens has previously indicated that the affected certificates are installed 
on high profile websites and infrastructure for Siemen’s group companies around 
the world, and that a rushed revocation would create more damage than could be 
expected from the serial number noncompliance.  

We have been working with Siemens to dramatically advance the date by which the 
affected certificates can be replaced and revoked.  Siemens predicts that the 
vast majority of the certificates can be replaced by September 30, 2017 with 
the few difficult cases following.

Addressing your questions:
1)  The failure was one of process rather than deployed code.  QuoVadis 
made an indepth review of the Siemens CA, policies and practices when we took 
over the rootsigning, just before the BR changes which raised the serial 
entropy requirements.  At that time it was compliant.   QuoVadis formally 
updates Siemens on changes to applicable standards, and the Siemens PKI team 
independently monitors groups like the CABF public and m.d.s.p. lists. Siemens 
were aware of the pending change to 64-bit serials and were prepared to 
implement them.  

I note that at the same time planning was underway to move from the in-house CA 
to an OSS CA – precisely for the reason of easing compliance with the 
increasing pace of change in technical aspects of the BR and other standards, 
such as CT, CAA and serial entropy.  It appears that by oversight, the update 
to bring the inhouse CA to 64-bits was not deployed, and our expectation was 
that the check would be made in the external audit.  The long transition to the 
OSS CA is close to completion.

2)  QuoVadis has a dedicated head of compliance and risk management who, in 
addition to overseeing QuoVadis’ own measures, supervises its external sub-CAs 
including detailed discussions on evolving standards, checks on 
implementations, as well as ongoing monitoring of certificate issuance.  There 
is frequent communication with Siemens and our other root-signed customers.

Siemens has a significant and mature internal audit and external audit regime.  
QuoVadis placed too much reliance on the external ETSI TS 102042 V2.4.1 NCP+ 
DVCP/OVCP audit report for what should have been textbook issues like the 
serial number entropy.  Going forward, QuoVadis will increase the formality of 
notifications regarding BR approved ballots, requiring documented evidence of 
compliance by the effective date, and notification to auditors for scope.

Like many CAs, QuoVadis uses crt.sh/certlint to check certificate issuance 
including for external sub-CAs.  This perhaps led to a false sense of security, 
as certlint does not highlight issues with serial number entropy.  Moreover, 
the fleeting window of visibility in some crt.sh reports may not reveal older 
issues or certificates that have not appeared in CT. QuoVadis is introducing 
routine use of certlint in its own certificate management system, and will 
build an expanded view for our external subCAs (the new Siemens CA will log all 
SSL in CT, and we intend our other external sub-CAs to do so before the Google 
deadline).  

3)  I do not have sufficient information yet to answer your questions 
regarding the auditor’s practices, and cannot comment on Digicert’s (nor 
Verizon’s) previous practices.

4)  The list of affected certificates is attached in spreadsheet form;  
they will be uploaded to CT as well.  You will note that the number has 
declined – Siemens' previous report did not take into account that some of the 
certificates had already previously been revoked for other reasons.   The 
spreadsheet also includes certificates issued during the Digicert/Verizon root 
signing period.

Regards, Stephen

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

RE: Certificates with less than 64 bits of entropy

[Stephen Davidson via dev-security-policy]

Update on Siemens - Certificates with less than 64 bits of entropy
The following is regarding the topic 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/vl5eq0PoJxY 
regarding the “Siemens Issuing CA Internet Server 2016” that is root signed by 
QuoVadis and independently audited and disclosed.

At the time the issue was reported, Siemens agreed to immediately take the CA 
offline, and it remains offline pending resolution.  This was reported to the 
listserv by me on 7/20.

Siemens confirmed a bug in their internally-developed CA software which meant 
it was issuing TLS/SSL with 32bit serial numbers, although the serial numbers 
were non sequential.  Siemens informed their external auditors of the situation.

It was found that 1201 currently valid certificates chained to the QuoVadis 
root were affected.  An additional 137 currently valid certificates were issued 
under the previous "Siemens Issuing CA Internet 2013" chained to a Digicert 
root, noted in an email from Ben Wilson of Digicert yesterday.  In the case of 
the QuoVadis-chained certificates, the certificates are virtually all of one 
year validity with expirations balanced across the calendar months (there are a 
handful of two and three year certificates, similar to the Digicert-chained 
population).  The remaining Digicert-chained certificates all expire by end of 
November 2017.  All certificates were issued to Siemens entities and 
Siemens-controlled domains.

Next steps
Siemens has moved to accelerate the previously planned replacement of their 
existing inhouse CA platform with a well-known open source CA with which 
QuoVadis is well familiar.  QuoVadis and Siemens' auditors are coordinating 
with Siemens to confirm that the new CA configuration meets Baseline 
Requirements.  It is worth noting that some BR controls, particularly related 
to vetting, are imposed by the Siemens certificate lifecycle system which will 
continue to be used with the new CA.  Siemens will not recommence their inhouse 
SSL issuance until the new CA is active and confirmed compliant.  The new CA is 
expected to come online in the second week of September.  Siemens commits to 
logging new SSL from that CA in Certificate Transparency.

Replacement
Although the Siemens PKI is centralised, the certificates are issued to a wide 
variety of Siemens group companies around the world and are used on both 
infrastructure and high traffic websites.  A rushed revocation and replacement 
of these certificates would have a negative business impact on Siemens that 
they believe outweighs the risk of the lower serials entropy (particularly 
given that they are nonsequential).

We propose that Siemens begin the early replacement of the affected 
certificates as soon as the new CA infrastructure is approved, with the goal of 
completing the task by January 31, 2018.  This will include all the affected 
certificates (ie those chained from both the QuoVadis and Digicert roots).  
While Siemens acknowledges that the affected certificates should not have 
occurred, we point out that they will all be replaced far in advance of the 
September 2019 date when industry-wide the last certificates issued before the 
BR change (to larger serial numbers) are scheduled to expire.

We request that Siemens be allowed this expanded scope to conduct an orderly 
replacement of the affected certificates.

Many thanks, Stephen Davidson
QuoVadis

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

RE: dNSName containing '/' / low serial number entropy

[Stephen Davidson via dev-security-policy]

Hello:

Siemens Issuing CA Internet Server 2016 was taken offline upon this report
while Siemens and QuoVadis investigate.  It will not issue certificates
until the problem is resolved.

Kind regards, Stephen Davidson
QuoVadis




-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozi
lla.org] On Behalf Of Charles Reiss via dev-security-policy
Sent: Tuesday, July 18, 2017 7:26 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: dNSName containing '/' / low serial number entropy

https://crt.sh/?id=174827359 is a certificate issued by D-TRUST SSL Class 3
CA 1 2009 containing the DNS SAN 'www.lbv-gis.brandenburg.de/lbvagszit'
(containing a '/') with a notBefore in April 2017.

The certificate also seems to have a short certificate serial number, which
cannot include 64 bits of entropy. Many certificates issued by this CA
appears to use large serial numbers (e.g. [1]). But there are certificates
with much shorter sequential-looking serial numbers with notBefores shortly
before [2] and after [3] this certificate's and as recent as 4 July 2017
[4].

[1] https://crt.sh/?id=137090990 , https://crt.sh/?id=124715040 [2]
https://censys.io/certificates/4445455caca3e9cf2ab2b673304487cb220871aa6d5ac
1bf03827f74609c3646
[3]
https://censys.io/certificates/8d08033efe732e8fb6c2f3257c52b500af991bd1f363f
fd6e29ec1812a943cd9
[4] https://crt.sh/?id=173758922


I did a cursory check on censys.io to see if there were other cases of short
serial numbers in certificates with recent notBefores that are trusted by
Mozilla:

- Digidentity Services CA - G2 (https://crt.sh/?caid=868 ; chains to Staat
der Nederlanden Root CA - G2) has issued certificates which serial numbers
that appear to be of the form 0x1000 + sequential counter with
notBefores as recent as 8 June 2017.

- Siemens Issuing CA Internet Server 2016 (https://crt.sh/?caid=26087 ;
chains to QuoVadis Root CA 2 G3) has issued certificates with 4-byte serial
numbers with notBefores as recent as 11 July 2017, though they do not appear
to be assigned sequentially.

D-Trust and QuoVadis both indicated no problems complying with version
2.4.1 of Mozilla's certificate policies (which requires, among other things,
64 bits of serial number entropy) by 1 June 2017 when they replied to
Mozilla's April CA communication. The Government of the Netherlands
indicated they needed a delay for CPS translation only.

___
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: Certificate with invalid dnsName

[Stephen Davidson via dev-security-policy]

Hello:

Thanks for pointing these out.  Regarding the two problematic certificates
noted below chained to QuoVadis:

Changes were made to our systems last year dealing these very issues, and it
appears that these remaining certificates were not revoked.  They will now
be revoked.  
Leading hyphens and reallywildcards are now rejected by our systems.

Regards, Stephen
QuoVadis


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozi
lla.org] On Behalf Of Charles Reiss via dev-security-policy
Sent: Wednesday, July 19, 2017 10:30 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName

On 07/19/2017 06:03 PM, Tom wrote:
> Following that discovery, I've search for odd (invalid?) DNS names.
> Here is the list of certificated I've found, it may overlap some 
> discovery already reported.
> If I'm correct, theses certificate are not revoked, not expired, and 
> probably trusted by Mozilla (crt.sh issuer are marked trusted by 
> Mozilla, but not all).

Annotating these certs:

> Starting with *:

I believe this cert is presently untrusted by Mozilla due to revocation of
all paths to the Federal PKI:
> https://crt.sh/?id=7211484*eis.aetc.af.mil

chains to StartCom (and all of these from StartCom are minor compared to 
StartCom's other problems):
> https://crt.sh/?id=10714112*g10.net-lab.net

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=48682944*nuvolaitaliana.it

chains to StartCom:
> https://crt.sh/?id=15736178*assets.blog.cn.net.ru
> https://crt.sh/?id=17295812*dev02.calendar42.com
> https://crt.sh/?id=15881220*dev.1septem.ru
> https://crt.sh/?id=15655700*assets.blog.cn.net.ru
> https://crt.sh/?id=17792808*quickbuild.raptorengineering.io


> 
> Starting with -:

chains to QuoVadis:
> https://crt.sh/?id=54285413
> -d1-datacentre-12g-console-2.its.deakin.edu.au

chains to StartCom:
> https://crt.sh/?id=78248795-1ccenter.777chao.com


> 
> Multiple *.:

chains to QuoVadis:
> https://crt.sh/?id=13299376*.*.victoria.ac.nz

I believe this cert is presently trusted by Mozilla only via a 
technically constrained subCA:
> https://crt.sh/?id=44997156*.*.rnd.unicredit.it

chains to Swisscom:
> https://crt.sh/?id=5982951*.*.int.swisscom.ch


> 
> Internals TLD:

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=33626750a1.verizon.test

I believe this cert is presently untrusted by Mozilla due to revocation 
of the relevant subCA:
> https://crt.sh/?id=33123653DAC38997VPN2001A.trmk.corp

chains to Certplus (DocuSign):
> https://crt.sh/?id=42475510naccez.us.areva.corp

I believe these presently lack an unrevoked, unexpired trust path in 
Mozilla:
> https://crt.sh/?id=10621703collaboration.intra.airbusds.corp
> https://crt.sh/?id=48726306zdeasaotn01.dsmain.ds.corp
___
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: New undisclosed intermediates

[Stephen Davidson via dev-security-policy]

Hello:

I acknowledge that QuoVadis Grid ICA2 was missing from the CCADB.  The
omission was human error (my own) when entering a group of issuing CAs into
SalesForce.  Ongoing, when new ICAs are created, the CCADB disclosure is
part of our process.

For the sake of clarity, that ICA is disclosed in our Repository and
included in our WebTrust audit reports.

Regards, Stephen
QuoVadis


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozi
lla.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Monday, June 5, 2017 10:30 AM
To: MozPol 
Subject: New undisclosed intermediates

Happy Monday!

Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
https://crt.sh/mozilla-disclosures#undisclosed

There are four intermediates here, and with exception of the StartCom one,
they were all issued more than a year ago.

As I've expressed before, I find it baffling that this still happens. To
approach this more productively, I'd be very appreciative if someone from a
CA could describe how they approach disclosing intermediates, where it fits
into their process, how they track progress, etc.

Cheers,
Alex
___
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: SHA-1 serverAuth cert issued by HydrantID (QuoVadis) in January 2017

[Stephen Davidson via dev-security-policy]

Incident Report

On February 15, Rob Stradling identified a SHA-1 certificate issued on
January 27, 2017 under the QV hierarchy.

dNSName:  qvsslrca3-v.quovadisglobal.com:
Serial Number:  29:9d:21:5a:7c:0e:16:d4:6b:c4:13:f6:79:72:eb:22:0c:ec:c9:2c
https://crt.sh/?id=83114602

Background

QuoVadis maintains examples of valid, expired, and revoked TLS/SSL
certificates to assist clients and application providers in testing.
"qvsslrca3-v.quovadisglobal.com" is one of those test certificates, and it
was renewed on January 27.

The "HydrantID Client ICA" is managed by QuoVadis, and final RA performed by
QuoVadis.  Due to the non-routine hierarchy, it was not possible to renew
the certificate using our usual Trust/Link interface, which enacts controls
for Baseline Requirements and other standards.  QuoVadis CA administrators,
with multiple authorisations, accessed the Intermediate CA and renewed the
certificate using the same policy under which the expiring certificate was
generated, instead of the current SHA256 policy on the Intermediate CA.

The TLS certificate was provided manually to the Server administrator and
installed on the QuoVadis-operated webserver.

Simply, this was an operator error, exacerbated by the nature of the test
certificate, the non-routine hierarchy, and bypass of the Trust/Link
automated checks against TLS misissuance.

Actions

Following notification, the certificate was immediately revoked (CRL number
is 0D0B).

The SHA1 TLS policy was retired from the Intermediate CA.

QuoVadis has now reviewed all valid TLS certificates under our hierarchies
confirming that no other SHA1 TLS have been issued since January 5, 2016.

At the time of the Baseline Requirements prohibition of SHA1, SHA1 policies
for TLS had been retired on our routinely used hierarchies.  QuoVadis has
confirmed that no SHA1 policies for TLS remain enabled on any QV-operated
Intermediate CAs.  

QuoVadis CA and Server administrators have been advised of additional
procedures to ensure all checks which would normally be carried out on
commercial certificate issuance are adhered to for internal requests.

QuoVadis WebTrust auditors have been informed of the misissuance.

Regards,

Stephen Davidson
QuoVadis Group 



-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozi
lla.org] On Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, February 15, 2017 7:14 PM
To: mozilla-dev-security-pol...@lists.mozilla.org

Subject: SHA-1 serverAuth cert issued by HydrantID (QuoVadis) in January
2017

This currently unrevoked cert has the serverAuth EKU and 
dNSName=qvsslrca3-v.quovadisglobal.com:
https://crt.sh/?id=83114602

Its issuer is trusted for serverAuth by Mozilla:
https://crt.sh/?caid=1333

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
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