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

• Kommando: certbot-auto

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
• –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

• 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“

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.