Certificate is there and valid but certbot fails


#1

I have been using certbot for the past year managing our server’s certs so I assumed when I upgraded certbot to the 0.28 as stated as required here in order for our domains to continue to be secured that the renew would work fine given it has for the past year. However, that is not the case, as we get the error below. When navigating the domain it is properly secured with https and has the green lock throughout so I am completely confused.

My domain is: SpottingQuotes.ca

I ran this command: sudo certbot renew --dry-run

It produced this output:
Attempting to renew cert (www.spottingquotes.ca) from /etc/letsencrypt/renewal/www.spottingquotes.ca.conf produced an unexpected error: Failed authorization procedure. www.spottingquotes.ca (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.spottingquotes.ca/.well-known/acme-challenge/-hC1mlMHz8dKw29R2TZhVWmxnPGx3D3j8XIFq-0CiTY: "\n\n \n \n \n ". Skipping.
The following certs could not be renewed:
/etc/letsencrypt/live/www.spottingquotes.ca/fullchain.pem (failure)


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

The following certs were successfully renewed:
/etc/letsencrypt/live/spottingquotes.ca/fullchain.pem (success)

The following certs could not be renewed:
/etc/letsencrypt/live/www.spottingquotes.ca/fullchain.pem (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)


Running post-hook command: service nginx reload
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: www.spottingquotes.ca
    Type: unauthorized
    Detail: Invalid response from
    http://www.spottingquotes.ca/.well-known/acme-challenge/-hC1mlMHz8dKw29R2TZhVWmxnPGx3D3j8XIFq-0CiTY:
    "\n\n \n \n

    \n "

    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.
    quotr@SpottingQuotes:~/tmp/letsencrypt/renewal$ sudo certbot renew --dry-run
    Saving debug log to /var/log/letsencrypt/letsencrypt.log

My web server is (include version): nginx/1.10.2

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

My hosting provider, if applicable, is: Domain is GoDaddy’s but the server is hosted in AWS.

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):certbot 0.28.0


#2

Well, you actually DO have a HTTPS error:

This server could not prove that it is www.spottingquotes.ca ; its security certificate is from spottingquotes.ca . This may be caused by a misconfiguration or an attacker intercepting your connection.

You seem to have separate certificates for the www and non-www FQDN of your domain:

And it seems you’ve mis-configured your webserver. At least: the virtualhost for the www-FQDN sends a certificate with only the base, non-www FQDN.

Anyway, that is a pesky error for all your website users, but it wouldn’t bother the Let’s Encrypt validation: it doesn’t care what certificate is installed.

Unfortunately, the output you’ve provided doesn’t really have the necessary information. Could you please give us the entire output? Including which plugin was used?


#3

Here is the full output:

quotr@SpottingQuotes:~/tmp/letsencrypt/renewal$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/spottingquotes.ca.conf


Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for spottingquotes.ca
Waiting for verification…
Cleaning up challenges


new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/spottingquotes.ca/fullchain.pem



