I found following CT log where it seems that Letsencrypt has issued certificate to NXDOMAIN. Is there any clause or poclicy in context to NXDomain which is not open widely ?
https://crt.sh/?id=1913698828 (Precertificate Log)
I also found some recent issue going on in this regards on plesk desk:
What do you mean by NXDOMAIN? That the domain was not registered, or it did not have an A record?
It is certainly possible to issue certificates for domains that do not resolve to an IP address. This is made possible by DNS validation, which you can read about here: https://letsencrypt.org/docs/challenge-types/#dns-01-challenge
We don’t have a way to tell you who issued the certificate, or what validation method they used. But as long as the cnodes.io domain was registered and had a valid nameserver setup at the time the certificate was issued, everything seems fine.
By NXDomain I mean to say that domain does not resolve to particular IP and resolving to its nameserver.
But as certificate is issued to its sub-domain which neither resolves to an IP address(http-01 method) nor has any TXT record entry against _acme-challenge.52d053af02a94944935bc413f80d9c1f.cnodes.io for (DNS verification method.)
_acme-challenge TXT records are usually automatically removed by ACME/Let’s Encrypt clients as soon as the validation process is complete. On average, they only exist for a few seconds to a few minutes.
So their current absence is not really an indicator of anything.
Are you concerned that somebody has issued an unauthorized certificate for your domain? Or is this somebody else’s domain?
It is somebody else’s domain, I was curious about method because for me it seems that they have used something different than http-01 or DNS validation.
Btw, I also found following issue on plesk desk. So I was curious if there is some bug that is letting it happen.
That Plesk issue is about something else - failed renewal attempts for a domain that no longer resolves.
There's no way for an external observer to know this. You could blink and miss the few seconds that the TXT record existed.
How the domain was authorized is between Let's Encrypt and the domain owner.
In general, I think the DNS validation method is likely in these situations because it works fine for names that don’t have publicly-visible A records, unlike the other methods. It’s common that DNS validation for services behind firewalls, on private networks, may not leave any publicly-visible traces in DNS afterward!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.