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

djaychela · January 29, 2019, 1:21pm

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

JuergenAuer · January 29, 2019, 2:35pm

Hi @djaychela

you are using letsencrypt. Use

sudo certbot renew --preferred-challenges http

instead.

djaychela · January 29, 2019, 3:05pm

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.

rg305 · January 29, 2019, 5:43pm

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]

djaychela · January 29, 2019, 7:21pm

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

rg305 · January 29, 2019, 7:24pm

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]

djaychela · January 29, 2019, 8:34pm

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

rg305 · January 29, 2019, 8:43pm

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

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

bmw · January 30, 2019, 12:32am

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:

What are the contents of /etc/letsencrypt/cli.ini?
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.

allella · January 30, 2019, 1:18am

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.

bmw · January 30, 2019, 1:43am

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

allella · January 30, 2019, 2:02am

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

djaychela · January 30, 2019, 8:56am

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.

bmw · January 30, 2019, 6:42pm

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

What are the contents of /etc/letsencrypt/cli.ini ?

If you’re on a Debian based system (such as Ubuntu), what is the output of sudo dpkg -l *certbot* ?

rg305 · January 31, 2019, 12:32am

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…]

allella · January 31, 2019, 2:57am

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.

system · March 2, 2019, 2:57am

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