Standalone expand gives challenge failed

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. |, 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:
sudo apachectl stop
sudo certbot certonly --standalone --expand -d -d

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate for and
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Challenge failed for domain
http-01 challenge for
Cleaning up challenges
Some challenges have failed.


My web server is (include version):
gunicorn (version 20.0.4)

The operating system my web server runs on is (include version):
cat /etc/os-release
NAME="Oracle Linux Server"

cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.9 (Maipo)

My hosting provider, if applicable, is: oracle cloud

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. My webserver is behind a public load balancer which already has a certificate generated by certbot. It works. I want to expand my cert and that is what is not working

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

1 Like

Hi @galactic_hitchhiker,

Interestingly, it seems like you have two different servers answering there, maybe behind some kind of load balancer? When I try to connect to your server with curl, it seems to alternate between one machine that says Welcome to Metrics Dashboard and one that says This is Web Server 1, and the two of them seem to be running different server software. If so, I'd guess that that's the reason for the failed challenge—when the Let's Encrypt CA tried to connect to your server to confirm your control over the domain name, it worked sometimes (because sometimes it connected to the machine running certbot --standalone) and failed sometimes (because sometimes it connected to another machine). This could also explain why it failed in secondary rather than primary validation.

1 Like

OMG! You hit it on the head!
Of course, now I see it. Thanks for the second set of eyes.
I was shutting down Apache but not gunicorn.
My load balancer was still redirecting port 80 traffic to port 5000 after SSL termination and that ended up being handled by the gunicorn server so the certbot could not see it.
Once I stopped gunicorn too, everything worked like a charm.

Thank you @schoen

1 Like

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