Well, if you don’t open port 80 everyone that goes to (http://)your.cloud.comwon’t be redirected to https://your.cloud.com. So no one will ever be on port 80 as they are redirected. Also it’s a better user experience, because people are lazy, who types https:// these days except us nerds?
Not sure if some browsers are perhaps checking https first when you just enter an address. We shouldn’t favour a specific certificate type or issuer as long as you use a https connection.
Thank you for your response. I’m quite new to nextcloud/letsencrypt, et al.
The line in question from the script appears below.
if eval "certbot certonly --manual --manual-public-ip-logging-ok --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory $default_le"
As I understand it, the dns method uses a TXT record for domain validation instead of a validation files accessible through standard web ports (80/443). As such, that means that for each letsencrypt renewal, a new TXT records must be generated at the registrar so the back end can validate it.
I just ran through it with another test subdomain. So during install of the VM it prompts you to add the TXT record w/key. The cert is successfully created.
The question then is what happens at renewal time? The corresponding command in the renew script is :
certbot renew --quiet --no-self-upgrade
This does not reference dns at all. In fact running it manualy with a --dry-run or --force-renew just results in a failure message.
The script isn’t designed to use DNS as primary, hence “last resort” so that you at least can get a cert during script run, and then fix a regular challenge which certbot renew can handle.
Afaik it’s not possible to script renewing a DNS challenge generated cert, without human interaction which makes it (almost) impossible to do it automatically in a script.
In essence it requires use of cloudflare nameservers. Using an api key to communicate with cloudflare and generate the validation TXT records.
I’ve adjusted the letsencryptrenew.sh script as follows. I’m sure this can be cleaned up by someone more knowledgeable. What do you think?
Also, I see the letsencryptrenew.sh is run as user root by cronjob. There’s also a systemd certbot process that runs. Can you help me understand the purpose of the systemd process?
OK, so I found some info about it. Seems neat indeed. But then again, not possible without human interaction.
I’d prefer everything as easy as possible, automatic and easy to use.
Sure, we could create another flow, like; if ports are closed and use DNS if you have Cloudflare then ask user for credentials and make it variables else ask user to create an account on Cloudflare and then restart the script.
^^My end goal (like yours), is for full automation. I don’t want to think about certs every 90 days.
Once configured, the code above automates everything. I believe your cronjob executes the renew script once a day. Same script, different code. Similar to the http validation, this will skip certs until 30 days are left, then renews.
No human interaction needed. I suppose it is possible to even configure it to place the new certs in the same place your existing script does. Instead, I just copy them over there.
Perhaps a way of implementing this is to ask these questions during the initial run of the activate-ssl.sh script to build a dns compatible renew script instead of http (or the same script could contain code for both, chosen by the value of a single variable in a config file).
You are right, a cloudflare account is required to make this work. On the other hand, a number of registrar’s support API access too. Challenge is to interface properly between the hydrate script and them. I would love to code this properly, but that is way beyond my abilities.
PS. In your activate-ssl.sh script, why is there a systemd scheduled certbot process in addition to the cronjob?
Yeah, sure, the script itself renews the certs by removing them and generate new ones.
The are reasons for everything. certbot renew doesn’t renew if the script isn’t outdated, hence it can be run everyday -which also is best practice due to the fact that there is nothing 100% certain with renewing a cert.
So in short, what a few lines of bash does (like in your example) certbot renew does automagically.
instead of http
I already have an idea regarding that. If the DNS method is used then set a varable called whateveryoulike-dns and generate a renew script for DNS. If that variable is not set, then run http renew script.
No human interaction needed.
Once it’s setup no, but how much “human interaction” did you do to come to the stage where it’s working by itself? That’s what i mean.
PS. In your activate-ssl.sh script, why is there a systemd scheduled certbot process in addition to the cronjob?
The cronjob always existed, that way I can decide which commands are being run. The service is not enabled, so it’s not run.
