Certificate Renewal fails

Doc · July 28, 2021, 9:22pm

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: bwrs.cdaytech.co.uk

I ran this command: docker compose, shown below

It produced this output:

Cert is due for renewal, auto-renewing...
certbot_1 | Non-interactive renewal: random delay of 57.120881546758554 seconds
certbot_1 | Plugins selected: Authenticator webroot, Installer None
certbot_1 | Renewing an existing certificate for bwrs.cdaytech.co.uk
certbot_1 | Performing the following challenges:
certbot_1 | http-01 challenge for bwrs.cdaytech.co.uk
certbot_1 | Using the webroot path /var/www/certbot for all unmatched domains.
certbot_1 | Waiting for verification...
certbot_1 | Challenge failed for domain bwrs.cdaytech.co.uk
certbot_1 | http-01 challenge for bwrs.cdaytech.co.uk
certbot_1 | Cleaning up challenges
certbot_1 | Failed to renew certificate bwrs.cdaytech.co.uk with error: Some challenges have failed.
certbot_1 |
certbot_1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
certbot_1 | All renewals failed. The following certificates could not be renewed:
certbot_1 | /etc/letsencrypt/live/bwrs.cdaytech.co.uk/fullchain.pem (failure)
certbot_1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
certbot_1 | 1 renew failure(s), 0 parse failure(s)
certbot_1 | IMPORTANT NOTES:
certbot_1 | - The following errors were reported by the server:
certbot_1 |
certbot_1 | Domain: bwrs.cdaytech.co.uk
certbot_1 | Type: unauthorized
certbot_1 | Detail: Invalid response from
certbot_1 | https://bwrs.cdaytech.co.uk/.well-known/acme-challenge/tDli8qVGj0sEjyTDt87O1rGXfhvmbBywZrz6gSHA8Go
certbot_1 | [2606:4700:3030::ac43:a9bd]: "\n \n
certbot_1 | <html lang="en">\n \n <meta
certbot_1 | charset="utf-8">\n "
certbot_1 |
certbot_1 | To fix these errors, please make sure that your domain name was
certbot_1 | entered correctly and the DNS A/AAAA record(s) for that domain
certbot_1 | contain(s) the right IP address.

My web server is (include version): nginx

The operating system my web server runs on is (include version): docker, on ubunut 20.04

My hosting provider, if applicable, is:

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): docker certbot/certbot

Docker-compose:
certbot:
image: certbot/certbot
restart: always
volumes:

./data/certbot/conf:/etc/letsencrypt
./data/certbot/www:/var/www/certbot
entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

nginx.conf:

events {}

http{
  server {
    listen 80;
    server_name bwrs.cdaytech.co.uk;

    location / {
      return 301 https://$host$request_uri;
    }
    location /.well-known/acme-challenge/ {
      root /var/www/certbot;
    }
  }

  server {
    listen 443 ssl;
    server_name bwrs.cdaytech.co.uk;

    ssl_certificate /etc/letsencrypt/live/bwrs.cdaytech.co.uk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/bwrs.cdaytech.co.uk/privkey.pem;

    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    include /etc/nginx/cloudflare;

    location / {
        proxy_pass http://bitwarden;
        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;
    }
    location /admin {
        proxy_pass http://bitwarden/admin;
        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;
        auth_basic           "Administrator Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
   }
  }
}

rg305 · July 28, 2021, 9:36pm

Hi @Doc, and welcome to the LE community forum

I suspect that order matters:

Where everything is being redirected before it can be matched to the challenge path.

Doc · July 29, 2021, 10:11am

Hi @rg305, and thanks for your help. Unfortunately swapping the order doesn't allow it to renew the certificate either. As the current certificate is no longer valid, I have attempted to run the script below, but receive the same error message.

script:

#!/bin/bash

if ! [ -x "$(command -v docker-compose)" ]; then
echo 'Error: docker-compose is not installed.' >&2
exit 1
fi

domains=(bwrs.cdaytech.co.uk)
rsa_key_size=4096
data_path="./data/certbot"
email="admin@cdaytech.co.uk" # Adding a valid address is strongly recommended
staging=1 # Set to 1 if you're testing your setup to avoid hitting request limits

if [ -d "$data_path" ]; then
read -p "Existing data found for $domains. Continue and replace existing certificate? (y/N) " decision
if [ "$decision" != "Y" ] && [ "$decision" != "y" ]; then
exit
fi
fi

