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.
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.
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?
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.
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.
Hoping that certbot will be able to figure it out and skip steps if necessary.
Which is exactly what happened! Every domain is working now.
Thanks again!
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".
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.
Thank you! Can't believe I missed that. 
Every domain is working now.