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:
apps.library.newpaltz.edu
I ran this command:
certbot renew --dry-run --debug-challenges -v
It produced this output: it said "Everything works, bro, your challenge URL exists & the value inside was sweet. Just Chill !"
But it lied to me the folder /.well-known/acme-challenge/ folder does not exist ! ? ! ?
& When I go to the challenge URL in a browser it's all like 404 dude.
How and where is the /.well-known/acme-challenge/ created?
What permissions does it require?
Can I create the folder and the challenge file myself?
My web server is (include version):
Apache 4.3
The operating system my web server runs on is (include version):
RHEL 7
Camandlines and GUI console
The version of my client is : 2.6.0
Not sure what you mean by "authenticator" Here is the output:
certbot renew --dry-run --debug-challenges -v
Saving debug log to /var/log/letsencrypt/letsencrypt.log
What this does is temporarily modify your Apache configuration so that requests to /.well-known/acme-challenge/ get served from a directory within /var/lib/letsencrypt/.
Once the certificate order is complete, the changes to your configuration get automatically reverted and the challenge response file is deleted.
By the looks of things, everything succeeded. What's the problem?
So far it has not shown any ability to modify my httpd settings. For example to make the certificate work in the first place I had to manually enter the cert and key and chain paths in my old ssl.conf file. Even though the install told me everything went fine.
I have a hard time believing the messages it gives because 2 years ago when I tried it on different but similar sever it was a nightmare to get automatic renewal to work this time I need a way to be certain.
VirtualHost configuration:
*:80 apps.library.newpaltz.edu (/etc/httpd/conf/httpd.conf:377)
*:443 is a NameVirtualHost
default server apps.library.newpaltz.edu (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost apps.library.newpaltz.edu (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost apps.library.newpaltz.edu (/etc/httpd/conf/httpd-le-ssl.conf:2)
Yeah, you have the same domain name handled by two different config files. Only one will be used (ssl.conf by the sounds of it).
The httpd-le-ssl.conf was made by Certbot based on your httpd.conf file.
I think the problem may be that your httpd.conf file is in /conf/ folder whereas the older ssl.conf file is in /conf.d/
Certbot may have created the new httpd-le-ssl.conf in the same folder as the http (port 80) one and didn't see the one for https (port 443) in conf.d
I'm not exactly sure the best way to sort out this mix and I don't have time to work up a test case for it. At least this might help explain what is happening
" requests to /.well-known/acme-challenge/ get served from a directory within /var/lib/letsencrypt/ ."
If you can tell me what folder inside /var/lib/letsencrypt/ is the folder that holds the challenge file I will make a permanent link to that folder in my server config.
That's not needed or helpful. The Apache authenticator handles that automatically. _az, a Certbot developer, already described how that worked earlier.
Indeed, if you're using --apache, you can't make it not make this change to your configuration automatically, or not remove the change automatically afterwards!
(It might get confused about how to make that change correctly if there are multiple VirtualHosts that appear to cover the same name.)
If you want
to make --apache work: make sure the VirtualHost configuration is correct and that each one covers a unique name or set of names
to see what --apache did to your configuration in the course of satisfying the certificate authority's challenge: add the --debug-challenges option
to actually manually map a directory as the existing static content webroot (and be able to see /.well-known/acme-challenge on your disk on an ongoing basis): use --webroot instead of --apache (then you'll have to manually install the certificate afterward)
to make Certbot use a static content webroot location to request the certificate, but still attempt to install the certificate for you afterward: use -a webroot -i apache (splitting the authentication and installation functionality between two different Certbot plug-ins).
Thanks for all your help, it is great to see people respond quickly.
So the reason my server is not reading any of your modified SSL settings is because CertBot/Let’s Encrypt, could not read the VHOST in my SSL.conf file for some reason. Then it created a redundant SSL settings file with a redundant VHOST that the system is ignoring.
Perhaps we could fix the problem that prevented CertBot from reading the VHOST in my SSL.conf and reinstall it?
When I run certbot renew --dry-run --debug-challenges -v
I must assume the dry run is not testing the actual challenge file being available on web from server. I assume that because my server is ignoring the VHOST settings in your redundant ssl settings file.
Is the redundant SSL settings file or its include file the way certbot makes available the challenge files? ? That is my guess.
I looked at your previous instructions and I found the challenge folder and made it available from my httpd.conf with an alias that worked so I again ran “certbot renew --dry-run --debug-challenges -v” again and it did not find any issues or errors so I’m sticking with this fix for now.
I'm happy that you are able to pass the --dry-run test.
You should review the certs [and names] covered, with: certbot certificates
Ensuring the there are no name overlaps, no unused certs, no expired/unrenewing certs, and that all certs are being properly used by your web server.
If anything looks out-of-place or simply doesn't make sense to you, feel free to post that output here for our review.
I still think this is the likely reason although I have not tested it yet. You could just migrate any unique settings in the ssl.conf file into the one Certbot created in the /conf/ folder. Then, move your ssl.conf to a completely different folder so Apache doesn't still see it. Restart Apache. Run certbot renew --dry-run to test renewal
It actually does test it, using the Let's Encrypt staging service instead of the real Let's Encrypt service. The staging service will also specify location and contents for a challenge file, and will then make a connection from the Internet to check these on your web server. However, the staging service can't issue a publicly-trusted certificate. It issues a non-publicly-trusted certificate for your site, which --dry-run then doesn't save to disk anywhere (because it normally wouldn't be useful to you in any way).