Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

2017-12-09 Thread Ángel via dev-security-policy
On 2017-12-09 at 08:59 -0700, Wayne Thayer wrote: > It can be confusing even for people following these things. That's where I > think collecting problem reporting info from audited sub-CAs in CCADB would > help. > > For everyone else, finding the correct problem reporting information is > mostly

Re: Verisign signed speedport.ip ?

2017-12-09 Thread Peter Bowen via dev-security-policy
On Sat, Dec 9, 2017 at 11:42 AM, Lewis Resmond via dev-security-policy wrote: > I was researching about some older routers by Telekom, and I found out that > some of them had SSL certificates for their (LAN) configuration interface, > issued by Verisign

Re: Verisign signed speedport.ip ?

2017-12-09 Thread Patrick Figel via dev-security-policy
Until November 11, 2015, publicly-trusted CAs were allowed to issue certificates for internal names and reserved IP addresses. All certificates of this nature had to be revoked by October 1, 2016. More details here: https://cabforum.org/internal-names/ Patrick On 09.12.17 20:42, Lewis Resmond

Verisign signed speedport.ip ?

2017-12-09 Thread Lewis Resmond via dev-security-policy
Hello, I was researching about some older routers by Telekom, and I found out that some of them had SSL certificates for their (LAN) configuration interface, issued by Verisign for the fake-domain "speedport.ip". They (all?) are logged here: https://crt.sh/?q=speedport.ip I wonder, since this

CA generated keys

2017-12-09 Thread Tim Hollebeek via dev-security-policy
Apologies for the new thread. It's difficult for me to reply to messages that were sent before I joined Digicert. With respect to CA generated SSL keys, there are a few points that I feel should be considered. First, third parties who are *not* CAs can run key generation and escrow

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

2017-12-09 Thread Kristian Fiskerstrand via dev-security-policy
On 12/09/2017 01:50 AM, Kurt Roeckx via dev-security-policy wrote: > But it's not obvious to me who to contact to revoke a given > certifiate, and it would be really useful that given a certificate > it would be obvious what to do, who to contact, to get it revoked. Could it be useful to

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

2017-12-09 Thread Tom via dev-security-policy
It can be confusing even for people following these things. That's where I think collecting problem reporting info from audited sub-CAs in CCADB would help. For everyone else, finding the correct problem reporting information is mostly a matter of luck. Perhaps we should require an email address

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

2017-12-09 Thread Wayne Thayer via dev-security-policy
On Sat, Dec 9, 2017 at 7:50 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Sat, 9 Dec 2017 09:51:59 +0100 > Hanno Böck via dev-security-policy > wrote: > > > On Fri, 8 Dec 2017 16:43:48 -0700 > > Wayne Thayer via

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

2017-12-09 Thread Nick Lamb via dev-security-policy
On Sat, 9 Dec 2017 09:51:59 +0100 Hanno Böck via dev-security-policy wrote: > On Fri, 8 Dec 2017 16:43:48 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > The root CA is ultimately responsible for

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

2017-12-09 Thread Hanno Böck via dev-security-policy
On Fri, 8 Dec 2017 16:43:48 -0700 Wayne Thayer via dev-security-policy wrote: > The root CA is ultimately responsible for subordinate CAs it has > signed. I see a problem with that, as this is far from obvious. If a random person discovers a problem