Certificate Request/Renew failed when host runs on dual stack (IPv4/IPv6)

Help
1

When trying to request or renew a certificate on a system that is running dual stack IP addressing, the request fails due to the domain lookup resolving to 2 IP addresses. The only work around is to remove IPv6 address from the dns records, renew/request and re-apply the IPv6 dns entry. I see that this issue has been around for sometime… is there any other work arounds?

2

You shouldn't need to do this - if Let's Encrypt finds an AAAA record for your domain on your authoritative nameservers, then it uses IPv6 only. The issue a lot of people have where the recommendation is "disable IPv6" is because they're not able to set up IPv6 to route properly, so that's the simplest (albeit not the best) solution.

In your case, IPv6 shouldn't be an issue, assuming that it routes identically to IPv4. Could you fill out the questionnaire you were presented when creating this topic? That will help us figure out what's actually preventing this issuance. See below, and note we're particularly interested in the answers to the first three questions in this case.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

2 Likes
3

My domain is: status.rocketnet.co.za

I ran this command: certbot -d status.rocketnet.co.za

It produced this output: below

My web server is (include version): nginx version: nginx/1.12.2

The operating system my web server runs on is (include version): CentOS Linux release 7.5.1804 (Core)

My hosting provider, if applicable, is: NA

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

{
  "identifier": {
    "type": "dns",
    "value": "status.rocketnet.co.za"
  },
  "status": "invalid",
  "expires": "2018-09-03T14:23:54Z",
  "challenges": [
    {
      "type": "tls-alpn-01",
      "status": "invalid",
      "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/cli1IdMFprseq2ZI-EiGmatIx6siVnQ8B6G8_lqDu-U/6821638884",
      "token": "8ROmQQSEo7RDXV2YLVJQqb9QXyor6EPFb3TidvhKdrc"
    },
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:unauthorized",
        "detail": "Invalid response from http://status.rocketnet.co.za/.well-known/acme-challenge/aZJkyrmZ_Xq900prdLD2vUSGp3syXvsvVv-9i2kswR0: \"\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody bgcolor=\"white\"\u003e\r\n\u003ccenter\u003e\u003ch1\u003e404 Not Found\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003e\"",
        "status": 403
      },
      "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/cli1IdMFprseq2ZI-EiGmatIx6siVnQ8B6G8_lqDu-U/6821638885",
      "token": "aZJkyrmZ_Xq900prdLD2vUSGp3syXvsvVv-9i2kswR0",
      "validationRecord": [
        {
          "url": "http://status.rocketnet.co.za/.well-known/acme-challenge/aZJkyrmZ_Xq900prdLD2vUSGp3syXvsvVv-9i2kswR0",
          "hostname": "status.rocketnet.co.za",
          "port": "80",
          "addressesResolved": [
            "169.255.0.134",
            "2c0f:f2a0:0:1::134"
          ],
          "addressUsed": "2c0f:f2a0:0:1::134"
        }
      ]
    },
    {
      "type": "dns-01",
      "status": "invalid",
      "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/cli1IdMFprseq2ZI-EiGmatIx6siVnQ8B6G8_lqDu-U/6821638886",
      "token": "KEGGTfVgprgSL98y2AOSvROVNM7KYisJkL8QoZDLdns"
    }
  ]
}

Domain: status.rocketnet.co.za
Type:   unauthorized
Detail: Invalid response from http://status.rocketnet.co.za/.well-known/acme-challenge/aZJkyrmZ_Xq900prdLD2vUSGp3syXvsvVv-9i2kswR0: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>"
4

Cool, so it's using the HTTP-01, which is a good choice for most implementations, and we see that Let's Encrypt is using your IPv6 address to attempt to load the challenge file:

However, your server is giving back a 404 instead of the challenge file. It's possible that Certbot is having a hard time parsing your nginx configs to determine where it should be serving the challenge file from. You might try specifying a webroot directory for that domain with -w. This tells Certbot the root directory where it should add .well-known/acme-challenge to in order to place the challenge file.

I believe newer versions of Certbot attempt to re-configure the nginx configs to serve the file from a specific server block, but I think the -w flag causes it to use "webroot" instead. You might need to specify -a webroot -i nginx instead of just nginx on your command to force that behavior.

5

Great, makes sense. I’ll try the next time specify the webroot to make sure it references the correct local path. IPv4 doesn’t seem to suffer from this issue, so if you would like any more debug information, I’m more than happy to assist.

6

http://status.rocketnet.co.za/ and https://status.rocketnet.co.za/ behave differently over IPv4 and IPv6.

Certbot’s Nginx plugin should handle everything appropriately, but if the web server configuration already has issues, it’s more likely to run into trouble.

What’s the Nginx configuration? Are all of the listen directives correct?

2 Likes
7

Autsj, so IPv6 users couldn't even properly use the site? :hushed:

8

In the past i’ve had to set the listen directives for v4 and v6, but had hoped that through the auto-redirect setup after the cert is renewed it would add it for the https… It seems that NGINX doesnt listen on IPV6 within a server directive unless its specified manually… something I’ll keep an eye on in future…

Thanks, both listen directives have been applied.

9

Yeah this is pre-https so the https wouldn’t part of the set up topic :slight_smile: I didn’t get a chance to finish the set up by the time I got back to check my posts :slight_smile:

Appreciate all the help!

10

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