Wildcard SSL + certbot-dns-linode + nginx

Hi guys,
I've followed the instructions to create a wildcard SSL certificate. I have already had one in place for heystefan.com and now I wanted to add another one for *.heysefan.com.
Everything went well in the SSH window but if you check https://www.heystefan.com you will see that the certificate is not there.

What could be the issue?

My domain is: https://heystefan.com

I ran this command:

certbot certonly \ --dns-linode
--dns-linode-credentials ~/.secrets/certbot/linode.ini
-d *.heystefan.com -i nginx

It produced this output:

Don't have the exact output anymore but everything went well!
All challenges have passed and there were no errors.

My web server is (include version):

nginx/1.18.0

The operating system my web server runs on is (include version):

ubuntu 20.10

My hosting provider, if applicable, is:

linode

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

certbot 1.14.0

You've used the certonly subcommand. This means yiu will only get the cert. Certbot won't install it for you in your webserver, even if you use the -i command. As you've used the certonly command, this is probably what you wanted. That does mean you should install it in the webserver yourself, manually.

1 Like

:man_facepalming: Thank you! Can't believe I missed that. :slight_smile:

Now I have another problem — the domain that used to work (https://heystefan.com) is not working anymore. I'm guessing it's overwritten in the nginx conf. Do you have any suggestions on how to proceed?

This is my conf file for the domain heystefan.com:
https://pastebin.com/raw/G313j94k

That's to be expected. See the following part of your command:

That's the only -d option in your command, so you also only have the hostname *.heystefan.com in the certificate. This however does not include the apex domain heystefan.com, so if you required that, you should have added that to the certbot command.

See: Glossary - Let's Encrypt

If you require heystefan.com to function, you should update your certificate to include it.

I appreciate the help so much, and I am very sorry in advance if I sound obtuse — but as I have mentioned in the original post, I have already set up https://heystefan.com before (also using certbot).
I had no idea adding a new domain will discard all that I have done before. And I am not sure what is my next course of action here. Ie. if I add heystefan.com back again, will it overwrite and discard the wildcard stuff I set up just now. :confused:

You might have that cert still laying around. What's the output of:

certbot certificates
1 Like

What I ended up doing is repeating the same command as before, only adding both domains for arguments:

certbot --dns-linode --dns-linode-credentials ~/.secrets/certbot/linode.ini
-d *.heystefan.com -d heystefan.com -i nginx

Hoping that certbot will be able to figure it out and skip steps if necessary.
Which is exactly what happened! :slight_smile: Every domain is working now.
Thanks again!

1 Like

It doesn't really—it's just that it makes a new certificate that doesn't include the old name, while the old certificate (which still exists) doesn't include the new name. If your web server has just a single virtual host for the apex domain and subdomain(s), it will have to¹ be configured to pick one certificate or the other, meaning that one name will fail.

The solution you found (issuing a certificate containing both names on a single certificate) is exactly right, because then the web server is configured to use that one, and it's valid regardless of which name the client connects under. Glad you figured it out!

If you can confirm that one of the old single-name certificates is no longer used in your configuration, you could choose to delete it with certbot delete to prevent Certbot from renewing it automatically in the future. Using certbot certificates can help confirm which is which (and you could grep -r thatcertificatename /etc/nginx to make sure there are no remaining references to it in your nginx configuration).

¹ There's no fundamental technical reason for this limitation, but the most popular web servers all have a notion of "one certificate per HTTPS virtual host".

1 Like

With an extra note that it is possible to have two separately used certificates per HTTPS virtualhost if their key algorithm is different. I.e., RSA and ECDSA.

Ok, thanks @schoen, everything is super clear now after this post.
I've removed the unused certificate.