Certbot doesn't work with own temporary webserver

Help
1

The operating system my web server runs on is (include version):Ubuntu server 18.04.4
I can login to a root shell on my machine (yes or no, or I don’t know): yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.27.0

Running certbot with builtin webserver I get an error. Starting a simple webserver manually works well.

certbot certonly --standalone --test-cert --preferred-challenges http-01 -d [my fqdn]
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for [my fqdn]
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. [my fqdn] (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://[my fqdn]/.well-known/acme-challenge/9UehXhelUt606GErvJkGnwZFQfFGLN091B-AuxmbesA [my IP]: 503

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: [my fqdn]
    Type: unauthorized
    Detail: Invalid response from
    http://[my fqdn]/.well-known/acme-challenge/9UehXhelUt606GErvJkGnwZFQfFGLN091B-AuxmbesA
    [my IP]: 503

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.

And now with a simple webserver:
python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 …

Now starting certbot without “standalone”:
certbot certonly --test-cert --preferred-challenges http-01 -d [my fqdn]
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?

1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for [my fqdn]
Input the webroot for access3.schwindt.eu: (Enter ‘c’ to cancel): /root/www
Waiting for verification…
Cleaning up challenges

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/[my fqdn]/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/[my fqdn]/privkey.pem
    Your cert will expire on 2020-08-18. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew all of your certificates, run
    “certbot renew”

Any ideas?
Thanks!

1 Like
2

Further investigation:
Debug mode works well:
certbot certonly --standalone --debug-challenges -v --preferred-challenges http -d [my fqdn]
Batch doesn’t work:
certbot certonly --test-cert --standalone --preferred-challenges http -d [my fqdn]

So what is the difference?
Is this an issue with integrated webserver? Maybe a timing problem?

1 Like
3

Does your system have both IPv4 and IPv6 ?

Is that the latest version of certbot for your system?

1 Like
4

IPv6 is disabled (at boot time, grub).
Yes, the system is up-to-date.

5

I gave it up.
And configured the served webservice also on port 80 for ceritficat delivery.

6

I've read this post 3 or 4 times but I still struggle to make heads of tails of it.

Yesterday and the day before that, when I made a request to /.well-known/acme-challenge/test, your server did indeed produce the HTTP 503 that was reported here:

A 503 is generally indicative of a reverse proxy (haproxy maybe?) which is setup to proxy ACME challenge requests to e.g. Certbot's standalone mode.

In these situations though, you would nominate a port for an alternate (non-80) Certbot's standalone server to run on, like --http-01-port 8123, and you'd proxy the request through to that port.

However, today, for the same request, I get a 404. So It's hard to tell what's really going on.

I think the problem is also being confounded by authorization re-use/caching. Once you succeed once, the ACME server will generally not make you repeat the challenge for the same domain for ~30 days, so that can kind of muddy your tests up. You could even shut down your whole server and it would still appear to succeed.

I know that nothing I have written is particularly useful, but lacking other responses in the days this thread has been up, I suggest giving more detail about your webserver setup.

Edit: oh, you gave up right before I posted this, haha.

7

Yes, I have my workaround :slight_smile:

But, regarding your answer: yes, haproxy serve SNI forwarding, and ACME challenges to the right webservers.
Why do nominate an alternate port (non-80)? Does you know that only the integrated webserver “-standalone” have a problem with port 80? Other webservers works well, I tested 2 (on port 80).

8

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