Talk:Certbot
RFC: elegant method for webroot
on the interwebs i found an interesting idea for multi domain setups. the idea is to serve all /.well-know/acme-challenge requests to one central place (e.g. /var/lib/letsencrypt) where the clients can put the challenge files to. a nginx config for this (e.g. in ssl.conf, so it is included everywhere ssl is used) can look like this:
location /.well-known/acme-challenge { alias /var/lib/letsencrypt; default_type "text/plain"; try_files $uri =404; }
this is an elegant solution especially for webapps on (sub)domains, as their filesystem locations are not littered with .well-known folders. still i lack an idea how to integrate this into the existing article, hence the post here. opinions? Fordprefect (talk) 22:09, 21 March 2016 (UTC)
Retroactive implementation
This will only work if you also set the webroot of the certificate as /var/lib/letsencrypt.
To use this with certificates which already exist you must either update the configuration files in /etc/letsencrypt/renewal, or use the following ExecStart command in certbot.service:
ExecStart=/usr/bin/certbot renew --quiet --agree-tos -w /var/lib/letsencrypt
Suggestion for preexisting complex VHosts
This assumes:
- You want https redirect for everything except letsencrypt challenges.
- Certbot with webroot set to /var/lib/letsencrypt.
- You want to make it all subdomains and even requests to IPs available to your certbot. (There is no ServerName directive.)
- You don't want to use the certbot-apache plugin. (Because it doesn't work with your weird config / OCD / Compartmentalization).
- You don't care about acme-challenges being accessible via https. Which is not required for LetsEncrypt. Some weird setups might require that. In that case add the extra location to a 443 Vhost.
Put this before all other Vhosts in your Apache config:
<VirtualHost *:80> DocumentRoot "/srv/http" RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} <Location /.well-known/acme-challenge/ > RewriteEngine Off </Location> Alias /.well-known/acme-challenge/ "/var/lib/letsencrypt/.well-known/acme-challenge/" <Directory "/var/lib/letsencrypt/"> AllowOverride None Options MultiViews SymLinksIfOwnerMatch IncludesNoExec Require method GET POST OPTIONS </Directory> </VirtualHost>
—This unsigned comment is by Lasagne (talk) 18:34, 21 September 2023. Please sign your posts with ~~~~!
DNS method should be mentioned as well as UCC certs
I use DNS as the validation method as I have appliances where I can't modify webroot but use a single UCC certificate for simplicity. Should probably add this. I don't use certbot, rather acme.sh, but I can switch and take a stab at it in a couple of weeks. Any interest in alternates as well, or just wanting to stick to the official client? DJ L (talk) 08:02, 20 November 2016 (UTC)
certbot-apache
Is it still true that certbot-apache still doesn't work in Arch? If not, can't the maintainer patch it to make it work? If not, why is it a package in Arch? Greyltc (talk)
It has worked for me: (quick notes, full write up later after some testing):
- Enable SSL on Apache
- Create self signed cert in /etc/httpd - openssl req -x509 -new -out server.crt -keyout server.key -nodes -days 3650
- Enable SSL modules in httpd.conf
- Enable mod_rewrite (for http -> https redirection)
- Include /conf/extra/httpd-ssl.conf
- Symlink /usr/bin/apachectl to /usr/bin/apache2ctl
- Use the suggested Include conf/extra/httpd-acme.conf from this page
- Get cert:
certbot --test-cert --agree-tos --email user@example.co.uk --apache -w /srv/http/ -d server.example.co.uk --apache-server-root /etc/httpd --apache-vhost-root /etc/httpd/conf/extra/ --apache-challenge-location /etc/httpd/
Gerdesj (talk) 13:02, 8 June 2017 (UTC)
accuracy flag
When I follow the steps the article, I am getting errors relating to the validation step. I suspect the author has omitted some key steps or details. Graysky (talk) 09:07, 12 August 2017 (UTC)
- If you're following the #Webroot method you already need to have a separate webserver running. You then point to the root directory that it is serving with the
-w
flag in thecertbot certonly
command. - Maybe it's clearer from this revision. The article has been complicated a lot recently, which I don't think is a good thing.
- If you're still getting errors, post them here. Lonaowna (talk) 10:18, 12 August 2017 (UTC)
Wiki Misses the DNS A Record Requirement
The #Webroot Manual method works fine for apache, but the wiki doesn't explain well that all of the steps mentioned above the Manual method related to including httpd-acme.conf, etc.. apply OR that you must have an A Record for your exact server name listed with your domain provider that matches the host.domain.tld you are attempting to get a certificate for.
Also, since the Manual method uses Port 80 (http) for the challenge response, you do not need https enable when you request your certificate. Once you have successfully been issues a certificate, and with httpd-ssl.conf edited per the wiki, simply enable https after you have your certificate and all will be fine.
With those additions, I find the Manual method quick, easy and bullet-proof for obtaining the certificate, and then renewal is as simple as certbot renew. David C. Rankin, J.D.,P.E. -- Rankin Law Firm, PLLC (talk) 21:36, 4 June 2020 (UTC)
- I don't understand what you mean by the
httpd-acme.conf
inclusion thing. - The wiki does not say that HTTPS is needed. There are some hints how to do certificate renewal when HTTPS is enabled - which is often the main purpose of the certificate.
- -- Lahwaacz (talk) 07:21, 5 June 2020 (UTC)
Automatic Renewal
Why is it recommended to renew certs twice a day? Certs are good for 90 days per official FAQ[1]. Isn't this just putting unnecessary load on Let's Encrypt, or am I missing something? X-san
- I don't think any action takes place until a threshold is reached for the number of days left, but still, twice a day is unnecessary I think Kewl (talk) 10:06, 17 December 2017 (UTC)
This will make sure that should the renewal fail, certbot will have plenty of opportunities to try again. NieDzejkob (talk) 00:45, 1 November 2018 (UTC)
I disagree with this approach; the service should handle retry-on-failure with the systemd options (Restart/StartLimit) and not simply attempt to renew every half-day... User:sauyon (talk) 11:36, 24 June 2019 (UTC)
I disagree too : Let's Encrypt is a free but essential service, we should not put such a stress ont their servers. I chand it for once a month with mail alert, like explained on the systemd timers page. Phigger (talk) 14:12, 4 March 2020 (UTC)
The renew command is smart enough not to create useless load on the Let's Encrypt servers, so running it more frequently only impacts the machine running the command. Nze (talk) 09:56, 1 April 2021 (UTC)
Source: https://certbot.eff.org/docs/using.html#renewal
Since renew only renews certificates that are near expiry it can be run as frequently as you want - since it will usually take no action.
The Certbot package on Arch comes with systemd service and timer. Instructions are out-of-date about manual creation of systemd service and timer. [2]
—This unsigned comment is by Seven.issimo (talk) 13:23, 15 April 2022 (UTC). Please sign your posts with ~~~~!
cerbot, official?
cerbot is a recommended easy to start with client but I don't think it is the "official" client, any information about this? Kewl (talk) 10:07, 17 December 2017 (UTC)
- From Certbot - About: Certbot was developed by EFF and others as a client for Let’s Encrypt and was previously known as “the official Let’s Encrypt client” or “the Let’s Encrypt Python client.”
- Let's Encrypt still recommends Certbot: "We recommend that most people with shell access use the Certbot ACME client."
- "Official" is a vague term. Maybe "recommended" is better but I'm not sure if it really matters. Lonaowna (talk) 10:35, 17 December 2017 (UTC)
Let's Encrypt and DANE (DNSSEC)
Using DANE (DNSSEC) with Let's Encrypt can be a difficult/dangerous task as LE certs refresh every 90 days and DANE hashes need to be updated, too. I found a lengthy post which uses a script to automate the process. Unfortunately, it is written in Russian language. Maybe a native speaker can pick it up to add such a section here or in DANE. t.ask (talk) 13:52, 18 December 2017 (UTC)
--post-hook documentation
In the Automatic Renewal section of the Arch Linux document, standard setup (non-wildcard), there is a tip
--post-hook "systemctl reload nginx.service"
to run a command after the renew is complete. According to the certbot documentation, the --post-hook
will run each time the renew is attempted whether it actually renews or not. If you need to restart your webserver, it may not be desirable unless it is necessary to do so.
The certbot documentation recommends to use --deploy-hook
to run a command if and only if the certificate is actually renewed.
When Certbot detects that a certificate is due for renewal, --pre-hook and --post-hook hooks run before and after each attempt to renew it. If you want your hook to run only after a successful renewal, use --deploy-hook in a command like this.
certbot renew --deploy-hook /path/to/deploy-hook-script
Trames (talk) 22:48, 8 April 2021 (UTC)
Placement of key block for rfc2136 bind configuration
The example given on the certbot Wiki page (Section: Configure BIND for rfc2136) shows the key block included in the zone file. I could not get this to work for bind 9.18.27-1. Entered more or less exactly as shown on the page, when I restart the named service, I get:
May 27 15:47:42 toad named[95854]: /etc/named/named.conf.local:14: unknown option 'key'
May 27 15:47:42 toad named[95854]: loading configuration: failure
May 27 15:47:42 toad named[95854]: exiting (due to fatal error)
If I move the key block as is to /etc/named.conf at the top level, then it just works. Not sure what's going on here, but I invested a considerable amount of time trying to debug this, so am wondering if this is worth a mention on the Wiki page? Pgoetz (talk) 21:14, 27 May 2024 (UTC)
- That's how it is there: the
key "example-key"
block is at the top level. — Lahwaacz (talk) 12:46, 28 May 2024 (UTC)