Changing the url setting in your site’s config file. Eg. using the cli: ghost config url new-subdomain.maindomain.com.
Making sure the DNS record for the new sub-domain points at the same IP address. If you already have a wildcard (*) A record for your domain that points to the right IP address, there will be nothing to do.
But 10 years since the “SSL By Default” campaign started, and I still find it the most infuriating part of server admin. So I don’t know how you should change your subdomain without invalidating your certificate. Even nginx seems short on ideas.
This looks awesome, thank you! Alas, there was a bit of devil in the detail. For other’s sake, here’s how I got it to work:
certbot can be installed on Ubuntu using sudo apt install certbot.
As you say, you need to already have a certificate issued using certbot. This is not the case in the default Ghost install (which I think uses /etc/letsencrypt/acme.sh instead).
However, you can just run the command twice - once to get a new certificate, and once to expand it!
Note that the -w directory needs to be /var/www/ghost/system/nginx-root in order for the .well-known/acme-challenge stuff to work, otherwise certbot can’t find your existing certificate.
The -n flag in the second command causes it to fail, because you need to accept the tos and provide an email address. Either remove that flag so it runs interactively, or add the --agree-tos and --email <email_address> flags.
In fact, just using the first command will prompt you to expand the existing cert anyway.
You need to change the ssl_certificate and ssl_certificate_key settings in your nginxsites-enabled file to point to the new certificate issued by certbot.
You need to restart nginx after making a config change, or even just modifying the cert, with sudo service nginx restart. Note that if it fails the systemctl mess on Ubuntu wont tell you why - check /var/log/syslog instead.
And voila! It’s “easy” to add additional subdomains to your certificate.
One doubt that remains - given that Ghost uses crontab to periodically renew the certificate automatically, wont this now fail because it uses acme.sh instead of certbot?
Okay it’s been 2 months so I’m about to find out whether renewal still works since switching from acme.sh to certbot. The acme.sh cron job is still working, but I guess it’s just renewing certificates I don’t use anymore. But now I see from this that certbot automatically installs a renewer too (sneakily hidden from crontab).
Tomorrow it’ll tick over to <30 days to expiry, so we’ll find out!
Cert updated! I didn’t realise at first, because the web server needs to be rebooted for the new cert to take effect. The actual cert date can be verified with sudo certbot certificates. So if I forget to reboot every 60 to 90 days, the auto-renewal is useless. Will take note!