Cannot renew cert: DEBUG:acme.challenges:tls-alpn-01 was not recognized

Help
1

Doing Certbot renew --dry-run I get:

Domain: xxxxx.com
Type: serverInternal
Detail: Remote PerformValidation RPCs failed

The log reveals

2018-08-01 13:07:40,917:DEBUG:acme.challenges:tls-alpn-01 was not recognized, full message: {‘type’: ‘tls-alpn-01’, ‘token’: ‘gSxydFxLDC5oFudippEjYwFezukpMJYpbB5B4IQwmvY’, ‘status’: ‘invalid’, ‘uri’: ‘https://acme-staging.api.letsencrypt.org/acme/challenge/8A_Jji9ib-2LR30VBIAmnnJMLZHVqwUpBQYhnMQODTg/155382426’}

What might be going on? I have checked DNS for the domain as I saw something similar once with bad IPv6 DNS records, but all seems fine on the DNS side …

2

This is probably because your version of Certbot is too old to understand that challenge type. But it's not a fatal error, because Certbot will just use the other available challenge types.

Regarding this error, I think it was just intermittent. If you try again right now, it should work (at least, I didn't get that error when trying with your domain: https://acme-staging-v02.api.letsencrypt.org/acme/authz/bvajsm_d2JYcDib6qrUZ3ybZtckbo3VqDyzYcpuTUp0)

3

Updating Certbot did not work

certbot --version reveals certbot 0.26.1

I am on Ubuntu Xenial and installed via ppa:certbot/certbot

I still get

Domain: xxxxx.dk
Type: serverInternal
Detail: Remote PerformValidation RPCs failed

And in the debug log

2018-08-01 13:27:37,379:DEBUG:acme.client:Sending GET request to https://acme-staging-v02.api.letsencrypt.org/acme/authz/mlLLanOSkAcUQ_Uo2T_Q6SzdZ7d7Hkhr1DPbOz9pCRM.
2018-08-01 13:27:37,565:DEBUG:urllib3.connectionpool:https://acme-staging-v02.api.letsencrypt.org:443 "GET /acme/authz/mlLLanOSkAcUQ_Uo2T_Q6SzdZ7d7Hkhr1DPbOz9pCRM HTTP/1.1" 200 2029
2018-08-01 13:27:37,566:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Content-Type: application/json
Content-Length: 2029
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Expires: Wed, 01 Aug 2018 13:27:37 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Wed, 01 Aug 2018 13:27:37 GMT
Connection: keep-alive

{
  "identifier": {
    "type": "dns",
    "value": "www.legolandresort.dk"
  },
  "status": "invalid",
  "expires": "2018-08-08T13:27:01Z",
  "challenges": [
    {
      "type": "dns-01",
      "status": "invalid",
      "url": "https://acme-staging-v02.api.letsencrypt.org/acme/challenge/mlLLanOSkAcUQ_Uo2T_Q6SzdZ7d7Hkhr1DPbOz9pCRM/155393173",
      "token": "CnFQ_bzZeLYHZ1JYpzxM0OcUr63AgT7Jp9Npdiy-V3E"
    },
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:serverInternal",
        "detail": "Remote PerformValidation RPCs failed",
        "status": 500
      },
      "url": "https://acme-staging-v02.api.letsencrypt.org/acme/challenge/mlLLanOSkAcUQ_Uo2T_Q6SzdZ7d7Hkhr1DPbOz9pCRM/155393174",
      "token": "pF-_uvXNrQODii27WMieIsLQmig5UPEOAcPLb79nZt0",
      "validationRecord": [
        {
          "url": "http://www.legolandresort.dk/.well-known/acme-challenge/pF-_uvXNrQODii27WMieIsLQmig5UPEOAcPLb79nZt0",
          "hostname": "www.legolandresort.dk",
          "port": "80",
          "addressesResolved": [
            "148.251.16.18",
            "2a01:4f8:200:62e2::612"
          ],
          "addressUsed": "148.251.16.18",
          "addressesTried": [
            "2a01:4f8:200:62e2::612"
          ]
        },
        {
          "url": "https://www.legolandresort.dk/.well-known/acme-challenge/pF-_uvXNrQODii27WMieIsLQmig5UPEOAcPLb79nZt0",
          "hostname": "www.legolandresort.dk",
          "port": "443",
          "addressesResolved": [
            "148.251.16.18",
            "2a01:4f8:200:62e2::612"
          ],
          "addressUsed": "148.251.16.18",
          "addressesTried": [
            "2a01:4f8:200:62e2::612"
          ]
        }
      ]
    },
    {
      "type": "tls-alpn-01",
      "status": "invalid",
      "url": "https://acme-staging-v02.api.letsencrypt.org/acme/challenge/mlLLanOSkAcUQ_Uo2T_Q6SzdZ7d7Hkhr1DPbOz9pCRM/155393175",
      "token": "pJMncW9LnSV_COkAkdHySt47BLCEKrGk-fDJdOH7X3A"
    }
  ]
}
4

Weird, I’m 5/5 for being unable to reproduce it on your domain.

The most I can suggest would be to repair your IPv6 connection, your server isn’t responding on its IPv6 address (wait, it just did for the first time for me).

Maybe cpu/jsha can pop by and comment on the RPC failure (though I suspect it could be related to this - the IPv6 timeout may be causing the RPC deadline to expire).

1 Like
5

That's an interesting theory. I'm not entirely sure. I do see a spike in RPC timeouts in the staging environment. Looking into it.

6

The spike was smaller than expected and the errors all corresponded to this domain.

@Webdock I expect that @_az's theory is correct and the IPv6 misconfiguration on your server is causing a remote validation attempt to timeout, which is being misrepresented as an internal server error due to an outstanding Boulder bug.

@Webdock - Can you fix the IPv6 connectivity or remove the AAAA records for the domain and try again? It would be helpful to hear if this resolves the problem.

1 Like
7

You are correct that IPv6 is misconfigured for that server. It is on the datacenter level and we are investigating if we can fix it there. Unfortunately we do not have control over DNS for those domains, so we cannot do a quick fix here.

I will report back here with my findings, but I suspect that as soon as we get IPv6 up everything will work.

Thank you for your assistance…!

1 Like
8

Repairing IPv6 did indeed clear up the issue

Thank you for your help :O)

1 Like
9

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