Nginx Reverse Proxy Multi-file configuration

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:

server {
        listen 80;
        listen [::]:80;

        server_name portainer.eddienetworks.ddnsfree.com www.portainer.eddienetworks.ddnsfree.com;

        location / {
                proxy_pass http://192.168.1.242:9000;
                proxy_set_header Host $host;
        }
}

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?

Thanks again for all the support,

Eduardo

1 Like

Hello @eddie welcome to the forum!

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):

https://hlandau.github.io/acmetool/userguide

https://certbot.eff.org/docs/

https://certbot.eff.org/docs/using.html#certbot-command-line-options

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.

rg305,

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:

www.eddienetworks.ddnsfree.com
test.eddienetworks.ddnsfree.com

are working fine (redirecting HTTP to HTTPS).

Thanks

Replying @Rip

Blockquote

My domain is: eddienetworks.ddnsfree.com, *.eddienetworks.ddnsfree.com

I ran this command: certbot --nginx followed by certbot certonly --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory -d '*.eddienetworks.ddnsfree.com' -d eddienetworks.ddnsfree.com

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

This is much simpler than it sounds.

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.

So in the end I changed all the vhost files by myself. For auto renewal I set a cron job.

Thanks for all again

1 Like

What does the job look like?
Did you test it?

Hi, the crontab file is:

0       1       *       *       *       /usr/bin/certbot renew >> /var/log/letsencrypt/renew.log
0       0       *       *       0       rm -r /var/log/letsencrypt/*

And the output of last night:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/eddienetworks.ddnsfree.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/nextcloud.eddienetworks.ddnsfree.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificates are not due for renewal yet:
  /etc/letsencrypt/live/eddienetworks.ddnsfree.com/fullchain.pem expires on 2021-11-13 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

So I believe everything is working ok.

The cron job runs, yes.
But it runs at the top of the hour (1 a.m.), this is a peak time and should be avoided.

It checks to see if any cert needs renewing and doesn't find one, so it doesn't really need to do anything.

Please show the outputs of:
certbot --version
certbot certificates
cat /etc/letsencrypt/renewal/*
systemctl list-timers | grep certbot

OP is using certbot 1.16.0 which incorporates the random sleep timer since v. 0.29.0.

1 Like

So that answers maybe two of the five things.

  1. certbot --version
    1.16.0

  2. 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:

  1. How many certs are there and when will they come due for renewal?
    certbot certificates

  2. Which method(s) are the certs configured to use during renewal (DNS-01 / HTTP-01 / manual / nginx / standalone / certonly / webroot)?
    cat /etc/letsencrypt/renewal/*

  3. Did the last certbot installation and successful cert issuance automatically create a renewal job?
    systemctl list-timers | grep certbot

Sorry for the delay: I was attending uni's lectures

For @rg305 questions:

  1. How many certs are there and when will they come due for renewal?
    certbot certificates
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: eddienetworks.ddnsfree.com
    Serial Number: 47ea975a5fc8b1f254c7a6eebbe93cd9ebf
    Key Type: RSA
    Domains: *.eddienetworks.ddnsfree.com eddienetworks.ddnsfree.com
    Expiry Date: 2021-11-13 09:30:18+00:00 (VALID: 88 days)
    Certificate Path: /etc/letsencrypt/live/eddienetworks.ddnsfree.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/eddienetworks.ddnsfree.com/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  1. 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,
  1. 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.

1 Like

This won't find it:

Try it as I showed it:

OR
find / -name snap.certbot.renew.timer
ls -l /etc/systemd/system/*.timer

Hi @rg305,

Here is the response of the command you asked me to try

sudo find / -name snap.certbot.renew.timer                                                                           ~
ls -l /etc/systemd/system/*.timer
[sudo] password for eddie:
zsh: no matches found: /etc/systemd/system/*.timer

and

sudo systemctl list-timers | grep certbot                                                                            ~
sudo: systemctl: command not found

As I mentioned before, Alpine Linux doesnt work with systemd. From Schedule jobs with systemd timers, a cron alternative:

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.

OK, so there is one cert:

that covers the names:

It was obtained using:

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).

Falls short on full automation.

You mean I will need to be redo the manual process every 90 days? The part of running

certbot certonly --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory -d '*.eddienetwoks.ddnsfree.com' -d eddienetworks.ddnsfree.com -v

and then pasting the text string?

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:

  1. 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]
  2. 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]
  3. 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.

Thanks again

1 Like