Processing /etc/letsencrypt/renewal/www.spottingquotes.ca.conf


Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.spottingquotes.ca
nginx: [warn] conflicting server name “spottingquotes.ca” on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name “www.spottingquotes.ca” on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name “spottingquotes.ca” on [::]:80, ignored
nginx: [warn] conflicting server name “www.spottingquotes.ca” on [::]:80, ignored
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (www.spottingquotes.ca) from /etc/letsencrypt/renewal/www.spottingquotes.ca.conf produced an unexpected error: Failed authorization procedure. www.spottingquotes.ca (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.spottingquotes.ca/.well-known/acme-challenge/IrYehpHRSBKX3w0tb35fsOSbG4Bc5FL1hg2_rQuBxOU: "\n\n \n \n \n ". Skipping.
The following certs could not be renewed:
/etc/letsencrypt/live/www.spottingquotes.ca/fullchain.pem (failure)


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

The following certs were successfully renewed:
/etc/letsencrypt/live/spottingquotes.ca/fullchain.pem (success)

The following certs could not be renewed:
/etc/letsencrypt/live/www.spottingquotes.ca/fullchain.pem (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)


Running post-hook command: service nginx reload
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:


#4

Hmm, very strange. So the non-www challenge is succesful, but the www-FQDN challenge gives a lot of warnings and fails?

Could you provide your nginx configuration file?


#5

Here is the sites-available config:

# These are some “magic” Nginx configuration options that aid in making
# WebSockets work properly with Passenger Standalone. Please learn more
# at http://nginx.org/en/docs/http/websocket.html
map $http_upgrade $connection_upgrade {
default upgrade;
‘’ close;
}

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name $HOSTNAME spottingquotes.ca www.SpottingQuotes.ca;

# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://www.$server_name$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name spottingquotes.ca www.spottingquotes.ca; # managed by Certbot

# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /etc/letsencrypt/live/spottingquotes.ca/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/spottingquotes.ca/privkey.pem; # managed by Certbot
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

# modern configuration. tweak to your needs.
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers ‘ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256’;
ssl_prefer_server_ciphers on;

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security “max-age=15768000; includeSubDomains”;

# OCSP Stapling —
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

## verify chain of trust of OCSP response using Root CA and Intermediate certs
# ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver 127.0.0.1;

root /home/quotr/app/current/public;

# Failfast hack attempts for exploits and unsupported languages
#Annoying PHP Hack Attempts. Just drop the connection (code 444)
location ~ ^/cgi-bin { return 444; log_not_found off; }
location ~ .(?:php|aspx|asp) { return 444; log_not_found off; }   location ~ php\.cgi { return 444; log_not_found off; }
location ~ ^/images/stories { return 444; log_not_found off; }
location ~ myadmin { return 444; log_not_found off; }

location /resque {
return 404;
}

location ~ .(css|png|ico) {
}

location / {
if (-f /var/www/quotr-public/system/maintenance.html) {
return 503;
}

# Nginx to forward all requests for www.foo.com
# to the Passenger Standalone instance listening on port 4000.
proxy_pass http://127.0.0.1:3000;

# These are “magic” Nginx configuration options that
# should be present in order to make the reverse proxying
# work properly. Also contains some options that make WebSockets
# work properly with Passenger Standalone. Please learn more at
# http://nginx.org/en/docs/http/ngx_http_proxy_module.html
proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_buffering off;
}

#Far-future expires header
location ~ ^/assets/ {
expires 1y;
add_header Cache-Control public;
add_header ETag “”;
}

#Error pages
error_page 503 @503;

location @503 {
# Serve static assets if found.
if (-f $request_filename) {
break;
}

# Set root to the shared directory.
root /var/www/quotr-public/system;
rewrite ^(.*)$ /maintenance.html break;
}
}


#6

Hi @xxchester

looks like you have a lot of double-definitions of your vHosts.

One domain name www.spottingquotes.ca should only have one vHost.

So remove all double-entries.


#7

Hmm interesting, when I comment out the server_name line in the port 80 section it removes the warnings and I am able to renew.

That being said, my understanding was you need a server_name line in each server declaration. Currently my http declaration looks like this:

server {
listen 80 default_server;
listen [::]:80 default_server;
#server_name $HOSTNAME spottingquotes.ca www.SpottingQuotes.ca;

#Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://www.$server_name$request_uri;
}


#8

Happy to read that your renew has worked.

If you have more then one server block with the same server_name, Certbot doesn’t know which definition is used.

The idea of vHosts is simple: Different domains with different configurations one one server. But then every domain name should only be used one time.


#9

Bah, this has of course broken the http redirect to https. So yay I can certbot renew but cannot redirect now.


#10

There is your redirect.

Add this line to your other vHost with the correct domain name.


#11

Sorry I should’ve mentioned I changed that line to this:

return 301 https://www.SpottingQuotes.ca$request_uri;

My server block now looks like this:

server {
listen 80 default_server;
listen [::]:80 default_server;
#server_name $HOSTNAME spottingquotes.ca www.SpottingQuotes.ca;

#Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://www.SpottingQuotes.ca$request_uri;
}


closed #12

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