Update FAQ about what domains can get LE certificates


I understand LE ssl certificates are only available to publicly accessible domains, not intranet/internal domains.

Could the FAQ be updated to include this information so that users can easily get this information?




The domain does not have to be publicly accessible. The DNS challenge allows you to issue certificates for domains that are not exposed to the internet. This is described in the following FAQ item:

Can I issue a certificate without exposing any ports?

Yes, using the DNS-01 challenge. Certbot currently doesn’t support this challenge type, but many other clients do.

// edit: this reminds me that certbot now supports dns-01, I’ll get this updated soon!


I actually meant LE does not work for private domains, meaning the dns records/servers are not publicly available, only for internal use within the company. So how could DNS-01 challenge work in this case?



For domains that are not “real” (i.e., made up internal names that you do not actually own), this is a general limitation of the Web PKI. No publicly-trusted CA is allowed to issue a certificate like that.

For domains that you actually own but whose name servers are not publicly available, dns-01 wouldn’t be an option either. You would have to use some kind of split horizon DNS deployment where the name servers at least respond to the query for the ACME validation token, even if it does not respond to anything else.

I wouldn’t want to add a dedicated FAQ item for this to avoid confusion (it would be easy to read it as “Let’s Encrypt doesn’t work for any hostname that’s not publicly accessible”), but perhaps the existing item for dns-01 could be amended a bit:

Can I issue a certificate without exposing any ports?

Yes, using the DNS-01 challenge. With Certbot, you can use this challenge using the manual plugin. Automation is possible via --manual-auth-hook. Your DNS records need to be publicly accessible for dns-01.

Would this have clarified the situation for you?


thank you so much for the quick reply.
Well, we do own the domain, in this case “putnaminv.com”. Although this is registered domain, it is mainly used internally. ( dns lookup for www.putnaminv.com will return a valid record, but anything else will not).
Could you clarify what you meant by " the name servers at least respond to the query for the ACME validation token, even if it does not respond to anything else." ?
Or could you please let me the flow of dns-01 validation process? I checked the hook.sh and one of the clients (dehydrated) and it seems that the issuing process involves creating a dns record in the dns server we designated, then it will validate it using google dns servers, in which case if the dns server we designated is for internal use only, then the validation won’t work.

Also does the domain ownership validation happens every time the LE client is run?

Thanks again.



With DNS-01, Let’s Encrypt will query the authoritative name server of a domain for a TXT record under the “_acme-challenge” subdomain. To use internal.putnaminv.com as an example, this would be the process from Let’s Encrypt’s side:

  • Determine the authoritative name servers for putnaminv.com. This command does roughly the same: dig putnaminv.com NS
  • Pick one of the name servers (frx-dns1.putnaminv.com, auth51.ns.uu.net, anx-dns1.putnaminv.com, auth02.ns.uu.net) at random
  • Send a query for the TXT record of the domain _acme-challenge.internal.putnaminv.com to the previously selected name server. The response (i.e. the TXT record) should be the challenge token. You could also respond with a CNAME pointing to a different domain that has the challenge token as a response.

The challenge token is (slightly simplified) a random value that Let’s Encrypt provides to your client when you try to validate ownership for a domain. It will change for each new attempt and is valid for about a week, meaning you would have to update the value of the TXT record with each renewal (usually every 60 days).

I mentioned CNAMEs because a solution like acme-dns might allow you to set a static CNAME once and run a separate public DNS server (under a different domain or subdomain) that gives you programatic access to create the TXT records you need for the ownership challenge.



So if I understand correctly, it is possible for us to get LE certificates for our internal domain with the following setup:

  1. create a static CNAME record in one of the dns servers for putnaminv.com
    2, we can then either register with the public acme-dns server or we can install a self-hosted acme-dbs server to handle the ownership challenge.

This seems to be a very good solution. Please correct me if my understanding is not right.

But essentially this will be causing some security concerns. What exactly does the CNAME record allow acme-dns server to do? Any security concerns?




This is exactly right.

If you decide to use the existing public server (acme-dns.io), you’re essentially giving the operator of that server (or anyone who compromises it) the ability to issue certificates for any of the domains that have a CNAME pointing to it. Those certificates could then be used in a MitM attack on your users.

If you run your own acme-dns server, you would remain in control, so the only risk would be a compromise of that server, which would again give the attacker the ability to issue a certificate for all domains pointing to it. The API access can be locked down pretty heavily, so your only exposure would be the code that handles DNS queries. I’d personally feel comfortable with that, but YMMV.

I can’t think of any other scenarios where this DNS server could lead to a compromise of other systems.



thanks for the quick and detailed explanation. I really appreciate it very much!

Yeah, definitely that is a concern if someone else comprises the acme-dns server and issue some LE ssl certificates. Wouldn’t there be a way for the real owner to find out? Say through generating a report or sending an email notification?




Let’s Encrypt participates in something called Certificate Transparency. That’s basically a public, append-only log of all certificates ever issued. You can use this log to search for certificates issued for your domains to determine if any of them were unauthorized. The easiest way would be to use a third-party monitor. There are quite a number of them out there, here are two examples:

You can also use https://crt.sh/ to search the log manually (or subscribe to searches via RSS).

More info on Certificate Transparency can be found at https://www.certificate-transparency.org/. It’s already supported by a number of CAs and will become mandatory for newly-issued certificates from all CAs at some point in October.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.