SSL certificate for a internal-only domain that's not on the Internet?


I have a non-public domain – blah-blah-dot-cloud – which is never used outside the company and cannot be reached from the public Internet.   However, it is used by several hundred machines within the company, and I would like to be able to use LetsEncrypt to generate a “trusted” certificate for them so that I do not have to “trust” a self-signed cert (hundreds of times …) myself.

LetsEncrypt’s ACME verification systems could not reach these sites to verify them:   no one can.   But, is it possible to produce a trusted certificate that references these domains?   Or is there a way that a signing-certificate could be obtained (from anyone)?


Do you own the domain name “blah-blah-dot-cloud” ? even if it has no A record or anything for it ? if so, then you can obtain a certificate using the DNS-01 challenge (whereby you have to place a token in the TXT record for _acme-challenge.blah-blah-dot-cloud

If you don’t own “blah-blah-dot-cloud”, then no you can’t obtain a certificate for it.


If you don’t control that name in the public DNS and it’s an internal-only name, the CA/Browser Forum’s rules now forbid any publicly-trusted CA to issue certificates for it.


(I thought …) “obviously,” the situation that I describe would be some kind of an “edge case,” where a “trusted™” certificate would somehow be issued for a URL that could never see the public light-of-day.

In retrospect, however, I now realize that this scenario is incompatible with the social-contract that any “public CA” is trying to achieve.   Clearly, the corporation in question must take these matters into its own hands, by inserting its own (self-signed, of course) certificate into the “list of trusted authorities” that it pushes down to its own corporate machines.

I now, somewhat ruefully, realize that “what I described, really makes no sense at all,” for LetsEncrypt or for any other “public CA.”

(“So … never mind …”) :confused:


.cloud is a real TLD, though. You can buy a .cloud domain from any major registrar right now.

If you’re using a .cloud domain internally and don’t own it… that’s bad.

If you’re using a .cloud domain internally and do own it… well. You could set up public DNS records, even if they’re completely dissimilar to your internal DNS records, and use them to obtain Let’s Encrypt certificates. Whether by using DNS-01 validation, or setting up A or AAAA records to use HTTP-01 or TLS-SNI-01 validation.

(Be aware that Let’s Encrypt logs all certificates to public Certificate Transparency logs, so the subdomains in your certificates would not be kept secret.)


Hi MIkeRob

You are right. There are two ways of going about this.

A) Create your own internal CA and add it’s intermediate to all the machines in your corporate network (this is quite common for example internal intranets). This is quite common in Windows Server environments.
B) CAs like GloablSign will provide an enterprise PKI capability (i.e. the ability to sign it’s own certificates which are then linked up to GlobalSign).
C) You can use Boulder as your CA (this is what LetsEncrypt uses) and the certificate from B to get the best of both worlds. I.e. an Internal CA which adheres to ACME protocol. Microsoft CA relies on Microsoft Services for certificates etc.


Don’t feel bad, it took public CAs the best part of two decades to understand why they ought never to issue for names that didn’t belong to anyone. They only agreed as an industry to stop in 2015.

Because they’re pretty cheap and it avoids confusion I would always recommended buying control of a domain even if you never intend any of the names in it to be visible to the public. Also, although Let’s Encrypt’s methods and policies forbid issuing in that circumstance, other public CAs are content to issue (perhaps for $$$) for any names in the domain you own. If you can prove you own they’ll issue for

An organisation-wide private CA is often the right choice though, yeah. Good luck.


Yeah, they actually feel cozy about setting up an internal-only CA and have the means to “push” trust out to their very-many machines.   (Not quite sure how that works there … but apparently it means that I won’t have to.)   But a truly internal-only CA (company-self-signed cert) does actually have some advantages for a site that needs to be secure and accessible to no one outside the company.   Makes sense, I suppose.   “So it goes… thanks, folks.”


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