Cerbot 0.28 still using SNI


#1

I recently updated certbot to 0.28.0 on a server running Ubuntu 14.04. When reissuing a certificate I noticed that it still uses SNI challenge for installation. The output went something like this:

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
Created an SSL vhost at /etc/apache2/sites-available/example.com-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/example.com-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/example.com-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/example.com-le-ssl.conf

Doing certbot renew --dry-run does in fact use the correct http-01 challenge, it’s only the initial deploy that seems to be stuck on SNI.


#2

That might not be enough to remedy the tls-sni-01 situation, as you have experienced yourself now.

What is the exact command you’ve ran? What is the contents of /etc/letsencrypt/cli.ini?


#3

According to this page: How to stop using TLS-SNI-01 with Certbot it should be:

If the dry run succeeds, and your Certbot version is 0.28 or higher, you’re good to go! No further action should be required to deal with the end of TLS-SNI-01 support.

Exact command was certbot --apache, selected a couple of domains and reissued the certificate as I’ve always done. This is a default install, nothing has been customized or altered — cli.ini is default:

# Because we are using logrotate for greater flexibility, disable the
# internal certbot logrotation.
max-log-backups = 0

#4

Can you confirm the version with certbot --version?


#5

Yes, see the first sentence of my original post. 0.28.0


#6

I’m not sure why you’re seeing Certbot 0.28 continue to use TLS-SNI-01, but the --dry-run success is a good sign because it indicates that your Certbot can successfully switch to HTTP-01 when TLS-SNI-01 is no longer available. This most likely means that your system can handle the upcoming change without incident.


#7

Thanks - guess we’ll find out! Are you aware of anything with my Apache config or elsewhere that might be triggering it to behave this way for deployment but not renewal?


#8

Some users actually updated some package of their OS, but were still running out-dated versions from some obscure directory, thats why I asked.

Also, it might be your Apache package isn’t 0.28.0, but an older version.


#9

Interesting — how can I check the Apache package version? I wasn’t aware that this could get out of sync. certbot was installed/updated per documentation with: apt-get install certbot python-certbot-apache so I’d assume that everything should be latest version.


#10

Checking the PPA it seems the apache and nginx plugins are up to date with 0.28. It were the DNS plugins which were lagging behind on version numbers.


#11

The log that shows this:

Should also show the version used (in that same log file).

[you might have multiple versions installed]


#12

Thanks @rg305 - I’d be happy to share the relevant parts of the log file — is there a way to do so privately? I don’t want to disclose the domain or server details on this public forum.


#13

Just the lines that show the version(s) will do.

You might want to verify which certbot is executed in the daily job(s) and if the are multiple certbots:
which certbot
find -name certbot
crontab -l
sudo crontab -l
systemctl list-timers | grep cert


#14

There’s only one cerbot and yes it’s running it’s corn that’s not an issue (though you should note that the cron process in this installation is triggered by /etc/cron.d/certbot not in the crontab).

Log confirms correct version:

2019-02-27 10:31:51,482:DEBUG:certbot.main:certbot version: 0.28.0

However this is curious:

2019-02-27 10:32:08,842:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/acme/authz/ka1JxQn968Pxul8wzlWWM0-Nw9XaHb09HXXJm5OIXyM.
2019-02-27 10:32:08,910:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "GET /acme/authz/ka1JxQn968Pxul8wzlWWM0-Nw9XaHb09HXXJm5OIXyM HTTP/1.1" 200 1478
2019-02-27 10:32:08,911:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Content-Type: application/json
Content-Length: 1478
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Expires: Wed, 27 Feb 2019 15:32:08 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Wed, 27 Feb 2019 15:32:08 GMT
Connection: keep-alive

{
  "identifier": {
    "type": "dns",
    "value": "www.example.com"
  },
  "status": "valid",
  "expires": "2019-03-29T15:29:11Z",
  "challenges": [
    {
      "type": "tls-sni-01",
      "status": "valid",
      "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/ka1JxQn968Pxul8wzlWWM0-Nw9XaHb09HXXJm5OIXyM/13049505119",
      "token": "-lLhsibP0Mt7UhfyMSXN9PgkkvO6soiocsithbwXQK8",
      "validationRecord": [
        {
          "hostname": "www.example.com",
          "port": "443",
          "addressesResolved": [
            "XXX.XXX.XXX.XXX",
            "XXXX:XXXX::XXXX:XXXX:XXXX:XXXX"
          ],
          "addressUsed": "XXXX:XXXX::XXXX:XXXX:XXXX:XXXX"
        }
      ]
    },
    {
      "type": "dns-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/ka1JxQn968Pxul8wzlWWM0-Nw9XaHb09HXXJm5OIXyM/13049505123",
      "token": "nztFiAIOy-ApfMDEyRpDqPGL6HKSHq_QJIYrRd2YbN0"
    },
    {
      "type": "tls-alpn-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/ka1JxQn968Pxul8wzlWWM0-Nw9XaHb09HXXJm5OIXyM/13049505126",
      "token": "uxjdzoQSsj_q5kk0IfbIyJGPFsTtWJ1uT_UNawn4vV0"
    },
    {
      "type": "http-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/ka1JxQn968Pxul8wzlWWM0-Nw9XaHb09HXXJm5OIXyM/13049505129",
      "token": "9h6mRvXze7Tnk3IPrIgzH0CPl-qZueqhWg8xXPGaiMk"
    }
  ]
}
2019-02-27 10:32:08,913:INFO:certbot.auth_handler:Performing the following challenges:
2019-02-27 10:32:08,913:INFO:certbot.auth_handler:tls-sni-01 challenge for example.com
2019-02-27 10:32:08,914:INFO:certbot.auth_handler:tls-sni-01 challenge for www.example.com
2019-02-27 10:32:08,914:WARNING:certbot.auth_handler:TLS-SNI-01 is deprecated, and will stop working soon.

Looks as though the api connection to https://acme-v02.api.letsencrypt.org prioritizes the SNI challenge and the status is “valid” whereas the http-01 challenge is “pending”. I’m not really sure about the logic here or if the order of the challenges returned is significant. Perhaps one of the devs can comment.


#15

Hi @billynoah

there is no prioritization. The challenge which is used is valide, the other are pending.

If you create a new order, all challenges are pending. If I use http-01 validation, then the http-01 validation is “valid”, the other challenges are pending.


#16

Ok so what exactly determines which one is used then? In this case it is a new order. Can you explain why it’s using SNI validation instead of HTTP?


#17

Did you use --preferred-challenges http? If not, the challenge in your config file is used.

So change your config with adding --preferred-challenges http.


#18

No I did not use any arguments at all. I’ve done the same certificate request on other machines though and they all seem to use HTTP so I can’t understand why it would be needed in this case as I haven’t done anything in particular to the config file.

Can you please be specific about which config file and where I should look? I’ve scoured /etc/letsencrypt and found nothing obviously related to a challenge. I don’t see why I should have to add any special argument here since I haven’t done that on other servers and they all default to HTTP.


#19

Check

/etc/letsencrypt/renewal

if there is a file.


#20

Yes there is a file there but contains nothing pertaining to challenges:

# Options used in the renewal process
[renewalparams]
server = https://acme-v02.api.letsencrypt.org/directory
account = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
installer = apache
authenticator = apache

At any rate, why would the renewal config be related to reissuing or issuing a new certificate? That doesn’t really make sense.