I’ve removed certbot-auto + /opt/eff.org virtualenv and installed certbot from the official centos package and now I’ve got certbot 1.4 up and running and it’s displaying correctly the info from the installed certificates in both the production/staging servers.
So, given the current situation let’s come back to the initial question… considering certbot certificates output:
How would i add new certificates not only for the existing production domain names domain1 domain2 domain3 domain4 domain5 domain6 domain7 set but also for the staging domain names local1.domain1 local1.domain2 local1.domain3 local1.domain4 local1.domain5 local1.domain6 local1.domain7.
I mean, the whole idea is being able to use ssl while testing my webapps in the staging box… and right now I’ve got local1.domain1 ... local1.domain7 in /etc/hosts pointing out to the staging server ip
The staging servers are centos vagrant boxes spinned out from my windows development machine, they’re named local1, local2, local3, ... so on my development box my hosts file would look like:
So answering your question, yeah, the ips would be private ones and they couldn’t be reached from the outside. I’m giving you all this info so you’ll be able to advice properly how to proceed, I mean, right now my nginx files look something like:
server {
server_name domain1 local1.domain1;
root /var/www/domain1;
# common
include common/security.conf;
include common/general.conf;
# flask app
location / {
proxy_pass http://unix:/run/gunicorn/domain1.socket;
}
}
and I’d have one of these nginx files for each one of my domains (domain1, … , domain7)
And the same goes for the hostnames, as they only exist in your hosts file, right?
In that case you can't use a Let's Encrypt certificate for those specific hostnames, as the Let's Encrypt validation server needs to be able to validate the hostname, either by connecting to its IP address or by resolving a special TXT resource records on the DNS zone.
You could however use wild card certificates. I.e., get a certificate for *.domain1, *.domain2 et cetera. This would however require the use of the dns-01 challenge, which could be harder to set up compared to the http-01 challenge. Another reason to switch to the CentOS package manager to install certbot: it's relatively hard to install one of the DNS plugins while using certbot-auto.
Yeah, exactly, both vagrant boxes ips and hostnames would be private to my development box
Not sure I haven't understood much out this explanation though but let me see whether I've understood a bit though... are you suggesting i should delete somehow the existing approved certificates for domain1, ..., domain7 and somehow create new certificates for *.domain1, ..., *.domain7? I didn't know it was possible to get certificates for wildcarded domains?
Another option (just random thought without any theorical basis) maybe... would it be possible somehow to use the approved certificates for the official domains in the staging boxes?
Anyway, just to let you know at this point I'm a bit confused so if you could please suggest me what'd be the easiest way to proceed here, I'd really appreciate it . I think at this point I've made clear my main goal is being able to use ssl in the staging boxes before deploying to production, so... This shouldn't be a very rare use-case, right?
I would recommend expanding the existing certificates, not deleting them and making a new one. Although in the end it comes down to the same. Although if you delete the certs, try making the wildcards and for some reason don't succeed, you've got zero certificates Always make a backup though.
Sure, I don't see why not. It would mean using the "regular" hostnames though, not local.domain variants.
Not a very rare use case no. Sometimes people use their own CA for local developing, as it's perfectly possible to include your own root on your own systems. However, using Let's Encrypt certificates is possible too.
Ok, so, in terms of certbot commands, how should i proceed to expand the existing ones?
That's actually a wise advice... speaking of which... I think when I'd copied from production to staging I'd only copied the /etc/letsencrypt folder and I forgot to copy also the /var/lib/letsencrypt one, which seems to also contain *.pem files. Although I guess many of the errors when doing curl weren't being produced by that fact though (speaking of which, certbox nginx metadata would contain subdomain support although i didn't understand much of the syntax).
Really interesting, thanks, I'll read through.
Mmm, just to be sure i've understood... you mean, before deploying i'd need to edit the hosts files so domain1, ... , domain7 would point out to the staging boxes, right? Mmm, if that's the case, it seems like a quite unoptimal way of developing
Oh yeah, that's the whole goal of this thread... I'd like to learn how to use the Let's encrypt certificates on staging rather than some manual openssl generated ones...
In any case, please let me know how should I proceed from here so I can expand the existing ones to support wildcards.
Hm, my certbot hasn't put pem files in /var/lib/letsencrypt, only some backups from the apache plugin. But backing up that directory doesn't hurt.
For fully automated certificate generation, you'd need to use one of the DNS plugins. Which plugin you'll need, depends on which DNS server is used for your domains. The plugin needs to add and remove TXT records to the DNS zone files of the domains for the validation required for a wildcard certificate. You can click on the DNS plugin from the list of plugins to go to the documentation of that plugin.
For example, if CloudFlares DNS services is used:
certbot --cert-name bpl.expert --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini -d domain1 -d *.domain1 -d domain2 -d *.domain2 (also include for domain3 to 7 in the same manner obviously)
I myself run my own BIND and use the dns-rfc2136 plugin.
It seems the certbot centos rpm package doesn't include any additional plugin while the certbot github repo has by default many of them. I guess to install the https://pypi.org/project/certbot-dns-digitalocean/ I'd need to enable the virtualenv first and pip install it, right? Or is there a more "proper" way to install plugins?
Ok, cool, I've already generated a Digitalocean token so it seems it'll be a matter of tweaking the command you've posted somehow after I install the digitalocean plugin... btw, let's say i run the command you've posted but i don't have the nginx files in the server, in that case certbot won't be able to edit them but... would it still be possible to do that job with certbot or I'd run out of luck and I'd need to edit all the nginx config files myself manually?
. I think at this point I've made clear my main goal is being able to use ssl in the staging boxes before deploying to production, so... This shouldn't be a very rare use-case, right?
Always make a backup though.
