Urn:acme:error:unauthorized Invalid response but acme file reachable

Help
1

Hi,

I have a problem with renewing one of my sites on a Digital Ocean server. The other sites (+10) do not have this problem and renew without problems.

Trying to renew the site certificate against the staging api I get this response. Using curl to access the file gives me a correct result back but not via Let’s Encrypt.


{
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:unauthorized",
    "detail": "Invalid response from http://inwestcorp.se/.well-known/acme-challenge/lL-as2ZPJxbhRNhFyFyOAFW9b4mFQJrjagCV4Qdc07A: \"\u003c!DOCTYPE html\u003e\n\n\u003c!--// OPEN HTML //--\u003e\n\u003chtml lang=\"sv-SE\" prefix=\"og: http://ogp.me/ns#\"\u003e\n\n\t\u003c!--// OPEN HEAD //--\u003e\n\t\u003chead\u003e\n\t\t\n\t\"",
    "status": 403
  },
  "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/ragNnMIVL9CjT3uej8GEZMXUhVojXKM8HLIFkV-chpM/43393666",
  "token": "lL-as2ZPJxbhRNhFyFyOAFW9b4mFQJrjagCV4Qdc07A",
  "keyAuthorization": "lL-as2ZPJxbhRNhFyFyOAFW9b4mFQJrjagCV4Qdc07A.Oj_C9tHEn2CiSV82gtHgMcSmDa2Z-26iKWRq6bT9rhI",
  "validationRecord": [
    {
      "url": "http://www.inwestcorp.se/.well-known/acme-challenge/lL-as2ZPJxbhRNhFyFyOAFW9b4mFQJrjagCV4Qdc07A",
      "hostname": "www.inwestcorp.se",
      "port": "80",
      "addressesResolved": [
        "188.166.133.135",
        "2a00:16d8:2:200::20"
      ],
      "addressUsed": "188.166.133.135",
      "addressesTried": []
    },
    {
      "url": "http://inwestcorp.se/.well-known/acme-challenge/lL-as2ZPJxbhRNhFyFyOAFW9b4mFQJrjagCV4Qdc07A",
      "hostname": "inwestcorp.se",
      "port": "80",
      "addressesResolved": [
        "188.166.133.135",
        "2a00:16d8:2:200::20"
      ],
      "addressUsed": "2a00:16d8:2:200::20",
      "addressesTried": []
    }
  ]
}

https://acme-staging.api.letsencrypt.org/acme/challenge/ragNnMIVL9CjT3uej8GEZMXUhVojXKM8HLIFkV-chpM/43393666

What the LE bot sees seems to be the beginning of the web page itself.

The relevant server blocks in nginx:

server {
  listen 80;

  server_name www.inwestcorp.se inwestcorp.se;

  include acme-challenge-location.conf;

  location / {
    return 301 https://$host$request_uri;
  }
}

And acme-challenge-location.conf:

location ^~ /.well-known/acme-challenge/ {
  alias /srv/www/letsencrypt/;
  try_files $uri =404;
}

I have read other threads with similar problems but have not found anything that applies to my situation.

  • Do you have any ideas as to why Let’s Encrypt fails for just this site but not the others?
  • And why it is accessible with curl but not by Let’s Encrypt?
2

“addressUsed”: “2a00:16d8:2:200::20”,
Your virtual host is not bound to IPv6; only IPv4:
listen 80;

3

Thank you for the reply!

Yes, that is true. Do you have any idea why there is no problem on any of the other sites then? The configs are identical to this one (only on port 80).

4

Because (I think recently) Lets Encrypt is preferring IPv6 over IPv4 when both are available.
If IPv6 connections can reach and be served by your system, then just add
listen [::]:80
below the other listen 80 directive.
If IPv6 is not able to be served by your system (for whatever reason), then you should probably remove it from DNS resolve:

Name: inwestcorp.se
Addresses: 2a00:16d8:2:200::20
188.166.133.135

Name: www.inwestcorp.se
Addresses: 2a00:16d8:2:200::20
188.166.133.135

If you can’t serve IPv6 and you can’t alter your DNS, then HTTP and HTTPS authentication will tend to fail and DNS authentication is out of the question; so you may have to try and try and try and hope that it will eventually use IPv4 and complete the challenge.

As far as I know, there is no “–forceIPv4” type of option available.

1 Like
5

Thank you for the detailed response, much appreciated!

I did try your suggestion as well as a few other combinations just in case (restarted nginx each time):

listen 80;
listen [::]:80;

same error

listen [::]:80;
listen 80;

same error

listen [::]:80;

Python error (httplib.BadStatusLine). Indicates that IPv6 perhaps is not used or that port 80 is at least required?

6

show results of:
ifconfig -a
or
ifconfig -a | grep addr:

7 
eth0      Link encap:Ethernet  HWaddr 26:02:ce:84:dd:4e
          inet addr:178.62.216.199  Bcast:178.62.255.255  Mask:255.255.192.0
          inet6 addr: fe80::2402:ceff:fe84:dd4e/64 Scope:Link
eth1      Link encap:Ethernet  HWaddr 7e:36:34:b2:e9:56
          inet addr:10.133.25.115  Bcast:10.133.255.255  Mask:255.255.0.0
          inet6 addr: fe80::7c36:34ff:feb2:e956/64 Scope:Link
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host

188.166.133.135 is a floating IP pointing to 178.62.216.199

8

Some more information:
Looking at the droplet now, a public IPv6 address is not activated.

9

If this IPv4 IP 188.166.133.135 goes to this IPv4 IP 178.62.216.199
Then this IPv6 IP 2a00:16d8:2:200::20 should go to this IPv6 IP fe80::2402:ceff:fe84:dd4e (on that same interface)
For IPv6 to reach your server.

Then you can add
listen [::]:80;
And things should improve.

10

Thank you for your help so far!

I will try to make the changes and try again. Either that or remove the IPv6 address (not really used anywhere else) as soon as I get a hold of the client with the domain info.

I will update this post with the results.

11

A follow up:

It was as you suggested, IPv6 address of the domain was not correct. Removing IPv6 address DNS entry from domain solved the problem.

Thanks!

12

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