Why is renewal asking me for acme-challenge?

Hi, I've successfully installed before, and also renewed once before in July. Renewal started failing for me.

Command: certbot-auto renew --dry-run


 - The following errors were reported by the server:

   Domain: <domain>
   Type:   unauthorized
   Detail: Invalid response from
   \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not
   Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

   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.

I've never had to create that file before and it doesn't tell me how. My site is protected behind basic authentication anyway so the outside bot never would have been able to reach the site. I've also never create a TXT dns field. Why is renew asking me for this? In July, certbot-auto renew worked fine.

I have a dim memory that when I installed, I did a standalone or certonly option, from not wanting to mess with my apache config. So now, when I stopped apache and ran:

certbot-auto --standalone renew --dry-run

It succeeded, but when I then ran:

certbot-auto --standalone renew

It failed. It took me a while to realize that the --dry-run command had actually restarted apache. So then I stopped apache again, and ran

certbot-auto --standalone renew

again, and it succeeded.

So hooray, I am renewed now. But I don't know why the renew command started believing I had an acme-challenge file. Is it possible I started with an earlier certbot version that upgraded itself in a way that screwed things up?

I just realized that

> certbot-auto renew --pre-hook "service apache2 stop" --post-hook "service apache2 start"

will work for me going forward, so I guess I've solved my problem. But I'll leave this up in case it helps someone else. Disconcerting how the right command changes over time, because I thought I had auto-renewal working.

1 Like

Welcome to the Let's Encrypt Community :slightly_smiling_face:

If you're using either the apache or standalone authenticator, you are using http-01 challenges that use files in webroot/.well-known/acme-challenge/ that are created by certbot. The standalone authenticator spins up its own webserver so your basic authentication wouldn't affect it. The apache authenticator creates a port 80 exception and doesn't utilize your site's content. You could have used the webroot authenticator instead of the apache authenticator to avoid having certbot interfere with your apache operation.

Based on the IPv6 address present in your error message, I suspect that you could have a faulty IPv6 address, which is very common around here. Without your domain name, I can't run any useful diagnostics though.

1 Like

Hi, thanks Griffin. I actually did have some ipv6 problems a while back - I had added ipv6 configurations to my server and DNS, after July, so after my most recent renewal, but neglected to add them to my vhost definition. Wildly confusing since the site worked for half my friends (on ISPs that defaulted to ipv4) and not for the other half (on IPSs that default to ipv6). I adjusted the vhost and got that squared away to the point that it works for all my friends, though. The site is storysprawl.com (a site to allow people to write chapters of branching novels together).


Nice! I'm a writer myself. Well, a beginning writer anyhow. :blush:

Certbot defaults to using IPv6, which tends to catch many people off guard.

Your redirects generally look fine. You probably want to decide www or non-www and redirect to that in order to canonicalize your address.

I just ran your site through our diagnostic tool and it's as I feared (different response codes from same server per _az's comment below). With standalone this won't pose any issues.

1 Like

... @_az good thinking including that test in letsdebug, though! :clap:


I'm so glad @_az managed to resurrect Let's Debug. :zombie:

1 Like

A false positive in this case though. If the standalone authenticator was being used historically, then it doesn't matter how Apache is configured.

We can infer that the IPv4 and IPv6 address point to the same server because both addresses have the same SSH host key fingerprint.

It sounds from the OP like --pre-hook/post-hook got wiped out of the renewal parameters for some reason.

Encoding it into the cronjob is a fairly safe way to ensure it runs, I guess (if you want to continue using the standalone authenticator).


I figured the different response codes were a sign of a misconfigured webserver. I didn't actually think it caused the certbot issue at that point. I should have made that more clear. :slightly_smiling_face:

1 Like