I have seen several topics relating to this but none that actually provide a solution, ie run certbot-auto with this flag, etc
I am using letsencrypt to serve multiple SSL virtualhosts on apache, the certificates are being generated and work correctly. I am being asked from my boss to have the Subject Name be our organization hdesd.org (which is one of the VHosts) instead of the alphabetically first one centraloregonstem.org. Is this possible and how do I accomplish this task? We have a working existing cert and are running the certbot-auto renew via cron.
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: multiple but we want hdesd.org to be the Subject Name but currently centraloregonstem.org is because it is alphabetically first
I ran this command: certbot-auto renew
It produced this output: It generates a valid cert but my boss wants the Subject name to be our org not alphabetical
My web server is (include version): Apache 2.4.6
The operating system my web server runs on is (include version): CentOS 7.2.1511
My hosting provider, if applicable, is:
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
Sorry but I don’t know if I understood what you need.
Are you talking about the CN (Common Name)?
or are you talking about the order of SAN?
If it is the second one, the answer is no, these names are sorted alphabetically and you can do nothing to override it.
If you are talking about the common name (CN), yes, you can define what is the domain name included in the certificate that will appear in the common name field, the first domain in the certbot command will be used to fill the common name.
Examples:
In this case, the common name will be centraloregonstem.org:
Note: Common Name field is deprecated and should not be used, indeed in a future Let’s Encrypt could use a serial number or something similar instead of one of your domains.
Yes it was the first one, the Common Name. So thank you!
So now that I have the existing cert and they are all still valid, how do I replace it? I never had to list the domains, it just scanned the virthosts defined in /etc/httpd/conf.d/ folder, so do I have to enumerate all of them now? And do you know if that will stick through the certbot-auto renew cron job or do I need to modify that job as well?
You can issue the same command you used, but this time add the -d parameters for every domain you want to include in the cert, and the first one will be the one used to fill the Common Name. If you issue the same command with the -d domain1 -d domain2 parameters, etc. certbot should detect that another cert with the same exact domains is already issued and will ask you if you want to renew and replace and you should select that option.
Yes, you don't have to change anything in your cron job, it will renew your certificate and Let's Encrypt will respect the common name.
Note: Before trying anything, please, backup /etc/letsencrypt/ dir just in case.
Both kinds of issuance are counted in the same way against the totals. The only difference is that reissuance won't be blocked by the certificate per registered domain rate limit (but it does count against it).
As far as I know, a reordered certificate should be counted as a renewal and hence not be blocked by this rate limit.
Thanks. I understood the timing and blocking aspects, just didn’t understand how boulder uniquely fingerprints the certs.
checking some live certs, it looks like the CN is included with the SAN so I’m going to assume the uniqueness is just based on a alphanumeric sort of the SANs.
That's right. CAs are required to include the Common Name in the SAN field too. That way clients can ignore the Common Name field entirely. (Clients usually don't ignore it, though, because enterprise CAs don't always hold themselves to the rules of public CAs.)
Some popular clients, including Firefox, completely ignore CN for publicly trusted certificates. If you have manually trusted other roots (e.g. corporate ones) then a special case checks CN.
This means the riskier attempt to parse CN only happens when you’ve also made another risky choice (trusting another root) and not to ordinary users on the Public Internet.
