Cerbot 0.28 still using SNI

Help
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.

1 Like
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.