
Let's Encrypt appears to issue a certificate for a domain that doesn't exist - 542458
https://twitter.com/beast_fighter/status/834190510642384897
======
jaas
Head of Let's Encrypt here. Our team is looking into this and so far we don't
see any evidence of mis-issuance in our logs. It looks like the domain in
question, 'apple-id-2.com', was registered and DNS resolved for it
successfully at time of issuance. Here is the valid authorization record
including the resolved IP addresses for 'apple-id-2.com':

[https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...](https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6HlvUOSem8bikLUKfXdHdyEfWmHSgPH2CQ)

We can't be sure why the reporter was unable to find a WHOIS record, we can
only confirm that validation properly succeeded at time of issuance.

Update: Squarespace has confirmed that they did register the domain and then
released it after getting a certificate from us.

~~~
walrus01
Since there are a myriad of registrars that can register .com , and it was
apparently registered and domain-validated successfully at the time of cert
issuance. Is there any way that LE can obtain from Verisign a historical copy
of the whois record as it appeared for the domain _at the time it was issued_
, while the domain was live? I'm hoping that verisign keeps such historical
records for expired or deleted domains.

edit: In addition to all of the data currently captured via the ACME client
challenge/response, would it not be a good idea for LetsEncrypt to store a
copy of the 'whois' record for a domain at the time a new cert is issued? In a
worst case scenario for a .com domain, all of the registrant details can be
opaque and hidden behind a privacy proxy, but it _will_ have at least one
functioning authoritative nameserver, and the hostname and IP address of that
authoritative nameserver can be stored forever.

This could help to track down future abuse in the event that large numbers of
suspiciously named domains can all be correlated to a set of common
authoritative nameservers.

~~~
dsp1234
_but it will have at least one functioning authoritative nameserver, and the
hostname and IP address of that authoritative nameserver can be stored
forever._

The authoritative nameserver could have been ns1.apple-id-2.com with an IP of
198.185.159.145, which would not provide any more information than is already
present.

~~~
walrus01
Yes, that's true, it's entirely possible to host the start of authority (SOA)
authoritative DNS for a domain on the same IP that is also an httpd or hosting
a myriad of other services. But if that information was captured at least it
would be known that was the configuration at the time the cert was issued.

edit: there are a number of shady black market things that use very short TTLs
and "fast flux DNS" for phishing and scam traffic relay/proxy purposes. In the
event that a large number of spurious domains were registered and part of a
larger botnet, it's valuable data to know that fast flux is indeed in use, or
rule it out.

