HELP certbot renew ERROR

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: collisdesign.com.au

I ran this command: certbot renew [dry run, even new install]

It produced this output:
1 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:

My web server is (include version): Apache
The operating system my web server runs on is (include version): MAC [mojave 10.14.6]

My hosting provider, if applicable, is: My MacMini

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):
certbot 0.32.0

MY NOTES: Using LE since 2019 - renew every 90 days with no issues until now [Aug 2022]. From forum search and Mac Terminal response, ".well-known/acme-challenge/" is a smoking gun. Have even created this hidden folder manually.
Forum posts mention adding "skip challenge requests" to server config?
Before I go down the rabbit hole, hopefully someone here can assist with a fix.

Also ran in terminal: apachectl -S
AH00526: Syntax error on line 25 of /private/etc/apache2/extra/httpd-vhosts-le-ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/collisdesign.com.au/fullchain.pem' does not exist or is empty

1 Like

...forgot to add: Server version: Apache/2.4.46 (Unix)

1 Like

Have you changed anything in your NAT or port-forwarding or MAC? Because these are the response headers from your domain. It looks like WebDAV is now responding to requests on port 80 (http) and not Apache.

curl -I collisdesign.com.au

HTTP/1.1 401 Unauthorized
Content-Length: 0
Www-Authenticate: Digest realm="WebDAVNav Server", qop="auth", nonce="FABC6C06-EAF0-43DA-8AAD-5E0BE95327C0"
Accept-Ranges: bytes
Date: Tue, 23 Aug 2022 12:14:14 GMT
4 Likes

...thanks Mike for the reply [at least someone].
Had WebDAVNav Server running whilst Apache/LE SSL was not working.
fyi, absolutely no changes have been made prior to this issue - this MacMini sits in the corner doing nothing except running as a web server/internal file server/web development server.
Anyway, long story short... SOLUTION FIX: Forget LE as provider of SSL Cert, moved over to, now using ZeroSSL who also provide a 90 day $0 cost option plus have a super simple how-to guide to install certs on Apache. Job Done.

3 Likes

Well, something must have changed.

The apachectl -S identified a missing certificate file. That would have prevented Apache starting.

Your history showed you renewed certs on date of expiry or day before. Generally that's done with 30 days remaining to ensure enough time to resolve problems. You should probably change that for ZeroSSL too.

Your comment about the acme-challenge folder wasn't important. Those are created and populated if/as needed.

I can't imagine why a forum post would say "add skip challenge requests to server config". That's, well, not possible to skip challenges. If you have the post please share it so we can correct that person.

In short, there was a lot to unpack in your first post. The mystery WebDAV I found on my own was as good a place as any to start.

If you become unsatisfied with ZeroSSL come on back. I'm sure we can work through it.

Glad you got something working.

4 Likes

post re skip challenge comment

[Jan 4]

3 Likes

Thanks for following through. That sample code results in the challenge handled in the HTTP VirtualHost and to redirect all other requests to HTTPS. That code sample, or something like it, can be helpful with certbot --webroot authentication.

I am not sure what he meant by "skip challenge requests". @rg305 may be the most prolific volunteer and with 22,000+ posts they won't all be golden :slight_smile:

4 Likes

That comment needs to be read within the context - see both comments:

  #skip challenge requests and
  #send all other requests to HTTPS

In short
Read together, they essentially mean:
Don't forward the challenge requests to HTTPS [forward all others]

In long
That location block should NOT apply to ACME challenge requests.
So, it only forward the request that aren't challenging - LOL

3 Likes

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