Renewing an existing certificate: The client lacks sufficient authorization 404


#1

My domain is: www.rosto.io

I ran this command:

sudo docker run -it --rm \
    -v faces_certs:/etc/letsencrypt \
    -v faces_certs_data:/data/letsencrypt \
    deliverous/certbot \
    certonly \
    --agree-tos \
    --dry-run \
    --renew-by-default \
    --webroot --webroot-path=/data/letsencrypt \
    -d rosto.io -d www.rosto.io

It produced this output:

Saving debug log to /var/letsencrypt/log/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for rosto.io
http-01 challenge for www.rosto.io
Using the webroot path /data/letsencrypt for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.rosto.io (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.rosto.io/.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body>\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>nginx/1.15.6</ce"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.rosto.io
   Type:   unauthorized
   Detail: Invalid response from
   http://www.rosto.io/.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0:
   "<html>\r\n<head><title>404 Not
   Found</title></head>\r\n<body>\r\n<center><h1>404 Not
   Found</h1></center>\r\n<hr><center>nginx/1.15.6</ce"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

My web server is (include version): Nginx

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

My hosting provider, if applicable, is: DigitalOcean

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.29.0.dev0

There is already a certificate issued, but I can’t renew it. I am not sure what has changed since I have succeed first time. Here is some more information I have:

I can access a file into the .well-known/acme-challenge directory, for example https://www.rosto.io/.well-known/acme-challenge/test.txt and https://www.rosto.io/.well-known/acme-challenge/test

Nginx logs when I run the certbot command:

52.29.173.72 - - [02/Feb/2019:21:36:56 +0000] "GET /.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY HTTP/1.1" 301 169 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "-"
52.29.173.72 - - [02/Feb/2019:21:36:56 +0000] "GET /.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY HTTP/1.1" 200 87 "http://rosto.io/.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
2019/02/02 21:36:56 [error] 8#8: *4 open() "/etc/nginx/html/.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0" failed (2: No such file or directory), client: 52.29.173.72, server: www.rosto.io, request: "GET /.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0 HTTP/1.1", host: "www.rosto.io"
52.29.173.72 - - [02/Feb/2019:21:36:56 +0000] "GET /.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0 HTTP/1.1" 404 153 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "-"
13.58.30.69 - - [02/Feb/2019:21:36:56 +0000] "GET /.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY HTTP/1.1" 301 169 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "-"
66.133.109.36 - - [02/Feb/2019:21:36:56 +0000] "GET /.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY HTTP/1.1" 301 169 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "-"
13.58.30.69 - - [02/Feb/2019:21:36:56 +0000] "GET /.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0 HTTP/1.1" 404 153 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "-"
2019/02/02 21:36:56 [error] 8#8: *8 open() "/etc/nginx/html/.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0" failed (2: No such file or directory), client: 13.58.30.69, server: www.rosto.io, request: "GET /.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0 HTTP/1.1", host: "www.rosto.io"
34.213.106.112 - - [02/Feb/2019:21:36:56 +0000] "GET /.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0 HTTP/1.1" 404 153 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "-"
2019/02/02 21:36:56 [error] 8#8: *9 open() "/etc/nginx/html/.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0" failed (2: No such file or directory), client: 34.213.106.112, server: www.rosto.io, request: "GET /.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0 HTTP/1.1", host: "www.rosto.io"
66.133.109.36 - - [02/Feb/2019:21:36:56 +0000] "GET /.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0 HTTP/1.1" 404 153 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "-"
2019/02/02 21:36:56 [error] 8#8: *10 open() "/etc/nginx/html/.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0" failed (2: No such file or directory), client: 66.133.109.36, server: www.rosto.io, request: "GET /.well-known/acme-challenge/-EDDkTDQiUDR16q_CcbU5G-KmEq5_IquVvNqlDqHyg0 HTTP/1.1", host: "www.rosto.io"
34.213.106.112 - - [02/Feb/2019:21:36:56 +0000] "GET /.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY HTTP/1.1" 301 169 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "-"
13.58.30.69 - - [02/Feb/2019:21:36:57 +0000] "GET /.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY HTTP/1.1" 200 87 "http://rosto.io/.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
66.133.109.36 - - [02/Feb/2019:21:36:57 +0000] "GET /.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY HTTP/1.1" 200 87 "http://rosto.io/.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
34.213.106.112 - - [02/Feb/2019:21:36:57 +0000] "GET /.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY HTTP/1.1" 200 87 "http://rosto.io/.well-known/acme-challenge/hbaBGaXKSQrvUHJql-j-0Ke-X5rjUuV0KhTPUiXaheY" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

Nginx Configuration file (I have commented out all the ipv6 references, as I thought it could have been the caveat, turns out it changed nothing):

upstream rails_app {
    server                      front:3000;
}

# redirect www.rosto.io to https
server {
    listen                      80;
    # listen                      [::]:80 ipv6only=on;
    server_name                 www.rosto.io
    return                      301 https://www.rosto.io$request_uri;
}

# redirect rosto.io to https
server {
    listen                      80;
    # listen                      [::]:80;
    server_name                 rosto.io;
    return                      301 https://www.rosto.io$request_uri;
}

# redirect https://rosto.io to https://www.rosto.io
server {
    listen                      443 ssl http2;
    # listen                      [::]:443 ipv6only=on ssl http2;
    server_name                 rosto.io;
    return                      301 https://www.rosto.io$request_uri;

    ssl                  on;

    add_header                  Strict-Transport-Security "max-age=31536000" always;

    ssl_session_cache           shared:SSL:20m;
    ssl_session_timeout         10m;

    ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers   on;
    ssl_ciphers                 "ECDH+AESGCM:ECDH+AES256:ECDH+AES128:!ADH:!AECDH:!MD5;";

    ssl_stapling                on;
    ssl_stapling_verify         on;
    resolver                    8.8.8.8 8.8.4.4;

    ssl_certificate             /etc/letsencrypt/live/rosto.io/fullchain.pem;
    ssl_certificate_key         /etc/letsencrypt/live/rosto.io/privkey.pem;
    ssl_trusted_certificate     /etc/letsencrypt/live/rosto.io/chain.pem;

    access_log                  /dev/stdout;
    error_log                   /dev/stderr info;
}

# handles https://www.rosto.io
server {
    listen                      443 ssl http2;
#     listen                      [::]:443 ssl http2;
    server_name                 www.rosto.io

    ssl                         on;

    add_header                  Strict-Transport-Security "max-age=31536000" always;

    ssl_session_cache           shared:SSL:20m;
    ssl_session_timeout         10m;

    ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers   on;
    ssl_ciphers                 "ECDH+AESGCM:ECDH+AES256:ECDH+AES128:!ADH:!AECDH:!MD5;";

    ssl_stapling                on;
    ssl_stapling_verify         on;
    resolver                    8.8.8.8 8.8.4.4;

    ssl_certificate             /etc/letsencrypt/live/www.rosto.io/fullchain.pem;
    ssl_certificate_key         /etc/letsencrypt/live/www.rosto.io/privkey.pem;
    ssl_trusted_certificate     /etc/letsencrypt/live/www.rosto.io/chain.pem;

    access_log                  /dev/stdout;
    error_log                   /dev/stderr info;

    # images are at most this size
    client_max_body_size        4M;

    # define the public application root
    root                        /var/www/rosto/public;
    index                       index.html;

    # define where nginx should write its logs
    access_log                  /var/www/rosto/log/nginx.access.log;
    error_log                   /var/www/rosto/log/nginx.error.log;

    # serve static (compiled) assets directly if they exist (for rails production)
        location ~ ^/assets/ {
        gzip_static             on;
        expires                 max;
        add_header              Cache-Control public;
    }

    # send non-static file requests to the app server
    location / {
        try_files $uri @rails;
    }

    location @rails {
        proxy_set_header        X-Real-IP  $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Host $http_host;
        proxy_set_header        X-Forwarded-Proto $scheme;
        proxy_set_header        X-Forwarded-Ssl on;
        proxy_set_header        X-Forwarded-Port $server_port;
        proxy_set_header        X-Forwarded-Host $host;
        proxy_redirect          off;
        proxy_pass              http://rails_app;
    }

    # certbot needs either port 80 or 443 open to connect
    location /.well-known/acme-challenge {
        allow                   all;
        root                    /data/letsencrypt/;
    }
}

Specific Nginx part of my docker-compose file

nginx:
    image: nginx:alpine
    depends_on:
      - front
    ports:
      - 80:80
      - 443:443
    volumes:
      - assets:/var/www/rosto/public/assets:ro
      # host directory:container directory -- 'nginx_conf:/etc/nginx/conf.d/'
      # will not work, the ./ prefix is needed here to indicate the origin
      - ./nginx_conf/production:/etc/nginx/conf.d/
      - nginx_logs:/var/www/rosto/log/
      - certs:/etc/letsencrypt
      - certs_data:/data/letsencrypt
    networks:
      - webnet

Result of letsdebug.net: https://letsdebug.net/www.rosto.io/20802
Result of https://crt.sh/?q=www.rosto.io

Any suggestions on how to tackle this problem are welcome. My cert is expiring in 20 days :frowning:


#2

Hi @edumucelli

your redirect doesn’t work.

Checking your website via https://check-your-website.server-daten.de/?q=rosto.io -

Your http + non-www /.well-known/acme-challenge is redirected to https + www /.well-known/acme-challenge.

But your http + www isn’t redirected. So something is missing.

To create this file:

In which directory did you create that file? Personally, I think it’s easier to use the “real” webroot instead of such

definitions.


#3

I think you just need to normalize the request behavior between the HTTP and non-HTTPS versions of www.rosto.io:

$ curl -X GET -IL www.rosto.io/.well-known/acme-challenge/test
HTTP/1.1 404 Not Found
Server: nginx/1.15.6
Date: Sat, 02 Feb 2019 22:13:26 GMT
Content-Type: text/html
Content-Length: 153
Connection: keep-alive

versus

$ curl -X GET -IL https://www.rosto.io/.well-known/acme-challenge/test
HTTP/2 200
server: nginx/1.15.6
date: Sat, 02 Feb 2019 22:13:39 GMT
content-type: application/octet-stream
content-length: 5
last-modified: Sat, 02 Feb 2019 20:48:48 GMT
etag: "5c560230-5"
strict-transport-security: max-age=31536000
accept-ranges: bytes

Let’s Encrypt always arrives at the port 80 request handler first (in which case you have a 404).


#4

Hi @JuergenAuer, thanks for the impressive quick reply! I am going to take a look on the redirection issues. That is the first time I am set up Nginx and Lets Encrypt. I may have messed up the redirections somehow. Thanks once again!


#5

Hi @_az thanks for this precious advice on top of the @JuergenAuer response. I will take a look what I have missed on my Nginx redirection configurations. Thanks once again!


#6

Those don’t seem to match.
Try:
--webroot --webroot-path=/etc/nginx/html \


#7

I was able to pinpoint the problem given your inputs. The issue was a missing ; in my Nginx configuration file

server_name www.rosto.io

By fixing I was able to renew the certificate.

Thanks for the quick replies and for precise diagnostic you guys made. Cheers. Ps.: Follows the fixed Nginx file with appropriate comments:

upstream rails_app {
    server                      front:3000;
}

# redirect http + non-www to https + www
server {
    listen                      80;
    listen                      [::]:80;
    server_name                 rosto.io;
    return                      301 https://www.rosto.io$request_uri;
}

# redirect http + www to https + www
server {
    listen                      80;
    listen                      [::]:80;
    server_name                 www.rosto.io;
    return                      301 https://www.rosto.io$request_uri;
}


# redirect https://rosto.io to https://www.rosto.io
server {
    listen                      443 ssl http2;
    listen                      [::]:443 ssl http2;
    server_name                 rosto.io;
    return                      301 https://www.rosto.io$request_uri;

    ssl                         on;

    add_header                  Strict-Transport-Security "max-age=31536000" always;

    ssl_session_cache           shared:SSL:20m;
    ssl_session_timeout         10m;

    ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers   on;
    ssl_ciphers                 "ECDH+AESGCM:ECDH+AES256:ECDH+AES128:!ADH:!AECDH:!MD5;";

    ssl_stapling                on;
    ssl_stapling_verify         on;
    resolver                    8.8.8.8 8.8.4.4;

    ssl_certificate             /etc/letsencrypt/live/rosto.io/fullchain.pem;
    ssl_certificate_key         /etc/letsencrypt/live/rosto.io/privkey.pem;
    ssl_trusted_certificate     /etc/letsencrypt/live/rosto.io/chain.pem;

    access_log                  /dev/stdout;
    error_log                   /dev/stderr info;
}

# handles https://www.rosto.io
server {
    listen                      443 ssl http2;
    listen                      [::]:443 ssl http2;
    server_name                 www.rosto.io;

    ssl                         on;

    add_header                  Strict-Transport-Security "max-age=31536000" always;

    ssl_session_cache           shared:SSL:20m;
    ssl_session_timeout         10m;

    ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers   on;
    ssl_ciphers                 "ECDH+AESGCM:ECDH+AES256:ECDH+AES128:!ADH:!AECDH:!MD5;";

    ssl_stapling                on;
    ssl_stapling_verify         on;
    resolver                    8.8.8.8 8.8.4.4;

    ssl_certificate             /etc/letsencrypt/live/www.rosto.io/fullchain.pem;
    ssl_certificate_key         /etc/letsencrypt/live/www.rosto.io/privkey.pem;
    ssl_trusted_certificate     /etc/letsencrypt/live/www.rosto.io/chain.pem;

    access_log                  /dev/stdout;
    error_log                   /dev/stderr info;

    # images are at most this size
    client_max_body_size        4M;

    # define the public application root
    root                        /var/www/rosto/public;
    index                       index.html;

    # define where nginx should write its logs
    access_log                  /var/www/rosto/log/nginx.access.log;
    error_log                   /var/www/rosto/log/nginx.error.log;

    # serve static (compiled) assets directly if they exist (for rails production)
        location ~ ^/assets/ {
        gzip_static             on;
        expires                 max;
        add_header              Cache-Control public;
    }

    # send non-static file requests to the app server
    location / {
        try_files $uri @rails;
    }

    location @rails {
        proxy_set_header        X-Real-IP  $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Host $http_host;
        proxy_set_header        X-Forwarded-Proto $scheme;
        proxy_set_header        X-Forwarded-Ssl on;
        proxy_set_header        X-Forwarded-Port $server_port;
        proxy_set_header        X-Forwarded-Host $host;
        proxy_redirect          off;
        proxy_pass              http://rails_app;
    }

    # certbot needs either port 80 or 443 open to connect
    location /.well-known/acme-challenge {
        allow                   all;
        root                    /data/letsencrypt/;
    }
}

#8

Indeed, that also made me think why is it asking for something from the /etc. However, it seems that the problem was an typo in the Nginx configuration file. However, I will keep a comment on the place where I store this command to investigate why it is looking for something there. Thanks anyway for your comment!


#9

By running the

sudo docker run -it --rm \
    -v faces_certs:/etc/letsencrypt \
    -v faces_certs_data:/data/letsencrypt \
    deliverous/certbot \
    certonly \
    --agree-tos \
    --renew-by-default \
    --webroot --webroot-path=/data/letsencrypt \
    -d www.rosto.io 

I now have

Saving debug log to /var/letsencrypt/log/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.rosto.io
Using the webroot path /data/letsencrypt for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/www.rosto.io/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/www.rosto.io/privkey.pem
   Your cert will expire on 2019-05-03. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - 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

However the certificate expiration date has been changed I guess: https://crt.sh/?q=www.rosto.io


#10

The question is did it use HTTP-01 or TLS-SNI-01 to obtain this most recent cert?

and why only one name?:


#11

This date also has puzzled me.

I do not know the method for the most recent certificate, but I’d say http-01 given the return of the docker run certbot:

http-01 challenge for rosto.io
http-01 challenge for www.rosto.io

Although the command I have shown here I gave only -d www.rosto.io I have tried to give both names but it apparently generated the certificate for only one domain: “Your certificate and chain have been saved at:
/etc/letsencrypt/live/rosto.io/fullchain.pem”

sudo docker run -it --rm \                                
    -v faces_certs:/etc/letsencrypt \
    -v faces_certs_data:/data/letsencrypt \
    deliverous/certbot \
    certonly \
    --agree-tos \
    --renew-by-default \
    --webroot --webroot-path=/data/letsencrypt \
    -d rosto.io -d www.rosto.io
Saving debug log to /var/letsencrypt/log/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for rosto.io
http-01 challenge for www.rosto.io
Using the webroot path /data/letsencrypt for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/rosto.io/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/rosto.io/privkey.pem
   Your cert will expire on 2019-05-03. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - 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

#12

This

creates one certificate with two domain names.

But:

Your non-www uses

CN=rosto.io
	02.02.2019
	03.05.2019
	rosto.io, www.rosto.io - 2 entries

your www uses

CN=www.rosto.io
	23.11.2018
	21.02.2019
	www.rosto.io - 1 entry

So you have two different vHosts with different certificates.

Instead of one vHost with both domain names and one certificate (with the same domain names).


#13

That looks good (HTTPS and with both names)

You can confirm it from the public cert files:
/etc/letsencrypt/live/rosto.io/fullchain.pem
/etc/letsencrypt/live/rosto.io/cert.pem


#14

Thanks for the complementary info. How do you get each of those CN informations?

I guess that the two different vHosts configuration come from my Nginx configuration file, right? I mean each of my server blocks listening to the port 443 has a different ssl_certificate_key/ssl_trusted_certificate path, like this

# redirect https://rosto.io to https://www.rosto.io
server {
    listen                      443 ssl http2;
    listen                      [::]:443 ssl http2;
    server_name                 rosto.io;
    return                      301 https://www.rosto.io$request_uri;

    ...
    ssl_certificate             /etc/letsencrypt/live/rosto.io/fullchain.pem;
    ssl_certificate_key         /etc/letsencrypt/live/rosto.io/privkey.pem;
    ssl_trusted_certificate     /etc/letsencrypt/live/rosto.io/chain.pem;
    ...
}

# handles https://www.rosto.io
server {
    listen                      443 ssl http2;
    listen                      [::]:443 ssl http2;
    server_name                 www.rosto.io;
    
    ...
    ssl_certificate             /etc/letsencrypt/live/www.rosto.io/fullchain.pem;
    ssl_certificate_key         /etc/letsencrypt/live/www.rosto.io/privkey.pem;
    ssl_trusted_certificate     /etc/letsencrypt/live/www.rosto.io/chain.pem;
    ...
} 

I thought that was the correct way of doing, i.e., having one per domain. But as I got inspired by different sources of a Nginx config file on the Internet I may have misunderstood. Should I keep then only one set of .pem files for both blocks?


#15

It’s Nginx’s default root when you don’t specify anything else.

https://nginx.org/en/docs/http/ngx_http_core_module.html#root

You don’t need to specify any particular root in a virtual host that redirects everything, but since the redirect wasn’t working due to the typo, that’s what happened.


#16

Alright! Thanks a lot for the clarification!


#17

Now it also seems fixed. I have fixed the second server block (using port 443) to use only the set of .pem files from /etc/letsencrypt/live/rosto.io/ instead of /etc/letsencrypt/live/www.rosto.io/ like following:

# handles https://www.rosto.io
server {
    listen                      443 ssl http2;
    listen                      [::]:443 ssl http2;
    server_name                 www.rosto.io;
    
    ...
    ssl_certificate             /etc/letsencrypt/live/rosto.io/fullchain.pem;
    ssl_certificate_key         /etc/letsencrypt/live/rosto.io/privkey.pem;
    ssl_trusted_certificate     /etc/letsencrypt/live/rosto.io/chain.pem;
    ...
}

As you have explained that passing multiple domains (-d rosto.io -d www.rosto.io) “creates one certificate with two domain names.” I will from now on keep doing that way to avoid having multiple certificates by mistake.

Now when I inspect the certificate information I see no more expiration day as 21 February but as 3rd of May as shown below:


#18

I have to say keep up the good work and the great community you guys have here. I would not have figured it out by myself without the help you gave me here. Thanks a lot @JuergenAuer, @_az, @rg305, and @mnordhoff!


#19

It’s the same (own) tool used earlier ( https://check-your-website.server-daten.de/?q=rosto.io ).

If you scroll down, there are the two connections (http + https with the ip addresses) and the certificates listed.

There I saw, that both connections are correct, but with different certificates.

Yep, now your two connections use the same certificate.

It’s not a mistake having different certificates. Sometimes www and non-www have different content, use different ip addresses etc. But if content + ip address the same, I find it easier to have only one certificate.


This community is pure gold!