7 ms·
Let's Encrypt appears to issue a certificate for a domain that doesn't exist
- jlgaddis 10y agoSummary: * 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.
- devoply 10y agoSounds like a bug. Under normal circumstances the acme would not exist and could not be resolved, and therefore no cert would be created.
- jlgaddis 10y agoThat's what you'd think, right? Apparently not.
- eridius 10y agoNote: 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 10y agoGood to hear. The registrar is godaddy though.
- Keverw 10y agoI 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.
- jlgaddis 10y agoThat might be possible. A lot of these "domain info" sites receive a daily feed from the registries (i.e. Verisign) that include all domain registrations, renewals, etc., so I would think they'd have it in their database even if that happened.
- walrus01 10y agoWhat 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 10y agoRedemption 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.
- movedx 10y agoMy 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 10y agoIf it's possible to tick all the boxes by accident, then the process is utterly broken.
- apetresc 10y agoAs 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?
- mbilker 10y agoI could sign a certificate for 'johndoe.com' without proper verification or I am using it in my local intranet. Let's Encrypt requires external verification to ensure certificates like this one and other miscellaneous certificates are issued.
- hug 10y agoThe 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.
- X-Istence 10y agoDomain tasting? Get a cert for it, then it expires?
- Artemis2 10y agoI'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.
- tialaramex 10y agoBest defence against this, if you're worried, is to wait 24 hours after gaining control of the domain, then check Certificate Transparency monitors for issuance in that domain. (24 hours is the CT Maximum Merge Delay, a correctly operating log promises to be able to reliably and consistently tell the monitors about any certificates logged more than 24 hours ago)
- jwilk 10y agoA 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
- jeffcactus 10y agoLooks 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.
- jwilk 10y agohttps://twitter.com/jgowdy/status/834524394575720448 https://twitter.com/jgowdy/status/834524394575720448 Jeremiah Gowdy "went ahead and bought the domain until someone figures out what's happening."
- adrianpike 10y ago> 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 10y agoPeople'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.
- jaas 10y agoHead 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/uZGv2KXUJ6HlvUOSem8bikLUKfXdHdyEfWmHSgPH2CQ https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl... 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 10y agoSince 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 10y agobut 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.
- cperciva 10y agoSince 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 10y agoIf 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_ 10y agoWhat attack vector would DNSSEC be protecting against?
- dane-pgp 10y agoThe 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_ 10y agoIt 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 10y agoYes, 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).
- syncsynchalt 10y agoTo summarize, it looks like a misreporting from whois rather than a LE bug or malfeasance.
- daenney 10y agoTwitter currently says: "Sorry, that page doesn’t exist!" if you follow the link.
- deleted 10y ago[deleted]