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.
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:
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’.
I noticed that in the file /etc/letsencrypt/renewal/www.example.com the order was:
so with an editor I switched the order to become:
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.
- Is this working as designed?
- Has any thought been spent on this at all or is it considered as absolutely irrelevant?
- Is there any way to bump the certificate to have the CN we’d want? (Except from “starting all over”.)