• Zertifikate sind 90 Tage gültig
• Anmeldung, Bezug und Erneuerung erfolgt über eine Client-Software die das ACME-Protokoll kann
• es gibt keine Wildcard-Zertifikate
• mehrere Domains/Sub-Domains in einem Zertifikat möglich
• relativ große Limits wie viele Zertifikate zu einem Zeitpunkt ausgestellt werden können
• Certificate-Revocation-List wird von CA gepflegt

• aktuelle Schlüssel, Zertifikate usw. liegen unter /etc/letsencrypt/live/Domain
  • das sind symbolische Links auf die aktuell verwendeten Dateien unter /etc/letsencrypt/archive/Domain

• es gibt mehrere Clients die das ACME-Protokoll sprechen → Zertifikate von Lets Encrypt holen können
• verschiedene Clients können verschiedene Sachen
  • zum Beispiel Zertifikate direkt in der entsprechenden Software konfigurieren (Webserver, Mailserver usw.)

• Certbot-Auto ist für Systeme ohne Internetanbindung oder für Systeme für die es kein Certbot-Packet gibt gedacht
• Bezugsquelle und Installationsanleitung: https://certbot.eff.org/docs/install.html
  • Installation ist runterladen und ausführen
• Kommando: certbot-auto
• Handbuch: http://letsencrypt.readthedocs.io/en/latest/using.html#manual

Man muss sich einmalig bei Lets Encrypt anmelden.

Syntax:

certbot-auto register [-m Mail-Address für Notification]

Beispiel:

certbot-auto register -m encrypt@mydomain.de

Die Angabe von -m und der Mailadresse ist optional.

Zuerst muss man wählen ob man das Zertifikat nur herunterladen oder auch gleich in den Webserver installieren will:

