TLS-SNI-01 to HTTP-01 change doesn't appear to be complete


#1

I’ve just followed the instructions to update certbot (https://certbot.eff.org/lets-encrypt/ubuntubionic-other), and it seems to work successfully on my Ubuntu 18.04 LTS system I have at home. However, when I update the certificate, I get a warning; tls-sni-01 challenge for djaychela.ddns.net TLS-SNI-01 is deprecated, and will stop working soon. - I was expecting this to no longer be the case after running

sudo sh -c "sed -i.bak -e 's/^\(pref_challs.*\)tls-sni-01\(.*\)/\1http-01\2/g' /etc/letsencrypt/renewal/*; rm -f /etc/letsencrypt/renewal/*.bak"

which was given in ’ How to stop using TLS-SNI-01 with Certbot

I can’t find any references in my config files under /etc/letsencrypt/renewal which contains one .conf file with the following in:

[renewalparams]
installer = apache
authenticator = apache
account = 3XXXXXX (removed in case this is private)
apache_vhost_root = /etc/apache2/sites-available
server = https://acme-v02.api.letsencrypt.org/directory

I’m therefore don’t think I’ve managed to change from TLS-SNI-01 to HTTP-01. Can someone please point me in the right direction in terms of where I should be looking for the configuration option that is controlling this?

My domain is: djaychela.ddns.net

I ran this command: sudo letsencrypt renew --force-renewal

It produced this output: Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for djaychela.ddns.net
TLS-SNI-01 is deprecated, and will stop working soon.
Waiting for verification…
Cleaning up challenges

My web server is (include version): Apache/2.4.18 (Ubuntu)

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

My hosting provider, if applicable, is: N/A (home hosted)

I can login to a root shell on my machine (yes or no, or I don’t know): yes

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


#2

Hi @djaychela

you are using letsencrypt. Use

sudo certbot renew --preferred-challenges http

instead.


#3

Thanks very much Juergen - works perfectly, and I’ve updated by crontab to suit.

FTR I did try certbot renew, but didn’t put --preferred-challenges http on, so hopefully that will help anyone else who has a similar issue.


#4

This won’t be necessary.
That would set that in stone; and someday (in the future) that may need to change and can’t.
[let cerbot automatically update the right settings in the renewal.conf file]


#5

I meant I’ve updated my crontab to use certbot, rather than baking in the options given.


#6

Please show:
systemctl list-timers --all | grep certbot

as well as:
sudo crontab -l |grep certbot

[or for whichever user the cron job runs as]


#7

Hi.

systemctl list-timers --all | grep certbot
gives
Wed 2019-01-30 08:31:35 GMT 12h left Tue 2019-01-29 15:15:35 GMT 5h 13min ago certbot.timer certbot.service

sudo crontab -l |grep certbot
gives
30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log


#8

So you now have two jobs (doing the same thing).

Show:
grep ExecStart /lib/systemd/system/certbot.service


#9

These instructions work just fine because you’re specifying a preference for HTTP-01, overriding any preferences Certbot has, but I think something else is going on here.

In the Certbot package in both Ubuntu 18.04’s official repos and the Certbot PPA, letsencrypt is a symlink to certbot so changing the name shouldn’t affect Certbot’s behavior. (Although the project was renamed almost 3 years ago so it’s probably good to use the updated name.)

None of Certbot’s plugins that are version 0.28.0 or greater prefer TLS-SNI-01 over HTTP-01 so if you’re seeing a message about TLS-SNI-01 being used and it’s deprecation, you either haven’t fully upgraded, you still have a preference for TLS-SNI-01 specified somewhere, or you’ve found a bug.

If anyone can still reproduce this problem (possibly by deleting any lines that look like pref_challs = http-01, in their renewal configuration files at /etc/letsencrypt/renewal), I’d love to know:

  1. What are the contents of /etc/letsencrypt/cli.ini?
  2. If you’re on a Debian based system (such as Ubuntu), what is the output of sudo dpkg -l *certbot*?

If neither of those commands hint at a preference for TLS-SNI-01 or an old version of Certbot or its plugins, I’d love to see a full log file showing the issue. These are stored in /var/log/letsencrypt by default. Feel free to redact any domains, emails, and IP addresses as you feel is appropriate.


#10

I’ve already upgraded using the

sudo certbot renew --preferred-challenges http

so it may be hard to recreate the issue, but here is a cleaned up shell output.

I had two systems, both with CentOS 7.6 running Apache 2.4.6 and they were on certbot 0.22.

  • After a yum upgrade certbot it updated to 0.29.1.
  • Running a --dry-run showed a http-01 challenge.
  • Running a renewal (using --force-renew because the cert wasn’t due for renewal) yielded

tls-sni-01 challenge for www.example.com
TLS-SNI-01 is deprecated, and will stop working soon.

I replaced the actual domain name with example.com in the logs below and bolded the parts I figure are relevant.

~ yum update certbot

~ certbot --version
certbot 0.29.1

~ sudo sh -c "sed -i.bak -e ‘s/^(pref_challs.)tls-sni-01(.)/\1http-01\2/g’ /etc/letsencrypt/renewal/; rm -f /etc/letsencrypt/renewal/.bak"
~ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/example.com.conf


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


new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/example.com/fullchain.pem



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

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/example.com/fullchain.pem (success)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)


