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)
Related
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!
I have issue with the cert manager which prevents me from synchronizing the robot with the cloud cluster.
It seems that it is due to a certificate error some way I can solve it.
the logs of cert manager:
1 controller.go:200] cert-manager/controller/orders "msg"="re-queuing item due to error processing" "error"="error creating new order: acme: urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates already issued for exact set of domains: www.endpoints.guminator.cloud.goog: see https://letsencrypt.org/docs/rate-limits/" "key"="default/cloud-robotics-2181866887"
This is hitting the "Duplicate Certificate limit of 5 per week" mentioned at https://letsencrypt.org/docs/rate-limits/. https://tools.letsdebug.net/cert-search?m=domain&q=www.endpoints.guminator.cloud.goog&d=168 shows when the certificates were created.
For a short-term resolution: I'd hope it will start working again in the next days, since the first certificates were issued on the 12th.
For a long-term resolution: Have you done anything that would cause this, for example deleting and recreating the cluster multiple times? If you need to do this regularly, you have two options:
Back up the certificate
https://cert-manager.readthedocs.io/en/release-0.9/tasks/backup-restore-crds.html suggests the following approach for backing up and restoring the configuration:
kubectl get -o yaml \
issuer,clusterissuer,certificates,orders,challenges > cert-manager-backup.yaml
kubectl get -o yaml secret letsencrypt-prod > cert-manager-secret-backup.yaml
Then, to restore after recreating the cluster:
kubectl apply -f cert-manager-secret-backup.yaml
Caveat: I have not tested this approach.
Use the Staging environment
https://letsencrypt.org/docs/staging-environment/ states that the staging environment allows 30,000 duplicate certs per week. You'd need to:
edit src/app_charts/base/cloud/cert-manager-issuers.yaml to refer to https://acme-staging-v02.api.letsencrypt.org/directory
configure the clients to trust the staging CA: https://letsencrypt.org/certs/fakeleintermediatex1.pem
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 some security certificates setup on multiple domain variants for my website. I have been following this guide on Bitnami:
https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#step-5-renew-the-lets-encrypt-certificate
I managed to create the certificates, but am now trying to renew them with this command:
sudo lego --email="name#email.com" --domains="mydomain.com" --domains="www.mydomain.com" --domains="mydomain.co.uk" --domains="www.mydomain.co.uk" --domains="mydomain.technology" --domains="www.mydomain.technology" --path="/etc/lego” renew
When I run this it just hangs. I get nothing back. Any ideas?