if [ ! -e "$data_path/conf/options-ssl-nginx.conf" ] || [ ! -e "$data_path/conf/ssl-dhparams.pem" ]; then
echo "### Downloading recommended TLS parameters ..."
mkdir -p "$data_path/conf"
curl -s https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf > "$data_path/conf/options-ssl-nginx.conf"
curl -s https://raw.githubusercontent.com/certbot/certbot/master/certbot/certbot/ssl-dhparams.pem > "$data_path/conf/ssl-dhparams.pem"
echo
fi

echo "### Creating dummy certificate for $domains ..."
path="/etc/letsencrypt/live/$domains"
mkdir -p "$data_path/conf/live/$domains"
docker-compose run --rm --entrypoint "
openssl req -x509 -nodes -newkey rsa:$rsa_key_size -days 1
-keyout '$path/privkey.pem'
-out '$path/fullchain.pem'
-subj '/CN=localhost'" certbot
echo

echo "### Starting nginx ..."
docker-compose up --force-recreate -d nginx
echo

echo "### Deleting dummy certificate for $domains ..."
docker-compose run --rm --entrypoint "
rm -Rf /etc/letsencrypt/live/$domains &&
rm -Rf /etc/letsencrypt/archive/$domains &&
rm -Rf /etc/letsencrypt/renewal/$domains.conf" certbot
echo

echo "### Requesting Let's Encrypt certificate for $domains ..."
#Join $domains to -d args
domain_args=""
for domain in "${domains[@]}"; do
domain_args="$domain_args -d $domain"
done

Select appropriate email arg

case "$email" in
"") email_arg="--register-unsafely-without-email" ;;
*) email_arg="--email $email" ;;
esac

Enable staging mode if needed

if [ $staging != "0" ]; then staging_arg="--staging"; fi

docker-compose run --rm --entrypoint "
certbot certonly --webroot -w /var/www/certbot
$staging_arg
$email_arg
$domain_args
--rsa-key-size $rsa_key_size
--agree-tos
--force-renewal" certbot
echo

echo "### Reloading nginx ..."
docker-compose exec nginx nginx -s reload

rg305 · July 29, 2021, 1:40pm

Did you run that in staging?

That has got to be the worst production code ever used here.
It seems to delete existing certs without even checking their validity.
And it doesn't even use the built-in certbot delete parameter.
Very pre-alpha / very early in the development code cycle (not production ready).

Doc · July 29, 2021, 1:54pm

It was run in staging to test, but error is present with staging set to 0. The deleted certs are temporary certs to allow nginx to start for the first time without a valid cert, and would normally only be used to generate the first cert so no need to test for validity. After that, update would be handled by certbot using the docker-compose file from the first post.

rg305 · July 29, 2021, 2:08pm

OK, so begin at the beginning...

hmm...
Do you realize that your site is behind Cloudflare IPs?

Name:      bwrs.cdaytech.co.uk
Addresses: 2606:4700:3030::ac43:a9bd
           2606:4700:3032::6815:1bcb
           172.67.169.189
           104.21.27.203

And as such, HTTP requests will never reach your actual site (via HTTP); as they will all be redirected to HTTPS (by Cloudflare) first.
As well as other CF consideration(s) needed to enable you to get a cert when behind them.
[I don't use CF, so I can't speak with much detail here]

rg305 · July 29, 2021, 2:13pm

So start by adding HTTPS challenge file request consideration (as was done in the HTTP server block):

Doc:

  server {
    listen 443 ssl;
    server_name bwrs.cdaytech.co.uk;

    ssl_certificate /etc/letsencrypt/live/bwrs.cdaytech.co.uk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/bwrs.cdaytech.co.uk/privkey.pem;

    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    include /etc/nginx/cloudflare;

    location / {
        proxy_pass http://bitwarden;
        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;
    }
    location /admin {
        proxy_pass http://bitwarden/admin;
        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;
        auth_basic           "Administrator Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
   }
  }

Doc · July 29, 2021, 2:48pm

Of Course! I completely missed that it was looking for the response on https. Made that change and it all seems good now.

Thanks for your help.

rg305 · July 29, 2021, 2:50pm

Glad to have helped

Cheers form Miami

#FreeCuba

system · August 28, 2021, 2:50pm

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