Renewing an existing certificate: The client lacks sufficient authorization 404

Help
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 -

Domainname Http-Status redirect Sec. G
• http://rosto.io/
207.154.236.195 301 https://www.rosto.io/ 0.393 E
• http://www.rosto.io/
207.154.236.195 404 0.046 M
Not Found
• https://rosto.io/
207.154.236.195 301 https://www.rosto.io/ 1.456 A
• https://www.rosto.io/
207.154.236.195 200 1.363 A
• http://rosto.io/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
207.154.236.195 301 https://www.rosto.io/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de 0.040 E
• http://www.rosto.io/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
207.154.236.195 404 0.040 A
Not Found
• https://www.rosto.io/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de 404 5.210 A
Not Found

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:

rosto-certificate-expiration
rosto-certificate-expiration.png740Ă—205 24.3 KB

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.