Renew dry run – nginx: [error] open() "/run/nginx.pid" failed

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:

opendata-stage.schleswig-holstein.de

I ran this command:

certbot renew --dry-run

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log                                                                                      
                                                                                                                                              
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -                                                               
Processing /etc/letsencrypt/renewal/opendata-stage.schleswig-holstein.de.conf                                                                 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -                                                               
Cert not due for renewal, but simulating renewal for dry run                                                                                  
Plugins selected: Authenticator nginx, Installer nginx                                                                                        
Renewing an existing certificate                                                                                                              
Performing the following challenges:
http-01 challenge for opendata-stage.schleswig-holstein.de
Waiting for verification...
Cleaning up challenges
nginx: [error] open() "/run/nginx.pid" failed (2: No such file or directory)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Afterwards I have to kill nginx and restart it. A well-known problem I guess, but I could not find a working solution yet.

The operating system my web server runs on is (include version):

Ubuntu 20.04

My hosting provider, if applicable, is:

self-hosted

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 0.40.0

My renew config is:

# renew_before_expiry = 30 days
version = 0.40.0
archive_dir = /etc/letsencrypt/archive/opendata-stage.schleswig-holstein.de
cert = /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/cert.pem
privkey = /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/privkey.pem
chain = /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/chain.pem
fullchain = /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = XXXXXXXXXXXX
authenticator = nginx
installer = nginx
server = https://acme-v02.api.letsencrypt.org/directory

That describes an nginx config problem. First, is nginx running prior to running certbot renew ? Because it must be running before using Certbot with --nginx plugin like you do. Certbot will start a copy of nginx outside of systemd if it is not and this can cause problems.

Assuming so, what does this show?

sudo nginx -t

And, your Ubuntu version should easily support the snap install of Certbot. Your 0.40 version is very very old. See below for install instructions. Just follow them carefully.

3 Likes

Thanks for your reply. Nginx is running when updating the certs:

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

We know it's an old certbot version, but we wanted to use the ppa instead of snapd. We changed to snapd now. The steps we followed:

sudo apt install snapd
sudo apt remove certbot && sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot certonly --nginx

This worked like a charm with no downtime. Now the renew --dry-run command works.

In our nginx server config, we left these lines:

ssl_certificate /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/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

We also have a basic auth active in our main server block, this is why we have this block as well:

# ACME-challenge
location ^~ /.well-known/acme-challenge/ {
  auth_basic off;
  root /var/www/_letsencrypt;
}

Is this still the way to go? I couldn't find any info in the documentation.

Ubuntu 20 has snap pre-installed so not sure why you did that step. But, the rest look correct. Just to confirm, what does this show: sudo certbot --version

This may be a problem. It would not cause an error about the pid but might interfere with how Certbot --nginx handles the challenge.

With --nginx Certbot makes a temp change to your server block such that the challenge is replied directly by a "return" statement and is not processed by your location block setting auth_basic off.

This wouldn't cause a "pid" error but perhaps a validation error. But, your first post shows getting a cert so for whatever reason that much seems fine.

What is the result now with a current Certbot?

sudo certbot renew --dry-run

You didn't use sudo in your first post. Don't you need that for controlling nginx since you use --nginx option?

1 Like

True, this step wasn't needed.

certbot 3.1.0

$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/opendata-stage.schleswig-holstein.de.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for opendata-stage.schleswig-holstein.de

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded: 
  /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Btw. this did not work without my ACME challenge location block turning disabling auth basic.

I just forgot to add sudo, ofc. I need sudo privileges to control nginx.

Okay good. Looks like it is working now.

As for this ...

I don't see how that would matter when using the --nginx plugin. The way that works is by inserting a location block that uses an equal sign match. This takes precedence over all other location blocks. An example is shown below.

Did you change to --webroot method? Would you show contents of this: /etc/letsencrypt/renewal/opendata-stage.schleswig-holstein.de.conf

Sample Certbot --nginx plugin changes. The last line is the highest priority location block for nginx.

server {rewrite ^(/.well-known/acme-challenge/.*) $1 break; # managed by Certbot

    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/html;

location = /.well-known/acme-challenge/MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg {default_type text/plain;return 200 MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg.AwQwgwgwzwgwJwgw4wew3wrwxwiw-wpwvwqwxwBwswT;} # managed by Certbot

}

1 Like
# renew_before_expiry = 30 days
version = 3.1.0
archive_dir = /etc/letsencrypt/archive/opendata-stage.schleswig-holstein.de
cert = /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/cert.pem
privkey = /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/privkey.pem
chain = /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/chain.pem
fullchain = /etc/letsencrypt/live/opendata-stage.schleswig-holstein.de/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = XXXXXXXXXXXXXXXX
authenticator = nginx
installer = nginx
server = https://acme-v02.api.letsencrypt.org/directory
key_type = ecdsa

Perhaps the issue stems from my ACME challenge location block, which was also active before, but without disabling basic auth. This may have led to conflicts between the location blocks.

Yes, I can confirm that completely removing that location block also allows the renewal process to work. This confirms that ACME challenges function even with basic auth enabled, as the Let's Encrypt-inserted location block takes precedence over the basic auth configuration.

Apologies for the misleading information, and thank you for resolving my issue.

2 Likes