Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
My web server is (include version):
The operating system my web server runs on is (include version):
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
No certbot yet installed
We have an internal domain through AD. So far as I can tell, Let’s encrypt will NOT be an option for us vs self-signed certs because LE uses domain verification to generate the certificate. Obviously, we don’t have a public domain to verify with. Am I misunderstanding LE or is this accurate? Does anyone have suggestions for another CA that will issue internal domain certs?
Assuming I got LE working for a different personal website, wouldn’t setting up a cron job to renew every sixty days (from the FAQ) also imply the users must re-accept the cert around every 60 days?
This is correct; publicly-trusted CAs are only allowed to issue certificates for publicly-registered domain names. While your site doesn't have to be globally accessible, it has to be a subdomain of a unique domain name that you have registered.
This rule applies to all publicly-trusted CAs as a result of industry standards set by the CA/Browser Forum. In the past, the rule was laxer and some publicly-trusted CAs would issue certificates for private, internal-only domains. Security experts were very concerned about the implications of this, because a certificate issued that was intended to be used legitimately for an internal service on network A could also be used to attack users of a different internal service (with the same name) on network B. So, this practice has been phased out.
You could instead register a public domain name and then create a private subdomain of that public name for your internal service. Let's Encrypt and other certificate authorities will be willing to give you a publicly-trusted certificate for the internal subdomain. The subdomain will be disclosed via Certificate Transparency, but it need not be accessible from the public Internet at all.
You could also use self-signed certificates or a private internal CA. In that case, every device that's intended to accept that certificate will have to be configured ahead of time to do so.
Nope, the point of publicly-trusted certificates is that users don't have to take any action in order to trust them. So both your original Let's Encrypt certificate and any subsequent replacement certificate from Let's Encrypt will be accepted immediately and automatically by users' browsers without the user having to take any action. This is a result of the browsers' trust in Let's Encrypt to perform this function.
Thanks schoen. Since this is a sensitive system, I’m doubtful we’ll be able to register a public domain even though the cert would be for a private subdomain that’s not internet (world) accessible. The problem with self-signed certs is that more and more browsers give the users flack when accepting them. It sounds like the better solution for us would be to setup an internal CA, have the users import that certificate and use the internal websites or any other service needing a cert.
I thought about the second question in more depth after I’d posted it. It was my thinking that a newly re-issued cert would prompt the user because the expiration date had changed. However, if this were the case, we’d see many more complaints about re-acceptance online. Not only this, but I can’t remember when I’ve ever seen this for any site other than one that didn’t renew at all.
@le-frog I actually used private domains in the past with LE certificates.
It was my thinking that a newly re-issued cert would prompt the user because the expiration date had changed.
Are you talking about self-signed cert, private CA, or Let’s Encrypt certificate?
Self-signed: users need to accept every new self-signed certificate. However, you can choose any validity period, since you are the one cretins the certificate.
Private CA: Users need to accept the CA certificate only once and then it will be treated as if it was a real CA certificate, so all leaf certificates will be accepted as normal.
It was my thinking that a newly re-issued cert would prompt the user because the expiration date had changed.
There is a difference between Private Key, Public Key, and certificate. Most likely, you installed a self-signed “leaf” certificate, then it expired and you generated a new “leaf” certificate with the same Public Key. In this case, users do need to accept the new certificate. In contrast, if you generate a “root” key pair, and make a self-signed certificate with Certificate Authority capabilities, and ask people to install that and then once in a while generate “leaf” certificates signed by the “root”, those will be accepted without any problems.
FYI, I used LE certs on a private domain and that was pretty simple. I used GitHub Pages to pass the challenges, but if you have a private site where you can install the cert bot, it’ll be even easier. I can explain what you would need to do, if you need help.
schoen, this helps further my understanding about what’s happening with cert expirations.
I’m interested in hearing your solution but doesn’t this method subvert LE’s intended method of verification? certbot isn’t an option because a connection to the outside world is expected, disregarding the domain check
First, let me explain the original problem: I had a VM that was not publicly accessible (accessible only for people connected to the organization’s network, Wi-Fi mostly, or VPN’ed into it). So my only way was to get a custom domain and get a cert for it. When I got a domain, the registrar online panel allowed me to enter only A or AAAA records (so no TXT or CAA or anything else), so the only way I found I could complete the challenge is by running a publicly accessible server (hosting special “challenge” file in a special folder .well-known). The simplest hosting solution I could think of was GitHub, so I went with it.
FYI, that was a a one-time solution for a development server that I knew I would decommission before certificate expiration (in less than 90 days). The real issue here is I picked a terrible domain registrar and if I needed the server for any real tasks (handling real data), I would just transfer to a different registrar.
doesn’t this method subvert LE’s intended method of verification
It is not automatic renewal method, but it is a valid verification with certbot running in “manual” mode. Yes, you should always prefer automatic renewal if at all possible. However, that one time I knew the server would be gone before certificate expiration anyway, so it did not matter.
Thanks bershanskiy. There are two issues for us that won’t allow this.
Because our internal domain is three letters and when we change the internal domain to a different set of three letters, we would not be able to register the domain (all three letter domains taken). However, even if this was not the case . . .
I strongly suspect management of nixing an public A/AAAA record of any kind for any reason.
Your method appears to still require a registered public domain but you use a “throw away” box to accomplish it
All certificates are issued for a specific domain name, multiple domains or wildcards. The domain name is the thing that the certificate certifies. (Certificate without a domain name is akin to a birth certificate or a passport without a name on it: it simply makes no sense). If you need a publicly trusted certificate, you will need to prove ownership (or rather control) of that domain.
when we change the internal domain to a different set of three letters, we would not be able to register the domain (all three letter domains taken).
Could you elaborate? You want to use a domain name internally that is already publicly assigned to someone else?!
If you use someone else’s domain, you are bound to have more serious problems than inability to get a cert. You are bound (at some point) to accidentally leak your internal DNS requests and subsequent traffic to the global internet and the real owner of the domain. FYI, Google bought .dev top-level domain and are constantly complaining that people use it (in development environments, probably). Google constantly gets DNS requests to domains that they as a registry (not a registrar) have not assigned to anyone.
I’m not sure I’d say we “need a publicly trusted certificate”. Browsers are becoming more strict about giving end users grief whenever they run into a self-signed certificate. Let’s Encrypt seems like a very good free option to accomplish getting a cert that doesn’t annoy users since LE is trusted by the browser. Self-signed certs can be created without a real (public) domain associated with them.
I can’t elaborate on specific names. Let’s say someone sets up Windows Server with Active Directory using abc.com domain. Does the domain belong to someone else? Most certainly. Is AD in violation of the other domain? My guess is that as long as that domain is within a closed internal network and not doing things like having DNS queries exit the network, you’re probably OK. One is public and the other private.
I happen to agree with you that this isn’t best practice if for no other reason than people will eventually make accidental queries but we use NAT and IP addresses for things like web servers. I don’t have control of the network but I’ll see about convincing management to change the new domain name. Is this what .local is meant to help with? I’ve inherited the situation.
I’m not sure I’d say we “need a publicly trusted certificate”.
Then I’d recommend running an internal CA: you create a “root” certificate that you install on every machine once (e.g., manually or via group policy) and then you sign as many “leaf” certificates for any domain names and dates as you need to. As long as you control your own root, this system provides the same level of assurance as the publicly trusted CAs do.
Browsers are becoming more strict about giving end users grief whenever they run into a self-signed certificate.
In general, you should not use self-signed certificates because they breed user apathy (“I alway just click OK, what’s wrong with that?”). If you teach people to be complacent, they will be.
Let’s say someone sets up Windows Server with Active Directory using abc.com domain.
Well, I’d recommend not using a name that you know someone else is using. I’d recommend using something else, e.g., abc.doesnotexist, because if your setup leaks DNS queries to the web, at least they will resolve with not found error instead of sending your traffic to the legitimate owner of abc.com.
Is this what .local is meant to help with?
Pretty much. The point of .local is that it is not and will never become a real TLD so there should be no name collisions. With the same result you can use any word not on this list.
Thanks for the wealth of information guys. I’ll probably end up with something like abc.companyname.
The original question was effectively two: How do I do non self-signed certs for an internal domain and How do renewals work for something on a VPS with an already registered domain. You have answered both.