It produced this output: - Congratulations! Your certificate and chain have been saved at
** /etc/letsencrypt/live/invoices.letterx.co/fullchain.pem. Your cert**
** will expire on 2017-02-26. To obtain a new version of the**
** certificate in the future, simply run Let’s Encrypt again.**
My operating system is (include version): Ubuntu 16.04
My web server is (include version): Apache 2.4.18
My hosting provider, if applicable, is: Linode VPS
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
Everything seems to be working fine from a user perspective. Way easy to get SSL working on my site, thanks to everyone who made this possible!
My concern:
I have several sites hosted on my VPS, all of which I wanted to create SSL certs for. I ran the certbot wizard, selected the hostnames I wanted certs for, and it completed successfully. All of the sites automatically use SSL now, which is great. However, if I examine the certificate directly, I can see that regardless of which site I’m viewing the cert for, the cert says it was issued to one specific sub-domain I have: invoices.letterx.co.
Why is this happening? Can I improve the config so that the certs are each issued to their respective domains?
A certificate has two ways to show what hostnames or other information it, um, certifies: The Common Name section, which may contain a single hostname, and the Subject Alternative Name extension, which can contain a long list.
Specifying a hostname in the Common Name has been obsolete for about 15 years, so of course it’s still done almost universally.
Subject Alternative Name has syntactic advantages, the obvious benefit of supporting multiple names, and if i remember correctly, it’s actually required by current certificate standards. But browsers still display it in the most obscure possible location – probably about halfway down the “Advanced Details” tab, or whatever your browser calls it, alongside every other piece of information in the certificate – while giving a prominent seat to the Common Name, which their networking code quite possibly ignores entirely.
Certbot’s default behavior is to choose the first name you specified in the command line as the Common Name. So if you ran:
example.com would be the Common Name, and displayed prominently in your browser. Evidently you put invoices.letterx.co first.
(Certbot also uses the first name when creating a new /etc/letsencrypt/live/example.com directory, but the name of the directory is not really literally expressed in the certificate.)
You have three options:
Ignore this, because it is of almost 0 actual importance.
Issue a new certificate with a different name specified first, if you have one you prefer.
Issue a number of new certificates, with different names specified first, and use each of them on your different sites.
If obsolete, why is certbot putting something there?
If it is properly ignored anyway, can certbot be told to leave it blank? Can a cert be issued by LE at all without a CN? Can any cert be issued without a CN?
I prefer the first option since if the browser, or app, accepts the cert and behaves properly, the typical user will never look at the cert's data anyway.
This option is well and good, as long as the rate limits are not a problem. But, if getting a different cert for each subdomain, why even include the other names in the SAN, just make each cert a solo version (except for possible www. variations of course)?
Compatibility, inertia. Who wants to be the first CA to break compatibility with some obscure SSL library from 2005? There's little downside to the status quo.
Of course, this becomes less of an issue over time. Systems are replaced or upgraded, and unrelated changes (e.g. banning SHA-1) reduce compatibility with obsolete software anyway.
Buggy software is a different issue. Who wants to bet that there's at least one current, semi-prominent library that has bugs with CN-less certificates?
I'd guess that the compatibility issues are near-zero today -- barring unlikely but possible bugs -- but i don't have a lot of evidence.
Normally? No. If you generate a custom CSR and use the --csr option? Maybe.
You'll have to wait for someone else to chime in. The Let's Encrypt CA software supports it, but it's configurable. They might have it off.
Yeah, you're right. I was thinking that, say, if you had ten names, you'd probably be happy to issue a few certificates with three or four names each. Issuing fewer certificates is probably less of a hassle for you typing certbot commands, if nothing else. And there's no branding issue if, say, example.com, www.example.com and static.example.com are the same certificate.
Most of the rate limits are per-domain. Rate Limits - Let's Encrypt If the way you want to split things naturally aligns with that, they're not an issue. (Issuing one certificate for example.com and example.net, or issuing two certificates, one for each domain name, has the same rate limiting cost.)
I had initially used the ‘wizard’ interface by running simply letsencrypt --apache, and star/unstarring the domains I wanted SSL for.
Your explanations and discussion helped me figure out how to get the results I was looking for by running that command with the -d switch and basically doing option 3 as suggested by @mnordhoff.
The CN is part of the Subject’s DN (Distinguished Name) and the rules Let’s Encrypt operate under, indeed even the much broader rules everybody on the Internet is supposed to follow, say for a SSL/TLS server certificate CN must be textually the same as one of the SANs if it is present. Some certificate authorities don’t get that right but they’re naughty and such shenanigans can cause weirdness.
Certificates must have a subject DN, but technically CN within that is optional. Let’s Encrypt talked about issuing some certificates with no CN because of exciting length issues with very very long hostnames, but I don’t believe this plan ever happened, so most likely if you submit a CSR with no CN filled out, Let’s Encrypt will simply choose one of your SANs and set that as CN. If you’re curious you could try against the staging servers to avoid wasting resources.
As of June 1, Boulder supported issuing certificates without a CN, but Let's Encrypt didn't enable it. Or maybe it was enabled in staging but not production?
