Talk:Certbot

From ArchWiki
(Redirected from Talk:Let's Encrypt)
Latest comment: 15 April 2022 by Seven.issimo in topic Automatic Renewal

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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 the certbot 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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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 ~~~~!Reply[reply]

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)Reply[reply]

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)Reply[reply]


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)Reply[reply]

--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)Reply[reply]