So, with the help of you guys (thanks again) I managed to configure Let's Encrypt for my main domain and the wildcard. However, I have a couple of services that have files similar to the one below:
As it's seen, these are meant to be under the wildcard certificate, but the pages are still with no encryption. I modified one the files manually and it worked fine but is there a way to make it automatically?
You seem to have missed some of the questions that would help us to resolve your issue much quicker... Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
The vhost shown is only for HTTP (listen 80;).
You could change the server_name there to the wildcard: *.eddinetworks.ddnsfree.com
OR .eddinetworks.ddnsfree.com
[depending on the webserver software and version]
But I think you might be speaking more about HTTPS (TLS/SSL).
If so, that generally requires an additional vhost config (and it listens on port 443).
The configuration of it is dependent mostly on the webserver software and your desires.
It can be as simple as the vhost config shown with the added necessary lines.
Like turning SSL on, using the certificate files, setting the secure ciphers and protocols...
It might also require some special proxy lines to ensure things pass through as expected.
Let's see if I can explain better what I want to achieve. Like portainer, I had a file for pihole the same way as the portainer one (just replacing portainer for pihole and different ip addresses). To make it use the SSL certificate (HTTPS) I modified the file to mimic the final version of the plain eddienetworks.ddnsfree.com. The resulting file is:
server {
listen 80;
server_name pihole.eddienetworks.ddnsfree.com *.pihole.eddienetworks.ddnsfree.com;
return 301 https://$host$request_uri;
}
server {
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/eddienetworks.ddnsfree.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/eddienetworks.ddnsfree.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
server_name pihole.eddienetworks.ddnsfree.com *.pihole.eddienetworks.ddnsfree.com;
location / {
proxy_pass http://192.168.1.240;
proxy_set_header Host $host;
}
}
And then the website loads encrypted. My question is if there's a way to do this to every file (or the ones I choose) automatically or only manually. Also, a matter of information, any variation of the website that is not included in one the proxy files such as:
It produced this output: changed the file and made encrypted the website
The operating system my web server runs on is (include version):
Alpine Linux 3.14 - Reverse Proxy (Nginx 1.20.1)
Ubuntu Hirsute - Website (Apache/2.4.46)
My hosting provider, if applicable, is: Vodafone Australia
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.16.0
There is an nginx system (that is also a proxy but that is not important) that uses certbot to get certificates (some of which are wildcards and that requires DNS auth which you haven't said if you can use a DNS API so we don't know if that can be automated or you must run it manually every 60-90 days).
In brief: nginx using certbot using certonly and --manual
So, where is the problem?
For any new site, the secure site needs to be done only once. You could try having certbot create it automatically for you (while it gets the new cert) OR you could make the vhost config file yourself.
As for the renewals, certbot would require a DNS API configured to handle the wildcards certs automatically. If any certs exist that don't contain wildcards, those could be renewed automatically via HTTP authentication.
Will running certbot at the top of the hour be affected by spikes? No, version 1.16.0 incorporates a random sleep timer.
Still pending:
How many certs are there and when will they come due for renewal? certbot certificates
Which method(s) are the certs configured to use during renewal (DNS-01 / HTTP-01 / manual / nginx / standalone / certonly / webroot)? cat /etc/letsencrypt/renewal/*
Did the last certbot installation and successful cert issuance automatically create a renewal job? systemctl list-timers | grep certbot
Which method(s) are the certs configured to use during renewal (DNS-01 / HTTP-01 / manual / nginx / standalone / certonly / webroot)? cat /etc/letsencrypt/renewal/*
cat /etc/letsencrypt/renewal/* ~
# renew_before_expiry = 30 days
version = 1.16.0
archive_dir = /etc/letsencrypt/archive/eddienetworks.ddnsfree.com
cert = /etc/letsencrypt/live/eddienetworks.ddnsfree.com/cert.pem
privkey = /etc/letsencrypt/live/eddienetworks.ddnsfree.com/privkey.pem
chain = /etc/letsencrypt/live/eddienetworks.ddnsfree.com/chain.pem
fullchain = /etc/letsencrypt/live/eddienetworks.ddnsfree.com/fullchain.pem
# Options used in the renewal process
[renewalparams]
account = 2491055be5418d2dd416c418ca2124e3
authenticator = manual
server = https://acme-v02.api.letsencrypt.org/directory
pref_challs = dns-01,
Did the last certbot installation and successful cert issuance automatically create a renewal job? systemctl list-timers | grep certbot
The reverse proxy is under Alpine Linux so I does not have systemd. It uses init.d instead.
sudo /etc/init.d/list-timers | grep certbot ~
[sudo] password for eddie:
sudo: /etc/init.d/list-timers: command not found
whereis list-timers ~
list-timers:
So I don't have list-timers either. Please, lemme know if you need any further information. I also changed the cron time even if it does not seem to be necessary anymore.
While unlikely, you may use a Linux distribution (or BSD or other Unix-like system) that does not have systemd. If you use *BSD,Alpine Linux, Gentoo, Knoppix, Void, Tiny Core, Devuan, Artix Linux, and others using a different init system other than systemd, then this article may be just a curiosity. Read on, or simply enjoy the cron you have.
And there was no job automatically inserted by the installation and subsequent cert issuance by certbot (likely due to the "Alpine Linux" mentioned).
[which you overcame by creating your own cron job]
Well...
Sadly, manual authenticated certs can't be automated (without modification).
So when the time comes for it to be renewed, your cron job will run, certbot will see that it should try to renew the cert and then it will fail while trying to do so (as now configured); Because manual authentications must be run interactively (can't be done at 1a.m., or at any time, by the system without modification).
Yes; certbot hasn't been configured to add those required TXT entries for you.
So it will start the process and either time out waiting or fail when proceeding because LE can't find them in your DNS zone.
These failures will be logged every time the cron job runs and the cert is nearing expiry.
Each time it tries a new pending authorization will be created.
That will continue until there are too many pending authorizations and it will start logging that new error.
This will be happening while the cert is still active (between day 60 and day 90).
And you won't realize it (unless you look at the LE logs or configure it to send you an email on any failure) until the cert actually expires.
Then you will be like: Why did my cert expire? I set the cron job to renew it!
And that is what I'm trying to avoid (yeah, all of that).
So there are three choices to overcome this upcoming lack of automated renewal situation:
Perpetually renew the cert manually each time before it expires (less than 90 days from last issuance). [You can remove the cron job to run certbot renew and have it send you an email instead]
Use a DNS Service Provider (DSP) that allows for API updates to your DNS zone and automate the DNS updates within certbot.
[if your current DNS provider doesn't support API updates, another DSP can be easily delegated to - more on that later, if needed]
Don't use wildcard certs (which require DNS-01 authentication) - switch to HTTP-01 authentication or TLS-ALPN-01 authentication.
So far what I did was creating a post at Dynu.com to see if anyone there can provide any help with item 02. Meanwhile I'll also try to find how to do that.