Setting up the ACME ID
Validation is performed with External Account Binding
(EAB).
To do this, you must first log in to the IT portal with your
personal digital ID (https://xsso.uni-muenster.de/IT-Portal/)
and set up an ACME ID there under “Digital ID
(certificate)” | “New ACME ID;” for the fully
qualified domain names (FQDNs) to be included in the future
certificates. (The list of FQDNs of an ACME ID can be changed later in
the IT portal).
This provides key data in the form of an EAB key ID and an EAB HMAC
key, which are required for registering the server.
Installation of the software
The EPEL repository contains the CertBot software, this can be
installed with:
yum install certbot
Registration of the CertBot
To register the server with the ACME service, the following command
must be entered once. This contains the key ID and HMAC key for
external account binding as well as the email address to be informed
in case of problems:
certbot register --server 'server-url'
--eab-kid 'key-id' --eab-hmac-key 'hmac-key'
--email 'email-address' --agree-tos
--no-eff-email
With:
key-id = the (shorter) key ID displayed
by the IT portal
hmac-key = the (shorter) HMAC key
displayed by the IT portal
email-address = the email address to
which the CertBot sends its information
After successful registration, the key ID and HMAC key are deleted
from the ACME server and can no longer be used.
However, if an ACME ID is to be used on multiple servers, the
CertBot directory /etc/letsencrypt can be copied to the
additional servers.
Generate certificate
In order to actually request a certificate via ACME, collect it,
install it and restart the certified service at the same time, the
following command is used:
certbot certonly --standalone --agree-tos --server
'server-url' --domain fqdn1,fqdn2,... --cert-name
'certname' --email='email-address' --deploy-hook
'systemctl restart servicename'
With:
fqdn1,fqdn2,... = the fully qualified
computer names (FQDNs) under which the service is found; these FQDNs
must have been specified in the IT portal for the ACME ID; the
FQDN specified first is also included in the subject of the
certificate, the others only in the subject alternative names
certname = the freely choosable file
name (without path) of the certificate
email-address = the email address to
which the CertBot sends its information
servicename = the name under which the
service is managed by the system daemon
This command places all required files in the
/etc/letsencrypt/archive/certname/ directory
tree and ensures that the following symbolic links always point to the
currently active files:
/etc/letsencrypt/live/certname/privkey.pem
/etc/letsencrypt/live/certname/cert.pem
/etc/letsencrypt/live/certname/chain.pem
/etc/letsencrypt/live/certname/fullchain.pem
The service should of course be configured to use exactly these
symbolic links to access the files and to restart with the command
specified with --deploy-hook.
Instead of using these paths, CertBot could also be automatically
built into services (e.g. with --apache or
--nginx instead of --standalone), but this
requires plugins.
Access permissions to the certificate files
CertBot stores the certificate files, especially the private key,
with access rights only for the root user (0700). So that applications
that do not run as root but under a different identifier are also
allowed to read these certificates, the corresponding read rights must
be set.
setfacl -R -m u:username:rX
/etc/letsencrypt/{live,archive}/certname
setfacl -m u:username:rX
/etc/letsencrypt/{live,archive}
setfacl -m d:u:username:rX
/etc/letsencrypt/{live,archive}/certname
With:
You should definitely check if the identifier can actually read the
generated private keys, for example with:
getfacl
/etc/letsencrypt/archive/certname/priv*
If necessary, the ACL mask in above commands must be adjusted.
You should not edit the access rights with chown,
chgrp or chmod, because this will be changed
or complained about by CertBot.
A completely different approach would be to specify a script in the
--deploy-hook option of the above certbot
command that copies the file to another location, sets the permissions
of these copies correctly with +chmod, and then restarts
the server. Then, of course, the server must be configured to use these
copies and not the original files.
Enable automatic certificate renewal
For this purpose only the certbot-renew timer has to be started:
systemctl enable certbot-renew.timer
systemctl start certbot-renew.timer
All generated and deposited certificates are then automatically
renewed before expiry.
