Re: Guang Dong Certificate Authority (GDCA) root inclusion request

The updated documents are also posted on the CA's website: https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/ Current audit statements are here: WebTrust CA: https://cert.webtrust.org/ViewSeal?id=2231 WebTrust BR: https://cert.webtrust.org/ViewSeal?id=2232 WebTrust EV SSL:

Re: [EXT] Symantec Update on SubCA Proposal

Just for clarity: (Note: Using ISO date format instead of ambiguous local date format) How many Symantec certs issued prior to 2015-06-01 expire after 2018-06-01, and how does that mesh with the alternative date proposed below: On 18/07/2017 21:37, Steve Medin wrote: Correction: Summary item

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On 07/18/2017 11:57 AM, Hanno Böck wrote: More dotdot-certificates: [snip] via searching censys.io: https://crt.sh/?id=174803642 for *..syntaxafrica.com Issued by GoDaddy in 2016; expires later this year, but revoked (CRL timestamp says a few days after issuance)

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Tue, 18 Jul 2017 21:43:28 +0200 Hanno Böck via dev-security-policy wrote: > It has this commonname: > commonName= .guidedstudies.com > > Well... that's also not a valid hostname... And of course it's not the only one:

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Tue, 18 Jul 2017 19:29:10 + Jeremy Rowley via dev-security-policy wrote: > Some of these certs are really old. Some of them are also not so old and still valid. All from GoDaddy: https://crt.sh/?id=22835635 https://crt.sh/?id=8216255 This one

RE: [EXT] Symantec Update on SubCA Proposal

Correction: Summary item #3 should read: 3. May 1, 2018 a. Single date of distrust of certificates issued prior to 6/1/2016. (changed from August 31,2017 for certificates issued prior to 6/1/2015 and from January 18, 2018 for certificates issued prior to 6/1/2016). > -Original

RE: Certificate with invalid dnsName issued from Baltimore intermediate

Some of these certs are really old. Is there a reason people were using double dot names? Are they all mistakes in the certificate request or is there some logic behind them? -Original Message- From: dev-security-policy

Symantec Update on SubCA Proposal

*Progress Update on SubCA RFP, Partner Selection, and Execution* Since June 1, Symantec has worked in earnest to operationalize the SubCA proposal outlined by Google and Mozilla and discussed in community forums. The core of this proposal is to transfer the authentication and issuance of

Re: Audit Reminder Email Summary

Forwarded Message Subject: Summary of July 2017 Audit Reminder Emails Date: Tue, 18 Jul 2017 19:00:05 + (GMT) Mozilla: Audit Reminder Root Certificates: LuxTrust Global Root 2 Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8777887 Audit Statement Date:

Re: Certificate with invalid dnsName issued from Baltimore intermediate

The "www..*" search is also intersting, I think: https://crt.sh/?dNSName=www..%25 crt.sh IDLogged At ⇧ Not Before IdentityIssuer Name 397448732016-10-02 2012-12-29 www..coinfling.com 386479982016-10-01 2011-03-24

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

> Yes, however I don't think Matthew's concern was about systems owned by the > CA but rather systems proximate to them in the network. For example if the CA > purchases Internet service from a single local Internet Service Provider, the > BRs obviously don't require that this ISP have all the

Re: Certificate with invalid dnsName issued from Baltimore intermediate

More dotdot-certificates: https://crt.sh/?id=34528113 for autodiscover.amphenolcanada..com Expired 2012 issued by Geotrust (aka symantec) https://crt.sh/?id=3478078 for PDC-LIB-WEB1.RBI1.rbi..in Expired 2016 issued by Institute for Development and Research in Banking Technology

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Tue, Jul 18, 2017 at 8:05 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/07/2017 21:27, Nick Lamb wrote: > > On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson wrote: > >> Thank you for bringing this to our attention. We have contacted Intesa >

Re: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

On 18/07/2017 16:44, Rob Stradling wrote: On 18/07/17 15:31, Jakob Bohm via dev-security-policy wrote: On 18/07/2017 16:19, Rob Stradling wrote: On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote: This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which

Re: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

On 18/07/17 15:31, Jakob Bohm via dev-security-policy wrote: On 18/07/2017 16:19, Rob Stradling wrote: On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote: This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which chains up to a Baltimore CyberTrust root,

Re: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

On 18/07/2017 16:19, Rob Stradling wrote: On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote: This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which chains up to a Baltimore CyberTrust root, contains an invalid dnsName of “www.intesasanpaolovita..biz”

Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote: This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which chains up to a Baltimore CyberTrust root, contains an invalid dnsName of “www.intesasanpaolovita..biz” (note the two dots):

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On Tuesday, 18 July 2017 07:45:01 UTC+1, Jakob Bohm wrote: > 1. I believe (though others may know better) that the high general >requirements for the security of CA systems also apply to the >systems performing the validation procedures in question. Yes, however I don't think Matthew's

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

Many of the concerns you list below are already covered in different ways. 1. I believe (though others may know better) that the high general requirements for the security of CA systems also apply to the systems performing the validation procedures in question. 2. For all DV (Domain