~ sudo certbot renew --force-renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/example.com.conf


Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for example.com
tls-sni-01 challenge for www.example.com
TLS-SNI-01 is deprecated, and will stop working soon.
Waiting for verification…
Cleaning up challenges
Resetting dropped connection: acme-v02.api.letsencrypt.org


new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/example.com/fullchain.pem



Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/example.com/fullchain.pem (success)


~ sudo certbot renew --preferred-challenges http --force-renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/example.com.conf


Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Waiting for verification…
Cleaning up challenges
Resetting dropped connection: acme-v02.api.letsencrypt.org


new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/example.com/fullchain.pem



Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/example.com/fullchain.pem (success)


I don’t have a cli.ini but the /etc/letsencrypt/renewal/example.com.conf file now has

pref_challs = http-01,

which I assume is from the --preferred-challenges http above.

After the --preferred-challenges http a new cert was issued and active on the domain. So, that “worked” but if it’s not going to stick then I’d be interested in the correct way to fix it.


#11

@allella, what is the output of sudo rpm -qa *certbot*? Has the Apache plugin been upgraded?


#12

sudo rpm -qa certbot
python2-certbot-apache-0.29.1-1.el7.noarch
certbot-0.29.1-1.el7.noarch
python2-certbot-0.29.1-1.el7.noarch


#13

I’m slightly confused about what’s happening (the reason for my original post, in fact) - since using Juergen’s suggested command (with --preferred-challenges http), my renewals work fine. But there isn’t any pref_challs entry in the renewal .conf file:

# renew_before_expiry = 30 days
cert = /etc/letsencrypt/live/djaychela.ddns.net/cert.pem
privkey = /etc/letsencrypt/live/djaychela.ddns.net/privkey.pem
chain = /etc/letsencrypt/live/djaychela.ddns.net/chain.pem
fullchain = /etc/letsencrypt/live/djaychela.ddns.net/fullchain.pem
version = 0.28.0
archive_dir = /etc/letsencrypt/archive/djaychela.ddns.net

# Options and defaults used in the renewal process
[renewalparams]
installer = apache
authenticator = apache
account = 3cbXXXXXXXXXXXXXetc
apache_vhost_root = /etc/apache2/sites-available
server = https://acme-v02.api.letsencrypt.org/directory

I know my setup is using this conf file - renaming it causes renew to say no renewals were attempted - but is there somewhere else that the preference for http-01 is set? The upgrade instructions I followed included a line to remove any references to TLS-SNI-01 from the renewal files, but there weren’t any in there anyway.

I know it’s not the end of the world, and it appears everything is working correctly on my setup now, but I’m still confused as to how this has happened, and how the preferred-challenges http switch altered something.


#14

@allella, what you have done should have correctly fixed the problem for you. If you run sudo certbot renew --dry-run and it succeeds, you’re all set.

And certbot-apache was updated the same time that Certbot was?

If you feel like playing with it by deleting the pref_challs = http-01, line in your renewal config file, I’d be interested to see if you can still reproduce the problem, but again, if the command I wrote above succeeds, you’re all set.

Certbot rewrites these files when it actually renews your certificate. If you run sudo certbot renew --preferred-challenges http but some/all of your certificates aren’t ready for renewal, that --preferred-challenges flag has no effect.

@djaychela, can you still reproduce your original problem by running sudo certbot renew --dry-run? If so, please answer the two questions in my post above which I’ve copied here for convenience:

  1. What are the contents of /etc/letsencrypt/cli.ini ?
  2. If you’re on a Debian based system (such as Ubuntu), what is the output of sudo dpkg -l *certbot* ?

#15

The confusion is in the premise that adding --preferred-challenges http will force a change in the renewal .conf file.
Generally speaking that will happen.
But nothing will happen when used in conjunction with --dry-run.
So the --dry-run supersedes all others; and will only simulate the renewal process (but won’t change a thing).

If you really need to see the renewal .conf file updated (to sleep well at night), you can force a real renewal using HTTP:
(leaving all else the same) just replace --dry-run with --force-renewal
And sleep happily ever after…

[until global warming…]


#16

There’s been some unknowns around why I/we had a warning even after upgrading to certbot 0.29.1. Regardless, the commands below seemed to exercise the demons, so thanks to @bmw, @JuergenAuer and others for the quick work.

I never manually updated the python2-certbot-apache plugin so yum must have done so automatically since it depends on certbot.

For any future travelers, “yum” is specific to CentOS, RHEL and other RedHat variants. Certbot has a nice tool to see how to properly install it, which was my install method prior to the issue.

In summary, I was able use the advise of wiser folks here to resolve the “TLS-SNI-01 is deprecated, and will stop working soon.” emails and renewal messages from certbot for CentOS 7 and Apache 2 using the following two commands.

Your mileage may vary if you’re using Ubuntu (apt-get) or other Linux distros.


closed #17

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