[SOLVED!] Dry runs failing

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. crt.sh | 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:

I ran this command:
certbot certonly --apache --dry-run -v

It produced this output:
Simulating a certificate request for vnpreviews.com
Performing the following challenges:
http-01 challenge for vnpreviews.com
Waiting for verification...
Challenge failed for domain vnpreviews.com
http-01 challenge for vnpreviews.com

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: vnpreviews.com
Type: connection
Detail: Fetching https://scribestories.com/index.php: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Cleaning up challenges
Some challenges have failed.

My web server is (include version):
Linux 5.10.0-20-amd64 on x86_64

The operating system my web server runs on is (include version):
Debian Linux 11

My hosting provider, if applicable, is:
1&1 Ionos for the domain address, OVH for the cloud server.

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
I have access to Virtualmin GPL (version 7.5), but I'm also comfortable shelling in with PuTTY.

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

Your DNS has an AAAA record for IPv6. But, trying that connection fails even for your "home" page.

The error message shows an IPv4 address as sometimes Let's Encrypt will try IPv4 when IPv6 fails. But, in some cases fixing your incorrect AAAA record will resolve this. You should fix that anyway so people can use IPv6 as you intend.

The other odd thing is you are redirecting requests from vnpreviews to scribestories. If that's intended that's fine. It's unusual so I point it out in case something has gone wrong in your Apache config.

(IPv6 failing)
curl -i6 -m8 vnpreviews.com
curl: (28) Failed to connect to vnpreviews.com port 80 after 4002 ms: Connection timed out

(IPv4 works but redirects to scribe.)
curl -i4 -m8 vnpreviews.com
HTTP/1.1 302 Found
Server: Apache/2.4.54 (Debian)
Location: https://scribestories.com/

Also Let's Debug the results are showing 3 ERRORs https://letsdebug.net/vnpreviews.com/1347124


Yes, Bruce's post reminded me that not only do you redirect from vnpreviews to scribe you also modify the HTTP challenge URL to something that won't work (even if comms worked)

Note the detailed info from the Let's Debug test that shows the challenge redirected to index.php

@0ms: Making a request to http://vnpreviews.com/.well-known/acme-challenge/letsdebug-test
@20ms: Server response: HTTP 302 Found
@20ms: Received redirect to https://scribestories.com/index.php

Showing what @MikeMcQ said only with curl

$ curl -Ii http://vnpreviews.com/.well-known/acme-challenge/letsdebug-test
HTTP/1.1 302 Found
Date: Mon, 23 Jan 2023 23:48:58 GMT
Server: Apache/2.4.54 (Debian)
Location: https://scribestories.com/index.php
Content-Type: text/html; charset=iso-8859-1

$ curl -Ii https://scribestories.com/index.php
HTTP/1.1 301 Moved Permanently
Date: Mon, 23 Jan 2023 23:50:14 GMT
Server: Apache/2.4.54 (Debian)
X-Redirect-By: WordPress
Location: https://scribestories.com/
Content-Type: text/html; charset=UTF-8

$ curl -Ii https://scribestories.com/
HTTP/1.1 200 OK
Date: Mon, 23 Jan 2023 23:50:33 GMT
Server: Apache/2.4.54 (Debian)
Link: <https://scribestories.com/wp-json/>; rel="https://api.w.org/"
Content-Type: text/html; charset=UTF-8

This online tool can be of help as well Redirect Checker | Check your Statuscode 301 vs 302

1 Like

Wow, I'm a goof.

Mike got it. IPv6 wasn't enabled on my server, but it's enabled now and the dry runs are working flawlessly.

Thank you! :smiley:

[Edit:] Also, sorry. Didn't mean to delete my last reply. I just finished a quick edit and knocked the delete button by mistake.


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