Dry Run Working, Real Run Not

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: www.peregrineit.net

I ran this command:
/usr/bin/certbot certonly --dry-run --agree-tos --force-renewal --standalone --preferred-challenges http --http-01-port 54321 -d www.peregrineit.net

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Obtaining a new certificate

IMPORTANT NOTES:

  • The dry run was successful.

I then immediatemly ran this command:
/usr/bin/certbot certonly --agree-tos --force-renewal --standalone --preferred-challenges http --http-01-port 54321 -d www.peregrineit.net

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.peregrineit.net
Waiting for verification…
Challenge failed for domain www.peregrineit.net
http-01 challenge for www.peregrineit.net
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: www.peregrineit.net
    Type: connection
    Detail: Fetching
    https://www.peregrineit.net/.well-known/acme-challenge/pacvZpiplRG1pApFK7on1Qa0h6jlhi5iYzuOToa6L5E:
    Error getting validation data

    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. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My web server is (include version):
Niginx (latest version, on a differennt server
HAproxy (latest version) on this server

The operating system my web server runs on is (include version): centos 7 (latest version)

My hosting provider, if applicable, is: N/A

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): N/A

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

Any help is greatly appreciated :smile:

As far as dry run working/real run not working goes, this is most likely due to Let’s Encrypt caching a previous successful authorization.

You can avoid that by deleting your staging account:

mv  /etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org \
/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org.bak

After you do that, both should be failing.

1 Like

Yes, both are now failing - so, how do I fix things? :smiley:

1 Like

Hi @dulux-oz,

Do you understand the various parts of this command that you’re using?

in this case this says that you want Certbot to create its own temporary web server and have it run on port 54321. Something else (like a firewall or reverse proxy) will then be responsible for mapping the publicly-visible port 80, as seen by the rest of the Internet, to that port. I don’t think that’s happening in this case—or is it?

1 Like

From their other thread, I believe OP is proxying through to 54321 from haproxy.

2 Likes

Thanks @_az. In that case, I suspect that the haproxy configuration might be messed up or might be different in some way than it was when this certificate was originally issued.

1 Like