Renew certificates throws unauthorized, new certificates work

Hi there,

I have a problem renewing my letsencrypt certificates using certbot renew.
All certificate renewals fail with an unauthorized status, but new certificate creations work with apparently the same config.
I have searched through the web and the community, but couldn’t find any solution proposal that solved my issue :o(
I tried uploading my log files of an successful new creation and the failing renewal, but the form won’t let me :frowning:
I hope I’ll be able to attach the files after creating the topic…

My domain is:
sys0000.dev.ergo.liferunoffinsuranceplatform.com

I ran this command:
certbot renew --deploy-hook /opt/certbot-deploy-hook.sh

It produced this output:
Domain: sys0000.dev.ergo.liferunoffinsuranceplatform.com
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge. Requested .acme.invalid from 158.177.138.117:443. Received 2 certificate(s), first certificate had names “sys0000.dev.ergo.liferunoffinsuranceplatform.com

My web server is (include version):
HA-Proxy version 1.5.18

The operating system my web server runs on is (include version):
CentOS 7.0

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

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no

Okay it won’t let me upload files, so here’s the log of the failing renewal:
2018-10-04 12:24:55,218:INFO:certbot.auth_handler:tls-sni-01 challenge for sys0000.dev.ergo.liferunoffinsuranceplatform.com
2018-10-04 12:24:55,218:DEBUG:acme.standalone:Successfully bound to :8888 using IPv6
2018-10-04 12:24:55,218:DEBUG:acme.standalone:Certbot wasn’t able to bind to :8888 using IPv4, this is often expected due to the dual stack nature of IPv6 socket implementations.
2018-10-04 12:24:55,226:INFO:certbot.auth_handler:Waiting for verification…
2018-10-04 12:24:55,226:DEBUG:acme.client:JWS payload:
{
“keyAuthorization”: “”,
“type”: “tls-sni-01”,
“resource”: “challenge”
}
2018-10-04 12:24:55,229:DEBUG:acme.client:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/challenge/:
{
“protected”: “”,
“payload”: “”,
“signature”: “”
}
2018-10-04 12:24:55,454:DEBUG:requests.packages.urllib3.connectionpool:“POST /acme/challenge/ HTTP/1.1” 202 339
2018-10-04 12:24:55,454:DEBUG:acme.client:Received response:
HTTP 202
content-length: 339
cache-control: max-age=0, no-cache, no-store
expires: Thu, 04 Oct 2018 10:24:30 GMT
server: nginx
connection: keep-alive
link: <https://acme-v01.api.letsencrypt.org/acme/authz/;rel=“up”
location: https://acme-v01.api.letsencrypt.org/acme/challenge/
pragma: no-cache
boulder-requester: 37693435
date: Thu, 04 Oct 2018 10:24:30 GMT
content-type: application/json
replay-nonce:

{
“type”: “tls-sni-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/”,
“token”: “”,
“keyAuthorization”: “”
}
2018-10-04 12:24:55,454:DEBUG:acme.client:Storing nonce:
2018-10-04 12:24:58,455:DEBUG:acme.client:Sending GET request to https://acme-v01.api.letsencrypt.org/acme/authz/.
2018-10-04 12:24:58,622:DEBUG:requests.packages.urllib3.connectionpool:“GET /acme/authz/ HTTP/1.1” 200 1973
2018-10-04 12:24:58,622:DEBUG:acme.client:Received response:
HTTP 200
content-length: 1973
expires: Thu, 04 Oct 2018 10:24:33 GMT
strict-transport-security: max-age=604800
server: nginx
connection: keep-alive
link: https://acme-v01.api.letsencrypt.org/acme/new-cert;rel=“next”
pragma: no-cache
cache-control: max-age=0, no-cache, no-store
date: Thu, 04 Oct 2018 10:24:33 GMT
x-frame-options: DENY
content-type: application/json
replay-nonce:

{
“identifier”: {
“type”: “dns”,
“value”: “sys0000.dev.ergo.liferunoffinsuranceplatform.com
},
“status”: “invalid”,
“expires”: “2018-10-11T10:24:30Z”,
“challenges”: [
{
“type”: “tls-alpn-01”,
“status”: “invalid”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge//7937432653”,
“token”: “”
},
{
“type”: “dns-01”,
“status”: “invalid”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge//7937432654”,
“token”: “”
},
{
“type”: “http-01”,
“status”: “invalid”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge//7937432655”,
“token”: “DZd5-laUB4qbXqG-”
},
{
“type”: “tls-sni-01”,
“status”: “invalid”,
“error”: {
“type”: “urn:acme:error:unauthorized”,
“detail”: “Incorrect validation certificate for tls-sni-01 challenge. Requested .acme.invalid from 158.177.138.117:443. Received 2 certificate(s), first certificate had names “sys0000.dev.ergo.liferunoffinsuranceplatform.com””,
“status”: 403
},
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/”,
“token”: “”,
“validationRecord”: [
{
“hostname”: “sys0000.dev.ergo.liferunoffinsuranceplatform.com”,
“port”: “443”,
“addressesResolved”: [
“158.177.138.117”
],
“addressUsed”: “158.177.138.117”
}
]
}
],
“combinations”: [
[
0
],
[
1
],
[
3
],
[
2
]
]
}
2018-10-04 12:24:58,623:DEBUG:acme.challenges:tls-alpn-01 was not recognized, full message: {u’status’: u’invalid’, u’token’: u’’, u’type’: u’tls-alpn-01’, u’uri’: u’https://acme-v01.api.letsencrypt.org/acme/challenge//7937432653’}
2018-10-04 12:24:58,624:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: sys0000.dev.ergo.liferunoffinsuranceplatform.com
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge. Requested .acme.invalid from 158.177.138.117:443. Received 2 certificate(s), first certificate had names “sys0000.dev.ergo.liferunoffinsuranceplatform.com

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.
2018-10-04 12:24:58,624:DEBUG:certbot.error_handler:Encountered exception:
Traceback (most recent call last):
File “/usr/lib/python2.7/site-packages/certbot/auth_handler.py”, line 82, in handle_authorizations
self._respond(aauthzrs, resp, best_effort)
File “/usr/lib/python2.7/site-packages/certbot/auth_handler.py”, line 155, in _respond
self._poll_challenges(aauthzrs, chall_update, best_effort)
File “/usr/lib/python2.7/site-packages/certbot/auth_handler.py”, line 226, in _poll_challenges
raise errors.FailedChallenges(all_failed_achalls)
FailedChallenges: Failed authorization procedure. sys0000.dev.ergo.liferunoffinsuranceplatform.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested .acme.invalid from 158.177.138.117:443. Received 2 certificate(s), first certificate had names “sys0000.dev.ergo.liferunoffinsuranceplatform.com

2018-10-04 12:24:58,624:DEBUG:certbot.error_handler:Calling registered functions
2018-10-04 12:24:58,625:INFO:certbot.auth_handler:Cleaning up challenges
2018-10-04 12:24:58,625:DEBUG:certbot.plugins.standalone:Stopping server at :::8888…

Here’s the renewal configuration:

renew_before_expiry = 30 days

version = 0.25.1
archive_dir = /etc/letsencrypt/archive/sys0000.dev.ergo.liferunoffinsuranceplatform.com
cert = /etc/letsencrypt/live/sys0000.dev.ergo.liferunoffinsuranceplatform.com/cert.pem
privkey = /etc/letsencrypt/live/sys0000.dev.ergo.liferunoffinsuranceplatform.com/privkey.pem
chain = /etc/letsencrypt/live/sys0000.dev.ergo.liferunoffinsuranceplatform.com/chain.pem
fullchain = /etc/letsencrypt/live/sys0000.dev.ergo.liferunoffinsuranceplatform.com/fullchain.pem

Options used in the renewal process

[renewalparams]
authenticator = standalone
installer = None
account =
http01_port = 8888
tls_sni_01_port = 8888

And here’s the log of a successful creation of a new certificate:
2018-10-04 12:22:15,572:INFO:certbot.auth_handler:http-01 challenge for sys9999.dev.ergo.liferunoffinsuranceplatform.com
2018-10-04 12:22:15,573:DEBUG:acme.standalone:Successfully bound to :8888 using IPv6
2018-10-04 12:22:15,573:DEBUG:acme.standalone:Certbot wasn’t able to bind to :8888 using IPv4, this is often expected due to the dual stack nature of IPv6 socket implementations.
2018-10-04 12:22:15,578:INFO:certbot.auth_handler:Waiting for verification…
2018-10-04 12:22:15,579:DEBUG:acme.client:JWS payload:
{
“keyAuthorization”: “”,
“type”: “http-01”,
“resource”: “challenge”
}
2018-10-04 12:22:15,582:DEBUG:acme.client:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/challenge//7937371387:
{
“protected”: “”,
“payload”: “”,
“signature”: “”
}
2018-10-04 12:22:15,781:DEBUG:requests.packages.urllib3.connectionpool:“POST /acme/challenge//7937371387 HTTP/1.1” 202 336
2018-10-04 12:22:15,781:DEBUG:acme.client:Received response:
HTTP 202
content-length: 336
cache-control: max-age=0, no-cache, no-store
expires: Thu, 04 Oct 2018 10:21:51 GMT
server: nginx
connection: keep-alive
link: <https://acme-v01.api.letsencrypt.org/acme/authz/>;rel=“up”
location: https://acme-v01.api.letsencrypt.org/acme/challenge//7937371387
pragma: no-cache
boulder-requester: 37693435
date: Thu, 04 Oct 2018 10:21:51 GMT
content-type: application/json
replay-nonce:

{
“type”: “http-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/”,
“token”: “”,
“keyAuthorization”: “”
}
2018-10-04 12:22:15,781:DEBUG:acme.client:Storing nonce:
2018-10-04 12:22:15,998:DEBUG:acme.standalone:::ffff:127.0.0.1 - - Incoming request
2018-10-04 12:22:15,998:DEBUG:acme.standalone:::ffff:127.0.0.1 - - Serving HTTP01 with token u’’
2018-10-04 12:22:15,999:DEBUG:acme.standalone:::ffff:127.0.0.1 - - “GET /.well-known/acme-challenge/ HTTP/1.1” 200 -
2018-10-04 12:22:18,785:DEBUG:acme.client:Sending GET request to https://acme-v01.api.letsencrypt.org/acme/authz/.
2018-10-04 12:22:18,951:DEBUG:requests.packages.urllib3.connectionpool:“GET /acme/authz/+ HTTP/1.1” 200 1444
2018-10-04 12:22:18,951:DEBUG:acme.client:Received response:
HTTP 200
content-length: 1444
expires: Thu, 04 Oct 2018 10:21:54 GMT
strict-transport-security: max-age=604800
server: nginx
connection: keep-alive
link: https://acme-v01.api.letsencrypt.org/acme/new-cert;rel=“next”
pragma: no-cache
cache-control: max-age=0, no-cache, no-store
date: Thu, 04 Oct 2018 10:21:54 GMT
x-frame-options: DENY
content-type: application/json
replay-nonce:

{
“identifier”: {
“type”: “dns”,
“value”: “sys9999.dev.ergo.liferunoffinsuranceplatform.com
},
“status”: “valid”,
“expires”: “2018-11-03T10:21:51Z”,
“challenges”: [
{
“type”: “tls-alpn-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge//7937371385”,
“token”: “”
},
{
“type”: “http-01”,
“status”: “valid”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge//7937371387”,
“token”: “”,
“validationRecord”: [
{
“url”: “http://sys9999.dev.ergo.liferunoffinsuranceplatform.com/.well-known/acme-challenge/”,
“hostname”: “sys9999.dev.ergo.liferunoffinsuranceplatform.com”,
“port”: “80”,
“addressesResolved”: [
“158.177.138.117”
],
“addressUsed”: “158.177.138.117”
}
]
},
{
“type”: “dns-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge//7937371388”,
“token”: “”
}
],
“combinations”: [
[
1
],
[
0
],
[
2
]
]
}
2018-10-04 12:22:18,952:DEBUG:acme.challenges:tls-alpn-01 was not recognized, full message: {u’status’: u’pending’, u’token’: u’’, u’type’: u’tls-alpn-01’, u’uri’: u’https://acme-v01.api.letsencrypt.org/acme/challenge//7937371385’}
2018-10-04 12:22:18,952:DEBUG:certbot.error_handler:Calling registered functions
2018-10-04 12:22:18,952:INFO:certbot.auth_handler:Cleaning up challenges
2018-10-04 12:22:18,953:DEBUG:certbot.plugins.standalone:Stopping server at :::8888…

Hi @nico-rogasch

the tls-sni-01 - challenge is deprecated. So switch to http-01 - challenge.

Use something like

certbot renew --preferred-challenges http ...

If you want to renew more then one certificate, perhaps try to renew only one certificate.

Hi Juergen,
thank you very much, that worked.
Didn’t realize that tls-sni is deprecated and wondering why the new issuance of certificates is working though?

Thanks again!

1 Like

Happy to read that :wink:

The new certificate used http-01 - validation. That worked.

1 Like

(The distinction comes about because renewals of existing certificates, under a certain renewal-detection algorithm, are still allowed to use TLS-SNI-01 and Certbot prefers it to HTTP-01 by default if it’s allowed to use it. The CA sends a list of allowed challenge methods in response to every certificate request.)

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