Certificate validation - ex. dns - huge risk problem

Hi,

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

BR

Aleksander Iwanski

please try.

dns-01 validation will check the authoritative dns servers for the domain, not random public resolvers. (or client-local ones)

1 Like

Hi @aiwanski

if your dns server isn’t public, Letsencrypt can’t check your dns server. So it’s impossible to create a certificate via dns validation.

Please create a certificate with *.google.com.

Where it the “huge risk”?
I fail to see any risk from your explanation/details.

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

BR

The proof is in the pudding, and I’m hungry :hungary:.

The particular error message for facebook.com is because it’s on a high-value domain blacklist - the CAA error is slightly different.

It means this:

% dig facebook.com caa

; <<>> DiG 9.16.0-Ubuntu <<>> facebook.com caa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5211
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;facebook.com.			IN	CAA

;; ANSWER SECTION:
facebook.com.		3599	IN	CAA	0 issue "digicert.com"

;; Query time: 51 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: mer mar 18 22:33:08 CET 2020
;; MSG SIZE  rcvd: 72

Please do it. I need to see that certificate.

No. CAA is another problem. Letsencrypt has a manual created list of blocked domains.

PS: @aiwanski : Try to create a certificate with my domain server-daten.de.

Oh, ok. Makes sense.

You can not create a valid certificate for any domain you don’t control.
If you can, please show us - now that would be a “huge problem”.

No, the sky is not falling down on you.
Things just tend to fall down on us when we throw them up ourselves,

Ok, I was to hurry, it really looked at auth domain

I think that trying to make an certificate is illegal and is prosecuted by law,

So don’t kick me on my balls, everything is ok - I can even remove the thread - my fault :smiley:

BR

olo

That depends. You can always try to issue a certificate for a nonexisting domain, like

C8S78fwipF4efom5zPVVQtNefTVgw8M9.org

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

BR

olo

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 think in OP’s situation here, the “private” server may be the one authoritative for the entire zone

what do you mean by that?

I can host a server claiming to be authoritative for . (the root zone), but no dns-01 challenge will cause it to be queried.

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.