Acme: error code 403 "urn:ietf:params:acme:error:unauthorized": Invalid response from http://fms-caboverde.com/.well-known/acme-challenge

Help
1

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. https://crt.sh/?q=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:fms-boatcv.com

I ran this command: $ sudo ./letsencrypt-auto certonly --standalone -d fms-caboverde.com

It produced this output:
Some challenges have failed.

IMPORTANT NOTES:

My web server is (include version): Nginx 1.14.0 (Ubuntu)

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

My hosting provider, if applicable, is: do.de

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

1 Like
2

Is there any error message in the logs?
[that might indicate that certbot was unable to spin up a temporary server - unable to bind to port 80]

1 Like
3

Well, when running https://letsdebug.net/fms-caboverde.com/123827?debug=y

I’ll get this.

acme: error code 403 “urn:ietf:params:acme:error:unauthorized”: Invalid response from http://fms-caboverde.com/.well-known/acme-challenge/1z0i7ObwQDXmOIV1x2QPLBQ9qUnY8GZqCmQJCsMxIe4 [41.215.223.67]: “\n404 Not Found\n

Not Found

\n

The requested URL was”

When I run the tls-alpn-01 challenge test I get the following error:

LetsEncryptStaging

DEBUG

Challenge update failures for fms-caboverde.com in order https://acme-staging-v02.api.letsencrypt.org/acme/order/5751349/85627301

acme: error code 400 “urn:ietf:params:acme:error:connection”: Error getting validation data.

4

When running LD, you are seeing what happens when an external system connects to your current web server.

When using:

You are NOT supposed to be using your current web server.
In that command, you are asking certbot to start a new (temporary) web server to serve the auth request.
[it would be expected that you would stop your web service immediately before and restart it immediately after]

So, you have not checked the right web server.

And, thus, I repeat my question:

1 Like
5

Sorry, I am completely new to this stuff . I found this in the log:

2020-04-17 18:50:24,853:DEBUG:acme.client:Storing nonce: 010165CmLF7G7FpviiE4FyxiAwAkLGB1jASPGL8drm4gzig
2020-04-17 18:50:24,854:INFO:certbot._internal.auth_handler:Performing the following challenges:
2020-04-17 18:50:24,855:INFO:certbot._internal.auth_handler:http-01 challenge for fms-caboverde.com
2020-04-17 18:50:24,855:INFO:certbot._internal.auth_handler:http-01 challenge for www.fms-caboverde.com
2020-04-17 18:50:24,856:DEBUG:acme.standalone:Successfully bound to :80 using IPv6
2020-04-17 18:50:24,856:DEBUG:acme.standalone:Certbot wasn’t able to bind to :80 using IPv4, this is often expected due to the dual stack nature of IPv6 socket implementations.

6

That confirms my suspicions.
In order to run the standalone option, you must first stop the current web service on port 80.

7

NGINX listens on port 80.
Although you’ll get an error message right away if Nginx service isn’t stopped before attempting to run certbot.

I read quit a bit about an IPv6 issue without really understanding what the problem is.

(2020-04-17 18:50:24,856:DEBUG:acme.standalone:Certbot wasn’t able to bind to :80 using IPv4, this is often expected due to the dual stack nature of IPv6 socket implementations.)

It seems like it successful with IPv6 but struggles with IPv4.

8

More like: Something is already using that IP:port.

9

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