Let's Encrypt questions

danb35 · 2018-01-03 14:57:47 UTC

NethServer Version: 7.4
Module: Let’s Encrypt

I’m pretty familiar with the use of Let’s Encrypt in SME, but the development there is on dehydrated (which I’d recommend you consider, along with acme.sh, rather than certbot–either of those is much more lightweight, and the extra features of certbot don’t seem to be at all necessary in this application). Seeing Let’s Encrypt integrated into the server manager is certainly nice, but it leaves a few questions:

It looks like the process to get a cert is to go to Server Certificates -> Request Let’s Encrypt certificate, enter the desired hostnames, and click the red button. Once obtained, set it as the default cert. Is that all there is to it?
It would then follow that, in order to add new hostnames/domains, you’d just repeat this process, adding whatever FQDNs you wanted to add?
Is the cert always going to be saved in the same location? It appears that the Let’s Encrypt cert, after being issued, is copied to /etc/pki/tls/certs/localhost.crt. Is it always going to be at that path?
Does issuing a Let’s Encrypt cert also schedule a task to renew it?

mrmarkuz · 2018-01-03 17:51:17 UTC

Yes, that’s it.

Exactly.

No, as far as I can see letsencrypt certs are saved to /etc/letsencrypt/live/DOMAIN/cert.pem. You can see it in web UI. A backup is made when requesting new cert.

Yes, there’s a cronjob /etc/cron.daily/nethserver-letsencrypt-certs.

Some more details:

github.com

NethServer/nethserver-letsencrypt/blob/master/root/usr/libexec/nethserver/letsencrypt-certs

#!/usr/bin/perl

use esmith::ConfigDB;
use esmith::HostsDB;
use File::stat;
use esmith::event;
use Getopt::Std;

my $cdb = esmith::ConfigDB->open();
my $ddb = esmith::HostsDB->open_ro();

my $crtdir = "/etc/letsencrypt/";
my $crtdir_backup = "/etc/letsencrypt.autobackup/";
my $lebin = "/usr/bin/certbot";
my $config = "";
my $verbose = 0;
my $testing = 0;
my $force = 0;
our $mail = '';
our $modified = 0;

This file has been truncated. show original

http://docs.nethserver.org/projects/nethserver-devel/en/v7/certificate_management.html#certificate-management

danb35 · 2018-01-03 18:09:35 UTC

Yes, that’s what’s shown in the web UI:

…but it isn’t what’s in /etc/httpd/conf.d/ssl.conf:
SSLCertificateFile /etc/pki/tls/certs/localhost.crt

/etc/httpd/conf.d/nethserver.conf shows the chain in /etc/letsencrypt/, but doesn’t give the cert or the key. Nothing in conf.d refers to the cert or key files in /etc/letsencrypt/.

mrmarkuz · 2018-01-03 19:01:11 UTC

You are right, seems the fullchain.pem from letsencrypt is just copied to /etc/pki/tls/certs/localhost.crt:

[root@server etc]# diff /etc/letsencrypt/live/mrmarkuz.goip.de/fullchain.pem /etc/pki/tls/certs/localhost.crt
56a57
>

danb35 · 2018-01-03 19:04:20 UTC

I think it should be using the files in /etc/letsencrypt/. After all, that’s where the config database says the files are:

But it isn’t, at least not consistently.

mrmarkuz · 2018-01-03 19:26:23 UTC

A copy of the files is used.
As far as I understand: By setting a certificate to default, the specific cert (as given in pki config) is copied and used. Another option would be to change the values in the httpd conf file.

giacomo · 2018-01-04 08:00:22 UTC

Markus is right, certificates must be copied for all daemons starting without root privileges.

NethServer 6 uses dehydrated but we faced a couple of issues after minor changes to the ACME protocol.
Dehydrated is an unofficial client and is not simple to maintain it for many years (we also need to build the rpm for it).

For NethServer 7 we switched to upstream certbot from epel and all this kind of problems have been disappeared