It looks like somebody has been able to get a certificate for one of our domains. Or at least for a subdomain. The funny thing is that because of an configuration failure since May the entry of the DNS servers point to IPs that do no longer have a working DNS server. Is there any technical way to lookup how does the authorisation has worked?
If you believe there’s a breach in your domain (or system), please contact email@example.com.
Also pinging @lestaff to correct me
By the way, it should be possible for you to revoke the certificate(s) yourself, with an ACME client and some work.
After validating a name, a Let’s Encrypt account can currently issue certificates for 30 days. (Unless the CA is prevented from doing so by
CAA records, which CAs cannot reuse for more than 8 hours.) Disabling their ACME account(s) or the authorizations would require intervention by Let’s Encrypt staff.
There’s not really a way for you to do it. Let’s Encrypt staff can search the CA’s logs. I’m not sure how much they can share.
If you’re not very familiar with how ACME or Let’s Encrypt work, there’s general documentation about the validation methods here:
What kind of configuration failure? Were there
NS records pointing to a host or IP under someone else’s control? Could they have then validated the name?
The whois record for the DNS points to 2 subdomains that do not have a runing DNS server on the IPs. For sure the whole domain was not reachable. But somebody was able to get a certificate in between. Strange.
The IPs were under your exclusive control the whole time?
No computer or person could have validated the domain at the time the certificate was issued, or in the previous 30 days?
The TLD’s whois records show that there were zero modifications in that time period?
The TLD doesn’t have a history of compromises?
There is not evidence of BGP hijacking of any of the IP addresses involved in that time period?
Was every zone involved secured with DNSSEC?
I tryed but they let me know that Letsencrypt does not provide “support” via email. Looks like issue of certificates without checking the DNS of the domain owner is normal operation
I did not get a notice that someting on the domain registration has changed in this time frame. But I dont know if there is a service that monitor domain changes of .RU domains. So I can not check this.
The domain of both DNS servers has no DNSSEC. Shame on me. BUT: Both DNS servers have “glue records” and as far as I know these records are secured by DNSSEC. So if Letsencrypt get a request, at least the issuer has to do an DNS lookup on our domain that should be save. Because of a configuration problem at our datacenter the DNS does not running on these IPs. So Letsencrypt would not be able to process the ACME I think. Or is there any other way that does not involve DNS requests of the domain?
Could you please at least provide us your domain name and the certificate issued? (From certificate transparency logs like crt.sh)
Oh sorry! I tryed to avoid this on a public forum because the domain is not really in use. But you are right, it is difficult to investigate if Letsencrypt does not want help with check the logs. So perhaps it would help here https://crt.sh/?q=mail.respondi.ru
That is helpful, thank you for posting your domain.
According to this tool that tracks historical DNS, the domain did have an valid configured A record up until 2019-07-23.
The latest certificate for your domain was issued on 2019-07-11, which is during the period where there was valid DNS.
So from what I can see, it is still possible that Let’s Encrypt performed proper authorization of the order.
Thank you for the hint with historical DNS data. Was really helpfull! The IP (only port 80, 8080 and 443) has been used by one of our developers at this time. I fear he has simply done a lookup of a domain that points to this IP and than used it to get a valid certificate for testing.
For what it’s worth, glue records aren’t signed.
If you’re using DNSSEC, your authoritative
NS records are signed, but the TLD’s non-authoritative
NS records sent in the referral are not.
DS record set is signed, of course.)
$ dig +dnssec +norecurse @b.gtld-servers.net powerdns.com ; <<>> DiG 9.15.1-Ubuntu <<>> +dnssec +norecurse @b.gtld-servers.net powerdns.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35249 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;powerdns.com. IN A ;; AUTHORITY SECTION: powerdns.com. 172800 IN NS pdns-public-ns1.powerdns.com. powerdns.com. 172800 IN NS pdns-public-ns2.powerdns.com. powerdns.com. 86400 IN DS 44030 8 1 B763646757DF621DD1204AD3BFA0675B49BE3279 powerdns.com. 86400 IN DS 44030 8 3 7DD75AE1565051F9563CF8DF976AC99CDCA51E3463019C81BD2BB083 82F3854E powerdns.com. 86400 IN DS 44030 8 2 D4C3D5552B8679FAEEBC317E5F048B614B2E5F607DC57F1553182D49 AB2179F7 powerdns.com. 86400 IN RRSIG DS 8 2 86400 20190925042307 20190918031307 17708 com. lg0t8/7gL2l1D2BsAfRrxY2DyWtCrEIOl/LRcb5hrzin1ACsw9HVQYQw rqbUJqpm0hPPViByKe1WLUG6r5+KTf/CYieBoIuyraNR5VuHJQ4nZyfM X/0u2UA2047nqw7a9tEvk2Kh6d6fOO0/PuUudKwUTsxTekXagvsZM93Q 1m8= ;; ADDITIONAL SECTION: pdns-public-ns1.powerdns.com. 172800 IN A 184.108.40.206 pdns-public-ns1.powerdns.com. 172800 IN AAAA 2a03:b0c0:2:d0::4af:b001 pdns-public-ns2.powerdns.com. 172800 IN AAAA 2604:a880:1:20::132:5001 pdns-public-ns2.powerdns.com. 172800 IN A 220.127.116.11 ;; Query time: 2 msec ;; SERVER: 2001:503:231d::2:30#53(2001:503:231d::2:30) ;; WHEN: Fri Sep 20 17:43:23 UTC 2019 ;; MSG SIZE rcvd: 484 $ dig +dnssec pdns-public-ns1.powerdns.com aaaa ; <<>> DiG 9.15.1-Ubuntu <<>> +dnssec pdns-public-ns1.powerdns.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51596 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;pdns-public-ns1.powerdns.com. IN AAAA ;; ANSWER SECTION: pdns-public-ns1.powerdns.com. 3600 IN AAAA 2a03:b0c0:2:d0::4af:b001 pdns-public-ns1.powerdns.com. 3600 IN RRSIG AAAA 8 3 3600 20191003000000 20190912000000 36021 powerdns.com. blK/UeCoIEg6gu/pMMVI3O++DtSYb3rUr7cU/jFBFAQlwR4XLkUjallS 1n+7otquJylekN6MO3JOVgC4y6edqdAFJEqMI4jZhMyrfFpm1SVBNwtm 93Y0wsZthPOY9sHaP0ixhRRCQXQbYDnHAoECN61TubicuE2hacZ2fXKb aGk= ;; Query time: 68 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Sep 20 17:47:49 UTC 2019 ;; MSG SIZE rcvd: 257
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.