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

2017-02-15 Thread Rob Stradling via dev-security-policy
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

SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-15 Thread Rob Stradling via dev-security-policy
This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth EKU and CN=hmrcset.trustis.com: https://crt.sh/?id=50773741=cablint It lacks the SAN extension, but that doesn't excuse it from the ban on SHA-1! Its issuer is trusted for serverAuth by Mozilla:

Re: Intermediates Supporting Many EE Certs

2017-02-15 Thread okaphone.elektronika--- via dev-security-policy
On Wednesday, 15 February 2017 18:27:28 UTC+1, Gervase Markham wrote: > On 13/02/17 17:34, okaphone.elektron...@gmail.com wrote: > > Isn't this mostly something that CAs should keep in mind when they > > setup "shop"? > > > > I mean it would be nice to have a way of avoiding that kind of impact

Re: Intermediates Supporting Many EE Certs

2017-02-15 Thread Jakob Bohm via dev-security-policy
On 14/02/2017 22:03, Nick Lamb wrote: On Tuesday, 14 February 2017 17:55:18 UTC, Jakob Bohm wrote: Unfortunately, for these not-quite-web-server things (printers, routers etc.), automating use of the current ACME Let's encrypt protocol with or without hardcoding the Let's Encrypt URL is a

Re: Intermediates Supporting Many EE Certs

2017-02-15 Thread Gervase Markham via dev-security-policy
On 13/02/17 19:22, Jeremy Rowley wrote: > As we tied the intermediate to a specific set of companies (which correlated > roughly to a specific volume of certificates), renewal and pinning were > non-issues. As long as each company was identified under the same umbrella, > an entity renewing,

Re: Intermediates Supporting Many EE Certs

2017-02-15 Thread Gervase Markham via dev-security-policy
On 13/02/17 17:34, okaphone.elektron...@gmail.com wrote: > Isn't this mostly something that CAs should keep in mind when they > setup "shop"? > > I mean it would be nice to have a way of avoiding that kind of impact > of course, but if they think it's best to put all their eggs in one > basket...

Re: Intermediates Supporting Many EE Certs

2017-02-15 Thread Gervase Markham via dev-security-policy
On 13/02/17 16:17, Steve Medin wrote: > Getting all user agents with interest is issuance limits to implement > the CA Issuers form of AIA for dynamic path discovery and educating > server operators to get out of the practice of static chain > installation on servers would make CA rollovers fairly

Re: Suspicious test.com Cert Issued By GlobalSign

2017-02-15 Thread Gervase Markham via dev-security-policy
On 13/02/17 14:34, Doug Beattie wrote: > This was for GlobalSign account used for testing, so it was a > GlobalSIgn employee. Customers are not, nor have they ever been, > permitted to add domains without GlobalSign enforcing the domain > verification process. But currently GlobalSign employees

Re: GoDaddy Misissuance Action Items

2017-02-15 Thread Gervase Markham via dev-security-policy
On 13/02/17 23:13, Santhan Raj wrote: > One thing to highlight here is that the WebTrust audits are performed > against the BRs and not against the root program requirements. This is true, although (apart from the relative importance of domain validation) this is similarly true of many items in