Trouble with issuing certs

My domain is:
http://dan.bfp.com/

I ran this command:
[lua] client.lua:232: post(): acme request via https://github.com/auto-ssl/lua-resty-auto-ssl

It produced this output:

{
  "identifier": {
    "type": "dns",
    "value": "dan.bfp.com"
  },
  "status": "invalid",
  "expires": "2020-08-19T15:25:46Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:unauthorized",
        "detail": "Invalid response from http://dan.bfp.com/.well-known/acme-challenge/... [2a05:d014:9da:8c10:306e:3e07:a16f:a552]: \"\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/chall-v3/...",
      "token": "...",
      "validationRecord": [
        {
          "url": "http://dan.bfp.com/.well-known/acme-challenge/...",
          "hostname": "dan.bfp.com",
          "port": "80",
          "addressesResolved": [
            "52.58.78.16",
            "2a05:d014:9da:8c10:306e:3e07:a16f:a552"
          ],
          "addressUsed": "2a05:d014:9da:8c10:306e:3e07:a16f:a552"
        }
      ]
    }
  ]
}

Trying to issue an cert for the subdomain and everywhere I can check I’m seeing the subdomain correctly resolve to 199.59.242.154, i.e. https://www.whatsmydns.net/#A/dan.bfp.com/199.59.242.154

However, as you can see from above, letsencrypt seems to be resolving it to the other two other IP addresses.

The subdomain had an AAAA record originally which has since been removed.

Any insight on how to get letsencrypt to use the correct ip?

1 Like

It seems the IPv6 address is not gone.

2 Likes

Your nameservers seem to be giving out different information.
When queried via IPv4, nothing/empty is returned.
When querried via IPv6, they return a CNAME to 1.dam.bodis.com

image

3 Likes

Hi rg305, thanks for taking a look.

It seems the IPv6 address is not gone.

The IPv6 answer has been removed from the name servers already. I don’t see them when querying the name servers directly. Are they being cached by LetsEncrypt? It’s not clear to us why the challenges are still resolving to these alternate addresses.

I’ve watched the records change from an AAAA that resolved to an IPv6 address, to now the cname, i.e.

nslookup -query=AAAA dan.bfp.com ns2.dan.com
Server:		ns2.dan.com
Address:	3.120.163.96#53

dan.bfp.com	canonical name = 1.dan.bodis.com

This was done a while ago, it seems almost as if they’re still cached? Or I’m trying to issue an https certificate on a subdomain and there might be an certificate on the apex domain, could that be an issue?

ns1.dan.com:

https://centralops.net/co/NsLookup.aspx?domain=dan.bfp.com&type=1&server=ns1.dan.com&class=1&port=53&timeout=5000

ns2.dan.com:

https://centralops.net/co/NsLookup.aspx?domain=dan.bfp.com&type=1&server=ns2.dan.com&class=1&port=53&timeout=5000

2 Likes

The only way this would be a problem is if the certificate for the apex domain were being served in lieu of yours. I did a little research into your domain and uncovered a few things that might be causing greater problems.

https://dan.bfp.com :

1 Like

It doesn’t look like you’ve ever had a Let’s Encrypt certificate issued for dan.bfp.com, but I do see a recent one for bfp.com:

https://crt.sh/?q=dan.bfp.com

https://crt.sh/?q=bfp.com

1 Like

I posted wrong second image.

https://crt.sh/?q=bfp.com

1 Like

The Let’s Encrypt certificate issued for bfp.com and www.bfp.com does not include dan.bfp.com, so no problem there with overlap.

Is bfp.com hosted on a shared server requiring SNI?

1 Like
2 Likes

Are you still having the DNS problem (wrong IP) ?
If so, this is the only thing I could see that is… “questionable”:

The server responded with no OPT record, rather than with RCODE FORMERR.

See: https://dnsviz.net/d/bfp.com/dnssec/

3 Likes

Thank you @rg305 and @freessltools.com, I’m told the issue is now resolved and was to do with the DNS 0x20 (mixed case) as mentioned on the https://unboundtest.com/ homepage.

3 Likes

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