Change base domain name for Lets Encrypt SSL certificate in Certbot

[jryd]

I previously posted this thread: Change base domain name for Lets Encrypt SSL certificate

I was waiting for the new version of Lets Encrypt to come out to enable me to change the base domain.

I am now using Certbot for my Debian Jessie server.

How do I go about reissuing my certificates to ensure the base domain is my top level domain rather than a sub-domain?

Do I need to revoke and reissue them? How do I do that?

[pfg]

You should be able to do that using the command you originally used to obtain the certificate. Add --force-renewal to force the client to get a new certificate even if the current one isn’t close to expiring. Based on your earlier post, this would be something like:

./letsencrypt-auto --apache -d example.me -d www.example.me -d mysql.example.me --force-renewal

Revocation isn’t needed - that’s something you only need to bother with if your private key is compromised.

[schoen]

@pfg, I asked @bmw about the history of Certbot releases and what they did about preserving the requested domain order.

In all released and planned Certbot versions, you’ll still have the old lineage name (in terms of what the certificate lineage is called on disk).

@bmw says that for renewal with certonly (or initially issuance with certonly or when running with run or no specific verb), you’ll preserve the order of requested names from the command-line -d arguments in all versions except 0.5.0.

For certonly renew, you’ll get alphabetical order in 0.4.0 to 0.5.0, random order in 0.5.0, alphabetical order in 0.6.0 until now, and, in the upcoming release, the order will be preserved.

So depending on what you have and what you want, you may or may not be able to “fix” it when upgrading to a new version. (It’s always possible to delete existing lineages completely by deleting all associated files in /etc/letsencrypt, and then make fresh lineages from scratch; you also have to be careful not to leave behind any references to the old lineages’ files in web server config files.)

[jryd]

I had upgraded to use certbot as I am running Debian Jessie with Apache.

@pfg running the following fixed it for me certbot -d example.me -d www.example.me -d mysql.example.me --force-renewal.

I had a little trouble following the exact order of things in @schoen response, as I am running version 0.8 I’m guessing it is alphabetical?

If this is the case then I got lucky as my top level domain is the first one alphabetically so it was going to be issued to this.

[schoen]

Hi @jryd, I know there are a lot of different cases and behaviors to consider here!

The alphabetical sort would happen if you ran certbot renew; but you ran certbot certonly, which doesn’t have the same problem, so the expected behavior is that you get the names in the same order in which you specified them with -d on the command line. I think that’s what happened for you.

If you later run certbot renew with 0.8.0, you might find that it reorders the names to example.me, mysql.exapmle.me, www.example.me in the replacement cert. The forthcoming release of certbot should no longer do that and should instead keep the exact order from the most recent version of the cert.