Force HTTP-01, old cert

I’ve used LetsEncrypt for my domain which was behind a firewall. So I’ve used --preferred-challenges dns to validate the domain. Command;

certbot -d mysite.nl -d mysite.suffix.nl --manual --preferred-challenges dns certonly

The server has been re-located, and is now accessible from the public internet. To ensure automatic renew would work as expected. I wish to set preferred-challenges to HTTP-01.

I deleted the cert with certbot --delete, waited for 3 days, and re-created the cert with;

certbot --nginx --preferred-challenges http certonly -d mysite.nl -d mysite.suffix.nl -v

Unfortunately Certbot fails on the first domain, I guess the preferred challenge type is somehow cached, referring to the -v debug payload;

...
Received response:
HTTP 200
Server: nginx
Date: Mon, 03 Feb 2020 15:12:16 GMT
Content-Type: application/json
Content-Length: 795
Connection: keep-alive
Boulder-Requester: 64374842
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: 0102Y_7zUvaV_80imqneUGAKUGKAFASDAkY78Twpt5BcmcrwoA
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "identifier": {
    "type": "dns",
    "value": "mysite.nl"
  },
  "status": "pending",
  "expires": "2020-02-07T16:41:20Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/2571911750/3WoMZA",
      "token": "hgaABCc_GEXNQ0jwOXpGUFAKLJJFXFXi6Zj9b4jon-KQ"
    },
    {
      "type": "dns-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/2571911750/AOLM6Q",
      "token": "hgaABCc_GEXNQ0jwOXpGUFAKLJJFXFXi6Zj9b4jon-KQ"
    },
    {
      "type": "tls-alpn-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/2571911750/7492Qw",
      "token": "hgaABCc_GEXNQ0jwOXpGUFAKLJJFXFXi6Zj9b4jon-KQ"
    }
  ]
}
Storing nonce: 0102Y_7zUvaV_80imqAGSDFSTF0VkY78Twpt5BcmcrwoA
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

How do I proper set the new http-01 challenge type?

Edit;

$ certbot --version
certbot 0.28.0
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
1 Like

Not sure why that did not work… Perhaps http may need to be http-01 instead.
From: https://certbot.eff.org/docs/using.html
“The options are http-01 (which uses port 80) and dns-01 (requiring configuration of a DNS server on port 53, though that’s often not the same machine as your webserver).”

In the meantime, can we have a look at the related renewal.conf file(s) at:
/etc/letsencrypt/renewal/

1 Like

Hi!
Thanks for the reply!

I’ve tried both http and http-01, unfortunately no difference.

The file in /etc/letsencrypt/renewal has been removed after using certbot delete on the domain.
Only other certs are listed here

Thx!

Which version of certbot are you running?
[newer versions will default to HTTP]

1 Like

I’m using certbot 0.28.0 on Debian GNU/Linux 9 (stretch)

There was another thread about this issue posted earlier today:

(It’s remarkably coincidental timing, since the API change that probably exposed this issue was made a month ago.)

It seems to have been inadvertently fixed by changes made in Certbot 0.31.0 – which does not really help you much, of course.

Edit:

The nginx plugin will always use HTTP-01 validation (currently). You don’t need --preferred-challenges since it only supports one challenge type anyway.

2 Likes

Hi! Thanks!

So upgrading to Certbot 0.31.0 should solve this issue?

Solution posted in linked issue did not solve the issue, same results

I think what you should do is just remove the --preferred-challenges flag from your command for now. It will allow you to renew your certificate.

1 Like

What is shown by:
sudo yum check-update
sudo apt update
sudo apt list --upgradeable

Both apt update & apt list --upgradeable show nothing. System is up to date using

deb http://deb.debian.org/debian/ stretch main

from /etc/apt/source.list

Read online that Debian 9 Stretch always uses Certbot 0.28.0.

Should installing Certbot-Auto help solve the issue?

1 Like

Worth a try…

1 Like

Yep, I’ve installed Certbot-Auto;

$ certbot-auto --version
certbot 1.1.0

Successfully created the certs with;

/tmp/certbot-auto --nginx certonly -d mysite.nl -d mysite.suffix.nl -v

Even tho this fixed the issue, I would like to know a workaround for Certbot 0.28.0. (If someone finds it :wink: )

Thanks for the help!

2 Likes

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