Common Name change after using --expand flag

Issuance Tech
1

I find myself with a Common Name (CN) that I hadn't expected.

When I first requested the certificate for the Web site in question, I requested a certificate for 'www.example.com' and that was all.

Like:

letsencrypt certonly --webroot --webroot-path /var/www/www.example.com/htdocs --domain www.example.com

It gave me a fully working certificate with the CN = www.example.com. Great. This makes logical sense to me and to those few actually looking at the certificate through a Web browser.

We do have a vhost based subdomain on this server, which can be considered as somewhat 'secondary' in functionality and also is of less interest to the main public. (Cause everyone goes for the 'www' site.) The 'secondary' subdomain is then called 'subdomain1.example.com'.

So I executed:

letsencrypt --expand certonly --webroot --webroot-path /var/www/www.example.com/htdocs --domain www.example.com --webroot-path /var/www/subdomain1.example.com/htdocs --domain subdomain1.example.com

I realize that I have one single shared certificate, valid for both www.example.com and subdomain1.example.com. This is absolutely fine with me.

What surprised me, and what has actually surprised a few visitors to our Web server (they looked at the cert !?!?! ) is that now the Common Name of the cert is set to CN = subdomain1.example.com. This raised a few eyebrows to a few visitors and I've had to explain that it's correct.

The vast majority of our visitors will visit www.example.com. Only those who have the required login will make any practical use of subdomain1.example.com even though anyone in the world may visit the 'login page'.

It would therefore look more logical to anyone actually inspecting the certificate if the CN was set to www.example.com and not to subdomain1.example.com.

I noticed that in the file /etc/letsencrypt/renewal/www.example.com the order was:

[[webroot_map]]
subdomain1.example.com = /var/www/subdomain1.example.com/htdocs
www.example.com = /var/www/www.example.com/htdocs

so with an editor I switched the order to become:

[[webroot_map]]
www.example.com = /var/www/www.example.com/htdocs
subdomain1.example.com = /var/www/subdomain1.example.com/htdocs

Then I forced a renewal of the certificate and reloaded apache.

But it seems to me that the "unwanted" order is kept as it was and that the CN remains 'subdomain1.example.com'.

I realize that technically it doesn't make any difference, but it does make a difference to a human being looking at the certificate through the browser.

Questions:

  1. Is this working as designed?
  2. Has any thought been spent on this at all or is it considered as absolutely irrelevant?
  3. Is there any way to bump the certificate to have the CN we'd want? (Except from "starting all over".)
2

A change introduced in version 0.5.0 caused the client to accidentally scramble the domain list. Before that, the first domain passed via --domain would end up being the Common Name.

There’s a fix for this which will probably be included in 0.6.0. You can either wait for that release, try to downgrade to a 0.4.* release (you’d probably have to do a developer installation and use the v0.4.2 git tag), or generate your own CSR with the correct Common Name and use it via --csr.

Issue and PR with the fix for your reference:


4 Likes
3

Thanks for the explanation @pfg , that makes a lot of sense.

Having this information, I can calmly sit back and wait for a future release of V0.6.0 or similar. Most importantly, I can explain the (non-critical) situation on my side. :slight_smile:

4

I am having the exact same problem! Glad that I know you’re aware of this and are fixing for the next release. Thank you.

5

Does this change also apply to when certificates are generated using a template as described here? https://www.nginx.com/blog/free-certificates-lets-encrypt-and-nginx/ (Note that I have used multiple domains in the template, despite what the author suggests it actually works).

Currently the common name appears to be assigned at random, and will sometimes change when the certificate is expanded. Just wondering if this will be fixed in the next release so that the common name is the first name listed in the template?

6

Yes, this bug affects all usage types of the client other than manually specifying a CSR via --csr. A fix is scheduled for 0.6.0.

1 Like
7

Just an update for anyone else with this problem who stumbles upon this thread, as @pfg suggests, downgrading to version 0.4.2 will solve the issue until 0.6.0 is released. To downgrade I simply uploaded and unzipped the .zip file found here https://github.com/letsencrypt/letsencrypt/releases, replacing the files from version 0.5.0

However, using the letsencrypt-auto command will automatically update your lets encrypt files to 0.5.0. To get around this I simply added --no-self-upgrade to the end of the command to generate the certificate.

Hope this may be of help to anyone else with this problem.

Thanks,
Ashley.

1 Like
8

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