[https://www.google.com/search?q=fast+flux+dns+malware&ie=utf...](https://www.google.com/search?q=fast+flux+dns+malware&ie=utf-8&oe=utf-8&client=firefox-b)

------
Keverw
I wonder if maybe someone had that domain and then deleted it. Dynadot(and
probably others) for example lets you delete domains for a partial refund
within a certain limited amount of time - which I think is a neat feature.

I know there are historical whois sites, but as far as I know unless someone
in the past checked for the domain with their service, they'd have no record
of it otherwise. So maybe that would explain how it has a cert for a domain
that currently does not exist and appears to never been registered.

~~~
walrus01
What is unusual is that if someone had it and then deleted it, it doesn't
still show up in the whois records in a 30, 60 or 90 day redemption period.
From dealing with a few .net domains that recently expired and went into
redemption, it takes a long time for a defunct domain to actually disappear
and become re-registerable again by another totally different purchaser.

~~~
Keverw
Redemption period I know of for when domains expire. But if you do the grace
deletion it's pretty much instantly. I was debating on a domain once with
myself, deleted it and then a day or so later registered it again. Usually you
can delete within the first 118 hours on certain tlds.

[https://www.dynadot.com/domain/grace_deletion.html](https://www.dynadot.com/domain/grace_deletion.html)
has some info about it. I'm only familiar with Dynadot because I use them, but
other providers that offer this should have similar information and times.

------
jlgaddis
Summary:

* Domain apple-id-2.com is not currently registered

* Domain apple-id-2.com has (apparently) never been registered

* LetsEncrypt, on 2017-01-03, issued a valid certificate for apple-id-2.com

Since we can't know how validation was successfully performed, all we can do
is speculate. Someone from LetsEncrypt will have to investigate and let us
know. Fortunately, they should have very detailed audit logs for exactly this
purpose.

~~~
eridius
Note: the domain does exist right now. It was registered today, in response to
this event:
[https://twitter.com/jgowdy/status/834524394575720448](https://twitter.com/jgowdy/status/834524394575720448)

~~~
compuguy
Good to hear. The registrar is godaddy though.

------
jwilk
A certificate for apple-id-1.com was acquired on the same day:

[https://crt.sh/?id=72482400](https://crt.sh/?id=72482400)

There's some evidence that apple-id-1.com existed back then:

[https://www.thedailywhois.com/2017-01-03/apple-
id-1.com](https://www.thedailywhois.com/2017-01-03/apple-id-1.com)

------
cperciva
Since let's encrypt gives a certificate to anyone who can make DNS temporarily
resolve to them, it seems like the most plausible answer is that someone
managed to send spoofed DNS responses to let's encrypt.

~~~
dane-pgp
If the CA system is only as secure as the DNS, that means we really need to
increase DNSSEC deployment, and maybe LE should make DNSSEC mandatory for
domains they issue certificates to in this way.

~~~
akerl_
What attack vector would DNSSEC be protecting against?

~~~
dane-pgp
The attack vector DNSSEC would protect against is DNS spoofing by an active
MitM.

That sort of attack might only be possible for nation state adversaries (or
maybe it's not that hard to intercept LE's DNS requests) but I suppose that
for many nation states it would be cheaper just to force a CA operating in
their country to issue them a fraudulent certificate if they wanted to spoof a
specific domain.

~~~
akerl_
It seems like if our attack vector is "a nation state willing and able to
subvert companies operating in their country", DNSSEC and the existing x509
CAs are both equally threatened, with the downside that Chrome/Firefox can't
delist a TLD when somebody discovers the malicious usage

~~~
dane-pgp
Yes, I was indirectly making the point that against such an adversary both
systems are equally threatened (although there may be malicious actors less
capable than a nation state that can spoof a DNS response).

One difference you didn't mention, though, is that with DNSSEC the domain
owner can choose which TLD they register under, whereas it is less common for
a site to specify which CAs are allowed to issue certificates for it
(especially in a way that works if the browser hasn't visited that site yet).

~~~
tialaramex
The mechanism by which sites (well, domains) can specify which CA may issue is
named CAA, it's part of DNS and is an IETF standard.

However, the current Baseline Requirements for trusted CAs don't actually
require them to check CAA unless their declared policies say that they check.
Let's Encrypt's policies say so, as do Symantec's but many others do not.

Gerv (of Mozilla) is trying to get this changed, either by industry agreement
in the BRs, or de facto by changing the Mozilla root programme rules if the
CAs try to block changing this in the BRs or keep stalling too long.

------
syncsynchalt
To summarize, it looks like a misreporting from whois rather than a LE bug or
malfeasance.

------
X-Istence
Domain tasting? Get a cert for it, then it expires?

~~~
Artemis2
I've been wondering how that could be done in a practical way. You'd have to
register domains that people are likely to register in the next 90 days. You
could probably just resell the domains if you were able to predict that.

------
apetresc
As someone who doesn't know much about the inner workings of the whole TLS
stack, why is this surprising? I know in the past I've self-signed
certificates for domains that only existed on my LAN. Why couldn't that be the
case here? Why shouldn't a central signing authority issue certificates for
people's intranets?

~~~
hug
The answer is the same as the reason x509 "works" at all. The CAs don't issue
invalid certs because if they did, they wouldn't be trusted anymore.

In terms of technical limitations, nothing stops any CA from issuing any cert
they want. It's the business consequences that stop them from doing so.

If Let's Encrypt wants to keep themselves on the trusted-root-CA list of
Windows, Chrome, MacOS, et. al., they need to keep their noses clean.

------
daenney
Twitter currently says: "Sorry, that page doesn’t exist!" if you follow the
link.

------
movedx
My guess is they had a localised DNS resolution failure for the domain and
some how hit a web server, or something else, that ticked all the boxes and
granted the certificate. A long shot, though.

~~~
jwilk
If it's possible to tick all the boxes by accident, then the process is
utterly broken.

------
jeffcactus
Looks like it was registered quite recently.

;; ANSWER SECTION: apple-id-2.com. 500 IN A 50.63.202.53

Creation Date: 2017-02-22T21:57:50Z

The cert was issued in January parsed.validity.start 2017-01-03T22:17:00Z

Not totally surprising as I have never seen Let's Encrypt do anything that
could be remotely considered diligence in not doing shady stuff.

~~~
adrianpike
> Not totally surprising as I have never seen Let's Encrypt do anything that
> could be remotely considered diligence in not doing shady stuff.

Mind elaborating? I'm not familiar enough to know what shady stuff they've
done, and I'm a happy user of LE so far. Would love to know more.

~~~
tialaramex
People's general thrust has been that Let's Encrypt's approach means anybody
who can control an FQDN can get a certificate for that FQDN and they don't
like that.

One group object that DV (Domain Validated) certificates which only validate
control over the FQDN just shouldn't exist at all. They believe you should
need to prove a "real world" identity to someone or else not be able to have a
certificate. Obviously that would put HTTPS back to pretty rare, because
proving real world identity costs money and requires some effort, whereas DV
has been completely automated.

Another group are fine with DV, except that they have an objection to
nebulously defined "obviously bad" FQDNs. They argue (and they're not entirely
wrong) that humans try to parse the FQDN for sense, and it leads them astray.
They see microsoft-helpline in the FQDN and conclude it's a Microsoft
helpline, or they see mybank-login-page and figure it's the log in page for
their bank...

Changing either of these things would be a radical policy alteration for the
Web PKI. In the anti-DV group that might actually be seen as a good thing, a
handful of CAs literally don't offer DV, their businesses could actually grow
if DV were abolished.

Right now, the Baseline Requirements which control how a public CA should
behave to stay trusted in the Web PKI, say the CA must have a "High risk" list
which protects some FQDN from being issued without human oversight. Let's
Encrypt do operate such a list and since they have no human oversight if you
hit the list you just can't get a certificate - about once a month somebody
asks on their public forum about such a name, e.g. aa.edu ran into this, so
did some outfit with the same initials as Deutsche Bank. However the BRs don't
specify what must be on the list at all.

I don't happen to think any of this is "shady" on the part of Let's Encrypt,
but some people do.