• run → Lade herunter und Installiere im Webserver (konfiguriere Webserver so das er auf das Zertifikat verweist
  • habe ich noch nicht ausprobiert
• certonly
  • Lade nur das Zertifikat herunter

Um ein neues Zertifikat für eine Domain zu erhalten muss man sich als Inhaber der Domain ausweisen.
Es gibt mehrere Möglichkeiten das zu tun:

• --apache

  → Erledige das über das Apache-Plugin

  • habe ich noch nicht getestet

• --nginx

  → Erledige das über das Nginx-Plugin

  • habe ich noch nicht getestet

• --webroot

  • Es werden Dateien in das Webroot gelegt die dann durch Lets Encrypt abgerufen werden
  • die Angabe des Verzeichnisses erfolgt interaktiv
  • es muss natürlich das Webroot (Verzeichnis im Dateisystem) angegeben werden aus dem Standardmäßig, bei Aufruf der Domain für die man das Zertifikat erstellen will, gelesen wird

• interaktiv zuerst 1 drücken
• dann kommt Abfrage des Verzeichnisses → Webroot eingeben
• <Enter> drücken

• --standalone 

  • startet einen Webserver auf Port 443 (https) (der vermutlich einen Authentifizierungs-Token ausliefert)
  • bei Auflösung des Domain-Namen (für den das Zertifikat beantragt wird) muss der Webserver unter der IP in den der sich auflöst erreichbar sein

• --manual

  → Gedacht wenn man das Zertifikat für einen anderen Rechner abrufen will

  • noch nicht genutzt

Es gibt noch weitere 3-rd-Party Plugins die weitere Möglichkeiten bieten (Authentifizierung über andere Anwendungen wie Mailserver usw.) → siehe Handbuch

Die Option -d gibt an für welche Domain man das Zertifikat beziehen will (wenn mehrere angegeben werden landen die alle im gleichen Zertifikat).

Syntax:

./certbot-auto //Nur Zertifikat oder inkl. Installieren// --//Authentifizierungsmethode// -d //Domain(s)//

Beispiel:

./certbot-auto certonly --webroot -d example.com

Obiges Beispiel bezieht nur das Zertifikat (richtet es aber nicht ein) (certonly), die Authentifizierung erfolgt durch das (automatische → certbot macht das nach Angabe des Verzeichnisses) hinterlegen von Dateien im Webroot (wird abgefragt wo das ist) für die Domain „example.com“

• Conversations 1.16.2 meldet das Zertifikat als unbekannt

• Kann ohne Modifikation nicht auf die Zertifikate zugreifen weil es als eigener Benuzer prosody läuft und die Zertifikate nur „root“ zugänglich sind
• Lösung siehe unter „Troubleshooting“

• Bei der Installation von certbot über einen Packagemanager wird in der Regel auch ein Cron-Scrip für die Erneuerung der Zertifikate installiert

Im Fall von Debian sieht das so aus:

/usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Im Prinzip ist es certbot renew.
Renew setzt aber Voraus das es ein Plugin im Webserver nutzen kann um Authentifzierung und Installation der Zertifikate durchführen zu können und das bei der Erst-Installation des Zertifikats diese Methode genutzt wurde.

Um eine andere Authentifizierungsmethode zu nutzen um das Zertifikat zu erneuern kann der cron-Job diesen Befehl ausführen:

certbot certonly -n --<Methode> [Optional notwendige Optionen] -d <Domain> | grep 'Certificate not yet due' || systemctl restart <someservice>

• -n → Non-Interactive → Frage nicht den Benutzer nach Eingaben → alle notwendigen Eingaben müssen in Form von Parametern vorhanden sein

• --<Method>

  → Authentifizierungsmethode → z.B. webroot

• [Optional notwendige Optionen] → Die Optionen die notwendig sind damit certonly mit der gewählten Authentifizierungsmethode ohne Benutzerinteraktion arbeiten kann. Vorher auf der Kommandozeile manuell testen, die Option -n gibt aus welche Optionen ggf. nötig sind
• -d <Domain> → die Domain für die Aktion durchgeführt werden soll (ggf. mehrfach angeben wenn mehrere Domains)
• der Rest → certbot liefert als Return-Value immer 0 zurück, auch wenn es nichts geändert hat. D.h. auch wenn kein neues Zertifikat bezogen wurde würde ggf. ein daran hängender Dienst neugestartet. Das grep prüft ob das Zertifikat nicht erneuert wurde und nur wenn es nicht-nicht erneuert wurde (also erneuert wurde) wird der Dienst im Befehl nach || neugestartet

Beispiel:

certbot certonly -n --webroot -w /var/www/someforum/ -d forum.test.de | grep 'Certificate not yet due' || systemctl restart apache2.service

Obiges Beispiel erneuert das Zertifikat für Domain forum.test.de, mit Authentifizierungsmethode webroot, der Pfad um die Authentifizierungsdaten zu hinterlegen ist /var/www/someforum/ und wenn das Zertifikat erneuert wurde wird apache neugestartet.

Dienste die nicht als root laufen oder die Zertifikate nicht abfragen während sie noch als root laufen (einige Dienste starten als root und wechseln nach dem Start in den Kontext eines anderen Benutzers) können nicht auf die Zertifikate unter „/etc/letsencrypt/live/Domain“ zugreifen bzw. unter „/etc/letsencrypt/archive/Domain“ weil diese Verzeichnisse nur root zugänglich sind.

Lösung ist das Setzen der erweiterten Berechtigungen ACL für diese Verzeichnisse (gibt noch andere mögliche Wege) und setzen von Default-Berechtigungen für diese Verzeichnisse → dadurch bekommen neu erstellte Dateien (wichtig wenn die Zertifikate erneuert werden) automatisch die richtigen erweiterten Berechtigungen.

Erweiterte Berechtigungen setzen, auch für alle Unterverzeichnisse und Dateien (x ist notwendig um den Verzeichnisinhalt listen zu können):

Syntax:

setfacl -R  -m u:<Benutzer>:rx live
setfacl -R  -m u:<Benutzer>:rx archive

Beispiel:

setfacl -R  -m u:prosody:rx live
setfacl -R  -m u:prosody:rx archive 

Die oben beschriebenen Anweisungen setzen für alle Verzeichnisse und Dateien unterhalb von „live“ und „archive“ die Berechtigung lesen ® und Auflisten/Ausführen (x) für den Benutzer „prosody“ bzw. den einzutragenden Benutzer.

Setzen der Default-Berechtigungen (Kopieren der bestehenden Berechtigungen und setzen als Default): Syntax/Beispiel:

getfacl live | setfacl -R -d -M - live
getfacl archive | setfacl -R -d -M - archive

Das obige Beispiel holt sich die bestehenden Berechtigungen per getfacl für die Verzeichnisse „archive“ und „live“ und setzt sie über setfacl als Default-Berechtigung (Option -d) für alle untergeordneten Dateien und Verzeichnisse (-R).
Das bedeutet Dateien die in irgend einem der Unterverzeichnisse neu angelegt werden bekommen automatisch die Default-Berechtigungen als Berechtigungen gesetzt.
Das ist wichtig wenn die Zertifikate erneuert werden, da sie sonst nur die „normalen“ Standardrechte haben und andere Benutzer als root danach wieder keinen Zugriff haben.

Hinweis: Die Methode hat Nachteile. Für alle Verzeichnisse wird „x“ für den entsprechenden Benutzer gesetzt (Inhalt auflisten) und wegen der Rekursivität des Befehls (-R) auch für alle Dateien in dem Verzeichnis, was ausführen bedeutet. Es werden also Dateien ausführbar die nicht ausführbar sein brauchen. Außerdem bekommt der Benutzer lesenden Zugriff auf alle Zertifikate (wegen dem rekursiven Setzen der Berechtigung auf archive und live), auch auf die er keinen Zugriff braucht. Beides kann im schlimmsten Fall genutzt werden wenn es ein Angreifer schafft im Kontext des Dienstes (und damit mit dessen Rechten) eigenen Code auszuführen und reißt ein gewisses Loch in die Sicherheit die mit dem ausführen als anderer Nutzer (nicht root) aufgebaut wurde.

• Cron-Job nicht vorhanden
• Es wurde eine andere Authentifizierungsmethode als „–apache“ gewählt (aka. das erste Zertifikat für die Domain wurde nicht per certbot run bzw. nur certbot erstellt)
  • certbot renew - das ist der Befehl der durch das per Default installierte cron-Script genutzt wird, kann Zertifikate nur erneuern wenn es ein Plugin für den Webserver hat und darüber die Authentifizierung und Installation des Zertifikates machen kann
  • Lösung siehe Howto → Zertifikat ohne Plugin erneuern