Using LE for proper internal domain


I have a client with an internal AD domain which is a valid Internet domain as well. It is strictly used for internal purposes, and there are no servers using this domain which are accessible outside of the corporate network, to the general public. The domain is simply the “.net” version of the “.com” domain, which is publicly exposed. Like so:

Public-facing domain, owned by the client:
Internal-only domain, owned by the client:

Currently, the client has their own CA server which issues certificates, but there are a few scenarios where this causes problems with software or workflows which can’t reach the CA server for validation (such as checking the CRL for a cert). To solve this problem, I’ve suggested using Let’s Encrypt since LE is already in the Trusted Root store, and we wouldn’t need any additional configuration for internal machines.

My questions:

  1. Will Let’s Encrypt work for this internal domain, on internal-only servers? We can easily modify the DNS host to provide a TXT record for validation.

  2. What would happen if a web server is using LE, but the accessing machine is not able to hit the public Internet? We need to consider the scenario where machines are locked to only access the internal network. Will the LE certificate still work correctly without this access?

  3. Are there any security issues that should be considered when taking this route? I assume that requests to LE’s CA server would show the internal URLs/FQDN being accessed, correct?

  4. Would requesting a wildcard certificate for * be the preferred route to take. We have dozens of web servers to secure. Would a wildcard certificate prevent FQDNs from being exposed during a request to the LE CA?

Thank you for your assistance. Apologies if these questions are a bit newbie-ish; this is my first deep dive into SSL and Let’s Encrypt!


As long as the TXT record can be viewed on the external internet.

Yes, just OCSP won’t work, which isn’t fatal to most browser configurations.

CA wouldn’t see anything like URLs, just your certificate domain names and IP addresses of:

  1. The host requesting issuance or renewal of the certificate,
  2. One of:
    a. Browsers that encounter your certificate, if you do not have OCSP Stapling enabled.
    b. The server using the certificate, if OCSP Stapling is enabled.
    c. Nobody, if you block internet traffic on your browsers and web server.

Yes, it would definitely achieve that.

1 Like

Note that CAs submit most certificates – and Let’s Encrypt submits all certificates – to public Certificate Transparency logs. Everyone can see your certificates, including the hostnames.


How would this problem, certificate validity checking, go away with a Let’s Encrypt certificate? As @_az already mentions, OCSP validation (LE doesn’t use CRLs) won’t work if the client doesn’t have internet access.


What would happen if a machine with an LE certificate was disconnected from the Internet for whatever reason? Would the certificate fail validation and the subsequent HTTPS site be unaccessible to that machine?


Thanks for the replay, Osiris. The current internal certificates have only an LDAP URL to hit the CRL, so we need to do some workarounds to get software like Git to see our self-signed certificate instead of using the Windows Certificate Store. That’s just one example.

closed #7

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