I am trying to obtain an SSL certificate with certbot and the --webroot setting. My current command is:
sudo certbot certonly --webroot -w <path> -d <URL> -d <*.URL>
Every time I run the command I get this error:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
I tried every similar command I found. Please share some help.
I am using ubuntu 18 with the newest certbot version. I also tried certbot-auto
I figured it out: with the http verification (webroot) it is not possible to obtain wildcards (<*.url>).
But it is possible with a DNS challenge (Reference).
Here is an example command for a manual / DNS challenge wildcard certifiat request:
sudo certbot certonly --manual -d *.<domain> -d <domain> --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 --server acme-v02.api.letsencrypt.org/directory
I want to provide some further reading on this for anyone else struggling - and I'll explain why every solution still didn't work!
Great advice from Letsencrypt ...
https://community.letsencrypt.org/t/client-with-the-currently-selected-authenticator-an-authenticator-script-must-be-provided-when/153921
https://letsencrypt.org/docs/challenge-types/ - see DNS-01. Basically Certbot has to connect with your DNS provider/api to create temporary records to verify your domain.
BUT ... not all providers allow this ...
https://community.letsencrypt.org/t/dns-providers-who-easily-integrate-with-lets-encrypt-dns-validation/86438
And it turns out mine (Namecheap) doesn't. So in short Wildcards + Certbot + Namecheap are not physically possible!
Related
According to the official ACME.SH documentation link, issuing a certificate is as simple as running the following command:
$ acme.sh --issue --alpn -d example.com
However, I am getting the following error
Error, can not get domain token entry example.com for `tls-alpn-01`
The supported validation types are `http-01` `dns-01` , but you specified: `tls-alpn-01`
I have tried switching from the default ZeroSSL.com to BuyPass.com, but that does not help. It seems that these providers do not allow tls-alpn-01 validation method, but it could be related to something that I am missing.
PS:
To preemptively answer some questions:
I have a valid domain that I replaced with "example.com"
The site is functional on a 443 port, but port 80 is blocked by ISP, hence tls-alpn-01
I am stopping Nginx, and then checking with netstat that port 443 is not bound to a service.
When I run the script with --debug 2 parameter, I get the following value for _authorizations_map variable
_authorizations_map='example.com,{"identifier":{"type":"dns","value":"example.com"},"status":"pending","expires":"2021-08-18T22:53:50Z","challenges":[{"type":"http-01","url":"https://acme.zerossl.com/v2/DV90/chall/wYehJ8kQjUDiDadBJ12qKw", "status":"pending","token":"Sfga2N2KwV-2hg3wo1gYAoyFvqV87dRvG2sHw4I6ups"},{"type":"dns-01","url":"https://acme.zerossl.com/v2/DV90/chall/CkrMQdEJthf-TmWvllW-Bg", "status":"pending","token":"_AlgMGzIfSQs7673Su-njnpieba_zLpSYxiUdXDEFnz"}]}'
Same problem, I switched from ZeroSSL to Let's encrypt CA and now it works without problems.
https://community.letsencrypt.org/t/the-acme-sh-will-change-default-ca-to-zerossl-on-august-1st-2021/144052
Edit: oops, sorry.
To tell acme.sh to use Let's encrypt CA
use:
acme.sh --set-default-ca --server letsencrypt
and then try to issue again the certificate in tls-alpn-01 mode
I'm stuck on how to fix this SSL error --
My SSL certs work fine on Chrome, but in Safari and Firefox I get an error that there is a host name mismatch if I go to www.domain.com instead of just domain.com
I've set up SSL Certificates using Certbot for my domain for both domain.com and www.domain.com
When I check on nginx to make sure that the certificates exist, I run sudo certbot --nginx, then select both of the domains when asked Which names would you like to activate https for?, and for both domain.com and www.domain.com, I get the result "You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry" and asks if I'd like to attempt to reinstall or renew and replace the cert.
I'm not sure what other steps I can take, as last time I installed certbot I simply followed the instructions, did the above for both www and non-www addresses, and it simply worked at both www and non-www!
Does anyone have any suggestions what to do next?
TLDR:
domain.com: works fine in firefox/safari, nginx says cert exists
www.domain.com: host name mismatch in firefox/safari, nginx says cert exists
why?!
After messing with it for a while, and trying #xyz's ssl checker I figured out the following things:
both certs were valid
When I re-installed the certs using certbot, the most recent cert would start working and the previous one would stop working
Turned out that i needed to add the other url as a subdomain to the existing cert and that fixed it!
I used:
sudo certbot -d domain.com -d www.domain.com
and that did the trick
You can check both domains from an external service, e.g. here:
https://www.sslshopper.com/ssl-checker.html
It will tell you if the certificate is correctly installed on both.
You should also open a new tab in Chrome, open developer tools, record network requests, then goto www.domain.com and see what redirects Chrome makes and what URL's it actually makes requests to. Maybe it has some automatic URL changing based on previously successfully resolved URL's.
My domain is: https://www.neasy.de
I ran this command:
git clone https://github.com/certbot/certbot
cd certbot
./certbot-auto certonly -a standalone -d neasy.de -d www.neasy.de
cd /etc/letsencrypt/live/neasy.de
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out keystore.p12 -name tomcat -CAfile chain.pem -caname root
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version): linux
My hosting provider, if applicable, is:
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):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):certbot 0.31.0
4 month ago i first used letsencrypt and I was success to use it. I learned I have to generate certificate
with and without www. prefix and it is important. My company has changed the domain name from neasy.app to neasy.de and for that I deleted my old certificate and generate new one for neasy.de
Now i am in a new trouble that if i write in my browser neasy.de it does not work even if i write www.neasy.de it does not work. But for at least once time if I write https://neasy.de or https://www.neasy.de it works, and for the next time i dont need to write https:// prefix.
This issue really seems weird to me any help will be appreciated. If you already tried writting https://neasy.de then you can open firefox browser private window
Since you're using Ubuntu please follow this guide:
https://certbot.eff.org/lets-encrypt/ubuntuxenial-apache.html (jus make sure to choose your ubuntu release from the dropdown).
this will guide you through the whole process without manual work.
Just make sure to run all apt-related commands.
Was there a route for the old domain neasy.app which was redirecting the http traffic to https ? It looks like you forgot to update that route with the new domain name.
Usually when you enter any new website in the address bar of browser it by default uses http protocol. On the server site you have to do a 301 redirect from http to https.
I have to renew Let's Encrypt certificates on my Debian server. By some reason the renew option doesn't works, and nor the certbot-auto script.
This below command works, but asking some questions:
sudo certbot --server https://acme-v02.api.letsencrypt.org/directory -d *.blogginger.com --manual --preferred-challenges dns-01 certonly
Questions while I'm running this command:
Would you like to redirect HTTP to HTTPS? I choose here option 1
Are you OK with your IP being logged?
and press Enter at the end.
How can I skip these questions? Which parameters should I use with certbot?
Thank you!
The solution was this below command to renew all certificate on the server, included the mentioned certificate as well:
sudo certbot renew
I insert this command in crontab for never forget to renew any certificates:
0 4 * * 0 sudo certbot renew
It will send a request at every early morning of Sunday.
Hide standard output and show only errors by addig "-q" parameter:
sudo certbot renew -q
It seems like letsencrypt have forgotten the options used when generating the certs originally.
If you manually run just certbot, with only the least possible options, and when asked, select the "don't alter apache config" option, I think the options will be saved for next run of certbot-auto renew
I have a working setup where Let's Encrypt certificates are generated with certbot. I wonder how you effectively test whether the renewal will work in production.
The certificates last for 90 days. Is there a way to reduce the lifespan to, for instance, 10 minutes, to see if the renewal works? (Using the staging system for that is fine.)
If you have an alternative approach how to make sure that your renewal code works (without having to wait for 90 days), it would also be appreciated.
You use the --dry-run option. E.g.:
$ sudo certbot renew --dry-run
From certbot -h:
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
...
--dry-run Test "renew" or "certonly" without saving any certificates
to disk
This ensures that the certbot can validate your domain with your current configuration.
If you really want to save the certificates to disk and see if your system is using the new cert, then you can also use the --force-renewal option. In that case, you should visit your website and check that the active certificate is the new one. If it isn't, you likely need to adjust your cronjob to restart your web server. E.g.:
certbot renew && service apache24 restart
You can use "certbot renew --force-renewal"
https://certbot.eff.org/docs/using.html#configuration-file
--force-renewal, --renew-by-default
If a certificate already exists for the requested
domains, renew it now, regardless of whether it is
near expiry. (Often --keep-until-expiring is more
appropriate). Also implies --expand. (default: False)