Talk:Certbot

From ArchWiki
Jump to navigation Jump to search

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

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 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)

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)

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)

Add info about tsig-keygen

Shouldn't we add the fact that to use tsig-keygen one has to install ddnsAUR ? Aviallon (talk) 12:05, 20 March 2019 (UTC)

Nevermind, I was being blind... Aviallon (talk) 12:10, 20 March 2019 (UTC)

Why the usage of plugins is preferred?

However the usage of #Plugins may be the preferred since it allows automatic configuration and installation.

While plugins are automatic and convenient in theory, they may actually broke the configuration, they conflict with other configuration methods (e.g. Ansible), they may not work in some specific situations. I don't understand this recommendation. The Certbot#Webroot + nginx location /.well-known/acme-challenge/ should be preferred IMO; this is more obvious, controllable (e.g. by Ansible) and flexible. Are there any important plugin features I've missed that make them preferable to webroot? andreymal (talk) 12:36, 3 June 2019 (UTC)

The quoted sentence says "may be the preferred", not that it is the preferred. This leaves it up to the user's preference. -- Lahwaacz (talk) 21:39, 3 June 2019 (UTC)