I think this might be related to the threads about multiple domains on the same certificate but I am less familiar with this subject as a whole.
Can there be a way to group the www.example.com and the root example.com domains in a single certificate?
For context, I’m hosting a static website through amazon’s s3 and cloudfront, which only lets you choose one certificate for the distribution (as far as I am aware of right now).
Yes, pass two -d flags on the same command line.
Certificates issued by Let’s Encrypt can include up to (IIRC) 100 domain names. www subdomains or the root domain are no special case here, so that works fine and like any other domain, as long as you can solve a challenge for each domain. It’s as simple as passing -d example.com -d www.example.com to the client.
CloudFront should work just fine with SAN (or Subject Alt Name) certificates, according to this blog post.
This works fine for me…
Thank you for the help! I didn’t realize that’s how letsencrypt worked
It’s worth noting that the order the domains are passed matters. The first domain will be the main domain for the produced certificate and the others will be Subject Alternate Names.
I think the directory structure in /etc/letsencrypt/ is also based on the first entry.
Note that we don’t guarantee that behavior, that the first domain passed will wind up in the Subject Common Name field. That happens to be how it works now, but in the future it could change.
but is there any reason to change that behaviour ?
The field is deprecated / discouraged in the BRs, in preference for subjectAltNames: https://github.com/letsencrypt/boulder/issues/40.
i see thanks @jsha for the heads up!
I’ve just generated a few certificates, and NONE of them assigned the first -d name as the Subject Name. A seemingly random name was selected as primary each time. I’d like to assert that this behavior is generally undesirable.
It might be true in many cases that the primary subject name is functionally irrelevant, and it might well be true that the field will go away in the future. However, it’s certainly very relevant today, and it will remain so for at least some amount of time. It matters to both systems and humans, and begs for the ability of specificity.
In some systems, that field is used for automation. For example, I know of at least one OpenVPN service whose connection scripts use the Subject Name field to determine the proper network settings to push. The inability to specify the Subject Name breaks these scripts needlessly.
More generally, though, and certainly more visibly, humans use that field. Humans click on the browser’s “lock” icon to provide a sense of confidence. When they find an unexpected name there, it can be confusing at best, and concerning at worst. Complicating matters even further, some browsers don’t even display the Subject Alternate Names when viewing the certificate that way, only the main Subject Name. I’ve already received calls from users who are conerned by this. My explanations help, but their confidence remains reduced.
Please, I implore you, provide some way to control which name will be used as the certificate’s main Subject Name. Even if it’s with a separate option, please do provide some deterministic mechanism to control the behavior. Thanks.
You actually can generate a CSR and pass that to the client. That is what I do, so that I control the Common Name.
This appears to be a regression in 0.5.0. I’ve opened an issue:
You can try downgrading to a previous version (although I’m not exactly sure how one would do that with letsencrypt-auto, you’d probably have to use the development installation guide) or alternatively create custom CSRs and use them via --csr like @Jason suggested.
Why? If there's a certificate mismatch, the browser will warn the user; conversely, if the browser hasn't given a warning, the certificate must be valid for the hostname the user is visiting. I'd have to think any user savvy enough to look at the certificate information in the first place would understand this.
Furthermore, as you’ve apparently got multiple hostnames in the SAN, this “looking up the CN” behaviour concern would only be valid for that single hostname… Why isn’t it a problem for all the other hostnames in the SAN?
@pfg: Thanks so much! I’ll watch that issue.
@Jason: Thanks to you also for the CSR suggestion. That’ll work in the mean time.
@danb35: Users are funny creatures, aren’t they. Some do think as you suggest. Others just think differently, I guess. Seems easiest to me to just make the CN what everyone thinks it should be.
@Osiris: I’m assuming you’re referring to my OpenVPN script example. The script in question simply looks up configuration in a local database, and it uses only the CN to do so – it completely ignores all SANs. (Should it be rewritten? Maybe.)
The example was only meant to illustrate that some automated processes expect the CN to be what they expect it to be, and do not work if it is otherwise.