Re: Verisign signed speedport.ip ?

[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 for the fake-domain "speedport.ip".
>
> They (all?) are logged here: https://crt.sh/?q=speedport.ip
>
> I wonder, since this domain and even the TLD is non-existing, how could 
> Verisign sign these? Isn't this violating the rules, if they sign anything 
> just because a router factory tells them to do so?
>
> Although they are all expired since several years, I am interested how this 
> could happen, and if such incidents of signing non-existing domains could 
> still happen today.

Before the CA/Browser Forum Baseline Requirements were created, this
was not explicitly forbidden.  Since approximately July 1, 2012 no new
certificates have been allowed for unqualified names or names for
which the TLD does not exist in the IANA root zone.

So, to answer your questions:

Q: How could Verisign sign these?
A: These were all issued prior to the Baseline Requirements coming into effect

Q: Could [...] such incidents of signing non-existing domains could
still happen today?
A: Not like this.  All Domain Names in certificates now must be Fully
Qualified Domains and the CA must validate that the FQDN falls in a
valid namespace.  It is allowable for me to get a certificate for
nonexistent.home.peterbowen.org, even though that FQDN does not exist,
as I am the registrant of peterbowen.org.

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

Re: Verisign signed speedport.ip ?

[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 via dev-security-policy wrote:
> 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 domain and even the TLD is non-existing, how could 
> Verisign sign these? Isn't this violating the rules, if they sign anything 
> just because a router factory tells them to do so?
> 
> Although they are all expired since several years, I am interested how this 
> could happen, and if such incidents of signing non-existing domains could 
> still happen today.
> ___
> 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

Verisign signed speedport.ip ?

[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 domain and even the TLD is non-existing, how could 
Verisign sign these? Isn't this violating the rules, if they sign anything just 
because a router factory tells them to do so?

Although they are all expired since several years, I am interested how this 
could happen, and if such incidents of signing non-existing domains could still 
happen today.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy