Hi - I am running Ubuntu 16.04 and attempting to set up SSL with certbot. I got everything installed with no problem and successfully got a certificate doing certbot --apache --staging and following the prompts. Once I tried removing the --staging part of this command I ran in to the acme-challenge 404 issue that seems to plague these forums. I tried staging again, no problem. Tried non-staging again, same issue. I have removed all .htaccess, all redirects, created and tested /.well-known/acme-challenge/test.txt in my docroot and confirmed that it is viewable in a browser.
Tried a couple more times and now I’ve hit the rate limit - guess I didn’t realize that failed attempts were counting against me… so now I’ll be waiting for another shot - luckily this is a testing domain so no big deal.
A couple questions -
Is certbot actually attempting to create the authorization file and directory tree in my docroot? The first few attempts I can confirm that those directories do not exist. Later I manually created them - but not sure how staging succeeded. I’m now wondering if they were being created there and then subsequently removed? Or are they possibly being created somewhere else and there should be an alias set up to reach that location?
What possible reasons could there be that this works fine in staging but then fails not in staging?
Looking forward to getting this working - I’m open to trying a manual process but honestly I’d REALLY like the automatic configuration to succeed so I can be as hands off with this stuff in production as possible.
Going to solve my own problem here and provide some info that may be useful to others:
After looking at the logs I discovered the answer to my first question above. certbot does indeed create a temporary rewrite to it’s own challenge folder by adding this to my config file (and then removing it)
RewriteEngine on
RewriteRule ^/\.well-known/acme-challenge/([A-Za-z0-9-_=]+)$ /var/lib/letsencrypt/http_challenges/$1
<Directory /var/lib/letsencrypt/http_challenges>
Require all granted
</Directory>
<Location /.well-known/acme-challenge>
Require all granted
</Location>
Pretty sure I just discovered the reason why this is failing - a rogue ipv6 dns record. Apparently the staging server used ipv4 which had the correct address - but the production server was trying via ipv6 which was failing. This being a development server it really never came up before. I discovered this in the json output foraddressUsed in the failed segments. Moral of the store: always read the logs
I'm glad you figured it out, and to more fully answer this question: it would if you used --webroot (or -a webroot), but with --apache it instead does the thing you saw involving a temporary rewrite.
Thanks for explaining! It makes perfect sense and it’s really helpful to understand that there’s a difference in mechanics between those two methods. I read a bit about --webroot but didn’t grasp this bit. Are these behaviours documented? If so, can you link to them for further reading?
but I guess I still need to update that documentation following the TLS-SNI-01 deprecation and the addition of HTTP-01 support to the Apache and nginx plugins.
