On Sat, Dec 9, 2017 at 11:42 AM, Lewis Resmond via dev-security-policy <dev-security-policy@lists.mozilla.org> 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
