Certbot will not modify the nginx conf file

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:

sudo certbot -i nginx certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d example.com \
  -d *.example.com

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/example.com.conf)

It contains these names: example.com

You requested these names for the new certificate: example.com, *.example.com.

Do you want to expand and replace this existing certificate with the new
certificate?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(E)xpand/(C)ancel: E
Renewing an existing certificate for example.com and *.example.com
Waiting 60 seconds for DNS changes to propagate

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2023-11-28.
These files will be updated when the certificate renews.

NEXT STEPS:
- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

My web server is (include version): Nginx 1.22

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

I can login to a root shell on my machine (yes or no, or I don't know): Yes

My configuration file in nginx for the domain is

sudo nano /etc/nginx/sites-available/www.example.com
server {
    listen 80;
    server_name example.com;
    return 301 http://www.example.com$request_uri;
}
 
server {
    listen 80;
    server_name www.example.com;
 
    location / {
        proxy_pass http://192.168.20.11;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

I remember that when I used the older version in the past. certbot, so after generating the certificates, paths were also added to the nginx configuration files. My configuration file looked like this

server {
    server_name example.com;
    return 301 http://www.example.com$request_uri;

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.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 {
    server_name www.example.com;
 
    location / {
        proxy_pass http://192.168.20.11;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.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 {
    if ($host = example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name example.com;
    return 404; # managed by Certbot


}
 
server {
    if ($host = www.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name www.example.com;
    return 404; # managed by Certbot


}

Why doesn't certbot edit the configuration file now?

This is why certbot won't modify nginx config. You told it not to do it, that's what certonly means.

Just run certbot install

And if you want both issue and install, use certbot with no subcommand

5 Likes

That seems like a contradiction:
-i nginx = use nginx plugin to install the cert into the nginx configuration.
certonly = "To just obtain the certificate without installing it anywhere, the certbot certonly (“certificate only”) command can be used."
User Guide — Certbot 2.6.0 documentation (eff-certbot.readthedocs.io)

Install AND don't install.
I'm surprised it did anything at all.

5 Likes

Does this command also modify the conf file?

sudo certbot -i nginx \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d example.com \
  -d *.example.com

It should try to install the cert into the nginx config.
But that can be hit or miss when one uses wildcards certs and FQDN server name definitions.

3 Likes

But expanding an already existing cert would not change the cert name.
That means you may not need to reinstall it at all.

4 Likes

Installers can also be used to choose the hostnames from the webserver. AFAIK this is not done by the authenticator, but by the installer part of the plugin.

Not tested, but i.e. certbot -a nginx would require you to input the hostnames using the -d options instead of the interactive Certbot prompt asking you which hostnames you'd like to secure.

1 Like

According to that, it works fine

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.