I want to minimize the risk of affecting api.example.com every time I make a non critical change.
What’s the best way to hand SSL certifications with LetsEncrypt in this situation?
Pardon me if this is a trivial question; I’ve only been handling my own certs for the last 8 months. Before that, I didn’t worry about it or let my host provider deal with it.
Thanks @cool110 and @serverco
That’s what I thought. I used the certbot for Server A (I believe; I did this 8 months ago). I tried using GetSSL for Server B (recommended as an alternative by LetsEncrypt) mostly because I wanted to try something new.
I think GetSSL is pulling my original example.com certificate created on Server A. Maybe this is just a limitation of GetSSL?
GetSSL shouldn’t be pulling your config from server A (unless you have specifically set it up, and given it access from server B to server A). Can you provide a bit more information ?
On Server B, I run getssl -c example.com. The expected directories and
files are created. When I edit the config file, I see it has listed all the
subdomains from Server A. Indeed, when I run getssl example.com, it says my
certs don’t need to be renewed (the certs on Server A were renewed this
morning).
On Server B, when I try to run getssl -c api.example.com (which is what I
really want to do), it prepends www to it. So in the configs, it is
referencing www.api.example.com
Yes, if you do “getssl -c example.com” it will do it’s best to create your config file for you. If there is an existing certificate for the example.com, it will add the SAN (subject alternate domains) for that domain to the config, taking them from the existing cert. Since the certs are valid ( you renewed them this morning) it is saying they are OK and don’t need renewing. You could use the “if” option to force renewal, but you don’t need to as your server A certs are correct.
You want to run “getssl -c api.example.com” (as you did ) because you want a cert for api.example.com on server B. By default it does add www as an alternate (perhaps it shouldn’t for subdomains, an interesting discussion). You can easily remove the www.api.example.com from list of SANS in the config file though, and you should then be able to obtain the cert for api.example.com ( again using -f if you have currently have a self signed cert, or other that you want to replace )
@serverco new problem: getssl complains about an ACL not being specified.
the getssl github page mentions that this MUST be specified. but … … what’s an ACME challenge and how do I create it? nothing on getssl’s github page explains what it is or how to generate it and “research” (i.e. the first 3 pages of Google search results) don’t help either.
EDIT: nevermind. I’ll just stick with the certbot. I think (think!) they didn’t have a package for nginx when I first looked at it, but now they certainly do.
For anyone else reading - you can see an overview of how the letencrypt system works ( including ACME challenges) at https://letsencrypt.org/how-it-works/
For the specific error here, in the getssl config there should be a ACL ( acme challenge location ) specified for every Domain name / alternate (SAN) that is specified - so it knows where to place the challenges that ACME requires.
