I just did to make my own certificate with local domain .corp.anything.country ( ex. corp.yahoo.com )
network topology was [ router connected to internet - internal dns servers - certbot linux box ( with internal dns servers as resolver ) ) ]
I did make an TXT _acme-challenge record on public available dns servers thought that certbot will use A/B/C etc servers to resolve the txt record - but verification didn’t work
so i put an TXT record _acme-challenge on my local internal dns server - and verification works well for an wildcard certificate.
so i can create an TXT record _acme-challenge in my own internal dns server with *.google.com domain and verification will work, or with my banking account - so you have legally certificate for man in the middle
You should change the code to verify records via servers available only on public dns or websites
ok, i cannot generate an certificate for an company which is public known
root@cert:/home/techsupport# certbot certonly --preferred-challenges dns --manual
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Please enter in your domain name(s) (comma and/or space separated) (Enter ‘c’
to cancel): facebook.com
Obtaining a new certificate
An unexpected error occurred:
Error creating new order :: Cannot issue for “facebook.com”: The ACME server refuses to issue a certificate for this domain name, because it is forbidden by policy
Please see the logfiles in /var/log/letsencrypt for more details.
but creating certificate for my own competition should not be a problem
this really could be a problem when You use old naming convention
like M$ domain.local - and this kind of domain is usually local, but if You use this kind of naming
for an infrastructure servers ( ex. CISCO ISE or RADIUS) You could generate signed certificates
on an every box you have - and use it for an replacing original infrastructure servers
Since Let's Encrypt will only issue certs for domain names ending in a public suffix, this example doesn't work either. What, exactly, is the security vulnerability you perceive? How, exactly, could I convince Let's Encrypt to issue a cert for a domain whose public DNS records I don't control?
I meant, The Internal server may be the one that is actually configured to answer for the entire domain through NS records at the registrar. But I don’t have enough information about the setup to say anything for sure
Let's Encrypt does validate from their own servers using the public DNS. CAs trusted in the web PKI are required to operate that way.* Your ACME client and local network do not control the process. (Of course, you might be running your ACME client on your authoritative DNS server, but that's a coincidence.)
* CAs might still be allowed to delegate domain validation to purportedly trusted RAs. I would have to check. It was a major source of problems and few benefits and I think it got banned entirely.