Hi all,
How can I change the cerbot path that’s used for creating certs using webroot? By that I mean:
/.well-known/acme-challenge/blah
I’m running into an issue where a CDN/reverse proxy I use, who supplies certs from let’s encrypt, is also using that path so it’s preventing me from creating/renewing my certs to secure the connection from my server to their server.
I’m running nginx and ubuntu 16.04
thanks!
You can change the filesystem path that certbot uses by using the --webroot-path or -w flags, but you cannot change the URL path--before they'll issue you a cert using HTTP validation, the LE servers must be able to connect to http://domain/.well-known/acme-challenge/ and retrieve the token file. That path is hardcoded and will not change. If you can't make that work, investigate using DNS validation instead.
I’d expect that any CDN would pass the request onto the origin if it didn’t match the path it was expecting.
Do you mind naming the CDN? Is it Sucuri WAF by any chance?
Conceptually, the use of a specific path is meant to prevent people from getting certificates this way when they just have control over one directory on a site but aren’t the system administrator. For example, many sites allow customers or subscribers to post content under a certain subdirectory… you can see this on https://sites.google.com/, to take a popular contemporary example. We don’t want people to be able to say “please validate my challenge from https://sites.google.com/site/randomuser/acme-challenge” and thereby get a Let’s Encrypt certificate for sites.google.com. The /.well-known prefix is meant to mean “content placed here has a special meaning to software”, and so most sites won’t allow anybody except the system administrator to post files there. As a result, the use of /.well-known for this purpose has been fixed by Internet standards and, to some extent, by the CA industry.
no, not sucuri…bit mitigate.
can DNS challenges be fully automated yet in ubuntu 16.04?
I took a look at a few domains using Bitmitigate. It seems like they need to take advantage of try_files in their handling of /.well-known/acme-challenge/ requests.
If you haven’t tried already, it might help to provide feedback asking them to fix it. I doubt you’re the first person to run into this problem. For some reason all the infosec products seem to have this problem.
DNS challenge support will depend on who your host your DNS with.
Of course they can, though you may want to use an alternate client to do so. The OS you're running the client on isn't nearly as important as your DNS host.
I'm currently using cloudflare for DNS.
I don’t remember if the CloudFlare DNS plugin is available in the OS-packaged Certbot on your OS. If not, your easiest path might be using the acme.sh client.
Nope. 
It's available starting in 18.04.
I suppose I should try to get bit mitigate to fix this issue on their side of things. if others are using let’s encrypt with their system, I’m sure they’ll likely run into this issue as well.
Then you should be in good shape with acme.sh rather than certbot.
just tried out acme.sh, seems to work very well!
it looks like it automatically adds a line to crontab to try to renew the cert. will it email me if it runs into any errors and/or if the cert is expiring like certbot and certbot-auto did? I didn’t use my email address when registering the new cert.
also, I suppose I should also remove certbot and certbot-auto from the system?
thanks for the help!
I believe acme.sh registers without an email address by default; you can set one afterwards by running:
acme.sh --update-account --accountemail youremail@example.com
There are occasionally other important notifications besides the renewal reminders so this is definitely worth doing even if you're confident that automated renewals are working correctly.
You can, but you don't have to. If you have any certs that you obtained with certbot that you no longer want it to try to auto-renew, you can just delete the corresponding files from /etc/letsencrypt/renewal/.
thank you. when running the update-account command, it told me my email address is already registered, which is true as it's the same email I use when I was using certbot to issue certs. I assume this is ok for acme.sh as well?
also, what's the proper way to update the following command so it restart nginx & postfix when certs are renewed?
acme.sh --install-cert -d yourdomain.tld --ecc
--cert-file /etc/nginx/acme.sh/yourdomain.tld/cert.pem
--key-file /etc/nginx/acme.sh/yourdomain.tld/key.pem
--fullchain-file /etc/nginx/acme.sh/yourdomain.tld/fullchain.pem
--reloadcmd "systemctl reload nginx.service"
I believe what it means is that an account was already registered. acme.sh registers an account for its own use, even if you've already registered another one with certbot. It's fine to use the same email for both.
I believe you can supply multiple reload commands separated by semicolons:
acme.sh --install-cert -d yourdomain.tld --ecc --cert-file /etc/nginx/acme.sh/yourdomain.tld/cert.pem --key-file /etc/nginx/acme.sh/yourdomain.tld/key.pem --fullchain-file /etc/nginx/acme.sh/yourdomain.tld/fullchain.pem --reloadcmd "systemctl reload nginx.service; systemctl reload postfix.service"
Or you could put them in a shell script and supply that as your reload command.
thanks!
another dumb question - how can I verify that my cert is indeed a wildcard cert?
acme.sh --list should give you a list of certs you’ve obtained with acme.sh and the domain names they cover. If one or more of the names begins with *. then it’s a wildcard cert.
You can also inspect the cert in your browser and look for a wildcard name under “subjectAltName”.
perfect, thank you!!!