Let's encrypt: Unterschied zwischen den Versionen
Matt (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Matt (Diskussion | Beiträge) |
||
(12 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 2: | Zeile 2: | ||
Diese Anleitung bezieht sich auf den Certbot-Client. | Diese Anleitung bezieht sich auf den Certbot-Client. | ||
== Certbot == | == Certbot == | ||
Anleitung siehe: https://certbot.eff.org/ | Anleitung siehe: https://certbot.eff.org/ | ||
=== Installation === | === Installation === | ||
Package für Debian: | Package für Debian: | ||
apt-get install python-certbot-apache -t jessie-backports | apt-get install python-certbot-apache -t jessie-backports | ||
Das Paket installiert auch einen Cronjob, der täglich die Aktualisierung ausführt, die Zertifikate aber nur dann tatsächlich aktualisiert, wenn ein bestimmtes Zeitfenster erreicht ist. Das Zeitfenster wird definiert in den Conf-Dateien in: | Das Paket installiert auch einen Cronjob, der täglich die Aktualisierung ausführt, die Zertifikate aber nur dann tatsächlich aktualisiert, wenn ein bestimmtes Zeitfenster erreicht ist. Das Zeitfenster wird definiert in den Conf-Dateien in: | ||
/etc/letsencrypt/renew/ | /etc/letsencrypt/renew/ | ||
Zertifikate erstellen inkl. Anpassung der Apache Konfig-Dateien: | |||
Zertifikate erstellen inkl. Anpassung der Apache Konfig-Dateien unter verwendung des Apache-Plugins: | |||
# certbot --apache | # certbot --apache | ||
Alternativ certbot gleich auf bestimmte Domains festlegen: | Alternativ certbot gleich auf bestimmte Domains festlegen: | ||
# certbot --apache -d domain1.tld -d domain2.tld | # certbot --apache -d domain1.tld -d domain2.tld | ||
Für Webroot-Validierung ohne Installer: | |||
# certbot certonly --webroot -w /var/www/example -d www.example.com -d example.com -w /var/www/other | |||
Webroot Validierung mit Installer (ungetestet): | |||
# certbot certonly --installer --webroot -w /var/www/example -d www.example.com -d example.com -w /var/www/other | |||
Zertifikate erstellen ohne Anpassung der Apache Konfig-Dateien (die *.pem-Files müssen dann manuell in die Apache-Conf-Files eingefügt werden): | Zertifikate erstellen ohne Anpassung der Apache Konfig-Dateien (die *.pem-Files müssen dann manuell in die Apache-Conf-Files eingefügt werden): | ||
# certbot | |||
# certbot certonly | |||
=== Zertifikate aktualisieren === | === Zertifikate aktualisieren === | ||
Zeile 21: | Zeile 41: | ||
# certbot renew # non-interaktiv erneuern aller Zertifikate | # certbot renew # non-interaktiv erneuern aller Zertifikate | ||
# certbot --renew certonly # veraltet (?) | # certbot --renew certonly # veraltet (?) | ||
=== Weitere Domains hinzufügen === | |||
Dies ist nicht möglich. Aber man kann eine neue Registrierung mit einer neuen Liste von Domains durchführen: | |||
# certbot --apache -d olddomain1.tld,olddomain2.tld,newsubdomain.newdomain.tld | |||
Wichtig: Vorher die Domains verfügbar machen und den Server entsprechend einrichten. | |||
=== Tricks === | === Tricks === | ||
* Um den Namen der Verzeichnisse in /etc/letsencrypt zu steuern am besten: | * Um den Namen der Verzeichnisse in /etc/letsencrypt zu steuern am besten: | ||
** Zunächst die Hauptdomain mit Zertifikat erstellen | ** Zunächst die Hauptdomain mit Zertifikat erstellen | ||
** Danach mögliche Subdomains hinzufügen durch erneuten Aufruf von Certbot und Auswahl der weiteren Domains | ** Danach mögliche Subdomains hinzufügen durch erneuten Aufruf von Certbot und Auswahl der weiteren Domains | ||
** Man kann auch ohne Konfiguration des Apache-Servers (ServerName und SSL-Konfiguration) den Certbot ausführen. Dieser fragt dann ServerName ab und legt eine SSL-Konfiguration selbst an. | ** Man kann auch ohne Konfiguration des Apache-Servers (ServerName und SSL-Konfiguration) den Certbot ausführen. Dieser fragt dann ServerName ab und legt eine SSL-Konfiguration selbst an. | ||
=== Validation-Challenge-Methoden === | |||
{| class="wikitable" | |||
|+ style="text-align: left" | Challenge-Typen | |||
! Plugin !! Challenge-Typ und Port | |||
|- | |||
| Apache || tls-sni-01 (443) | |||
|- | |||
| Webroot || http-01 (80) | |||
|- | |||
| nginx || tls-sni-01 (443) | |||
|- | |||
| standalone || http-01 (80) oder tls-sni-01 (443) | |||
|- | |||
| DNS plugins || dns-01 (53) | |||
|- | |||
| manual || http-01 (80), dns-01 (53) oder tls-sni-01 (443) | |||
|} | |||
Wenn ein Plugin mehrere Methoden nutzen kann, dann wird mit dem Parameter <code>--preferred-challenges</code> ausgewählt, welcher Challenge-Typ verwendet werden soll. | |||
Die Ausgewählte Methode wird in Datei <code>/etc/letsencrypt/renewal/<domain>.conf</code> im Parameter <code>authenticator</code> im Abschnitt <code>[renewalparams]</code> gespeichert. | |||
Quelle: https://certbot.eff.org/docs/using.html#getting-certificates-and-choosing-plugins | |||
==== Apache ==== | |||
todo | |||
==== Webroot ==== | |||
Dabei wird im angegebenen Webroot-Verzeichnis ein verstecktes Unterverzeichnis <code>.well-known</code> angelegt, in dem eine Datei abgelegt wird, die der Validierung dient. | |||
Nutzung des Webroot Plugins und der http-01-Validierung: | |||
certbot certonly --webroot -w /var/www/example -d www.example.com -d example.com -w /var/www/other -d other.example.net -d another.other.example.net | |||
Parameter <code>certonly</code> sollte verwendet werden. Sagt zumindest der certbot. | |||
Falls man z.B. eine automatische Installation haben möchte, muss man bei Webroot-Validierung den Parameter <code>--installer</code> verwenden. | |||
==== Nginx ==== | |||
todo | |||
==== Standalone ==== | |||
todo | |||
==== DNS plugin ==== | |||
todo | |||
==== Manual ==== | |||
ungetestet: | |||
certbot --manual --preferred-challenges http -w /var/www/example -d www.example.com -d example.com -w /var/www/other -d other.example.net -d another.other.example.net | |||
== Server Hardening == | == Server Hardening == | ||
Vergleiche Artikel über [[Server Hardening (Debian)]]. | Vergleiche Artikel über [[Server Hardening (Debian)]]. | ||
Zeile 34: | Zeile 123: | ||
=== Installation === | === Installation === | ||
Bei der Erstregistrierung einer Domain mit Certbot wird ein Account bei Lets Encrypt angelegt. | Bei der Erstregistrierung einer Domain mit Certbot wird ein Account bei Lets Encrypt angelegt. | ||
Zeile 43: | Zeile 133: | ||
=== Änderung der E-Mailadresse === | === Änderung der E-Mailadresse === | ||
Deprecated: | |||
certbot register --update-registration --email yourname+1@example.com | certbot register --update-registration --email yourname+1@example.com | ||
Aktuell: | |||
cerbot update_account [options] | |||
D.h. so? | |||
cerbot update_account -m yourname+1@example.com | |||
=== Abmeldung einer E-Mailadresse === | === Abmeldung einer E-Mailadresse === | ||
In Expiration-E-Mails ist am Ende ein Abmelden-Link, mit dem man sich aus dem Mailverteiler entfernen kann. | In Expiration-E-Mails ist am Ende ein Abmelden-Link, mit dem man sich aus dem Mailverteiler entfernen kann. | ||
[[ | |||
== Proxy-Domains == | |||
Wenn ein Server über einen Virtual Host mit Proxy in Apache eingebunden wird, kann dieser Virtual Host die DNS-Challenge von Let's Encrypt nicht erfolgreich erfüllen. | |||
Für die Challenge in Letsencrypt ist Zugriff auf die Domainhinhalte notwendig. | |||
Als Lösung kann die Webroot-Challenge genutzt werden. Hierfür muss Letsencrypt auf Webinhalte unter <code>.well-known/acme-challange</code> zugreifen. | |||
Für die Webroot-Challenge müssen die Unterverzeichnisse <code>.well-known/acme-challange</code> explizit vom Proxy ausgeschlossen werden. | |||
Die ProxyPass-Parameter werden in der Reihenfolge in der Konfig-Datei geladen. Daher werden darin folgende Zeilen eingefügt: | |||
ProxyPass /.well-known/acme-challenge ! | |||
Alias /.well-known/acme-challenge /var/www/html/.well-known/acme-challenge | |||
<Directory "/var/www/html/.well-known/acme-challenge"> | |||
Options None | |||
AllowOverride None | |||
Require all granted | |||
AddDefaultCharset off | |||
</Directory> | |||
Der ProxyPass-Parameter mit einem Ausrufe-Zeichen am Ende beschreibt ein Verzeichnis, welches nicht per Proxy an das Proxy-Ziel weiter geleitet wird. | |||
Der Alias-Parameter erzeugt ein Verzeichnis im Webserver, und leitet diesen an den angegebenen Pfad weiter. | |||
Quellen: | |||
* https://certbot.eff.org/docs/using.html#webroot | |||
* https://blog.rimuhosting.com/2018/07/05/certbot-letsencrypt-apache-and-tomcat/ | |||
* https://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass | |||
[[Category:Linux]] | |||
[[Kategorie:Kryptographie]] | [[Kategorie:Kryptographie]] |
Aktuelle Version vom 30. September 2020, 12:56 Uhr
Anleitung, um Zertifikate mit einem der Let's Encrypt Clients zu erstellen oder zu aktualisieren.
Diese Anleitung bezieht sich auf den Certbot-Client.
Certbot
Anleitung siehe: https://certbot.eff.org/
Installation
Package für Debian:
apt-get install python-certbot-apache -t jessie-backports
Das Paket installiert auch einen Cronjob, der täglich die Aktualisierung ausführt, die Zertifikate aber nur dann tatsächlich aktualisiert, wenn ein bestimmtes Zeitfenster erreicht ist. Das Zeitfenster wird definiert in den Conf-Dateien in:
/etc/letsencrypt/renew/
Zertifikate erstellen inkl. Anpassung der Apache Konfig-Dateien unter verwendung des Apache-Plugins:
# certbot --apache
Alternativ certbot gleich auf bestimmte Domains festlegen:
# certbot --apache -d domain1.tld -d domain2.tld
Für Webroot-Validierung ohne Installer:
# certbot certonly --webroot -w /var/www/example -d www.example.com -d example.com -w /var/www/other
Webroot Validierung mit Installer (ungetestet):
# certbot certonly --installer --webroot -w /var/www/example -d www.example.com -d example.com -w /var/www/other
Zertifikate erstellen ohne Anpassung der Apache Konfig-Dateien (die *.pem-Files müssen dann manuell in die Apache-Conf-Files eingefügt werden):
# certbot certonly
Zertifikate aktualisieren
# certbot renew # non-interaktiv erneuern aller Zertifikate # certbot --renew certonly # veraltet (?)
Weitere Domains hinzufügen
Dies ist nicht möglich. Aber man kann eine neue Registrierung mit einer neuen Liste von Domains durchführen:
# certbot --apache -d olddomain1.tld,olddomain2.tld,newsubdomain.newdomain.tld
Wichtig: Vorher die Domains verfügbar machen und den Server entsprechend einrichten.
Tricks
- Um den Namen der Verzeichnisse in /etc/letsencrypt zu steuern am besten:
- Zunächst die Hauptdomain mit Zertifikat erstellen
- Danach mögliche Subdomains hinzufügen durch erneuten Aufruf von Certbot und Auswahl der weiteren Domains
- Man kann auch ohne Konfiguration des Apache-Servers (ServerName und SSL-Konfiguration) den Certbot ausführen. Dieser fragt dann ServerName ab und legt eine SSL-Konfiguration selbst an.
Validation-Challenge-Methoden
Plugin | Challenge-Typ und Port |
---|---|
Apache | tls-sni-01 (443) |
Webroot | http-01 (80) |
nginx | tls-sni-01 (443) |
standalone | http-01 (80) oder tls-sni-01 (443) |
DNS plugins | dns-01 (53) |
manual | http-01 (80), dns-01 (53) oder tls-sni-01 (443) |
Wenn ein Plugin mehrere Methoden nutzen kann, dann wird mit dem Parameter --preferred-challenges
ausgewählt, welcher Challenge-Typ verwendet werden soll.
Die Ausgewählte Methode wird in Datei /etc/letsencrypt/renewal/<domain>.conf
im Parameter authenticator
im Abschnitt [renewalparams]
gespeichert.
Quelle: https://certbot.eff.org/docs/using.html#getting-certificates-and-choosing-plugins
Apache
todo
Webroot
Dabei wird im angegebenen Webroot-Verzeichnis ein verstecktes Unterverzeichnis .well-known
angelegt, in dem eine Datei abgelegt wird, die der Validierung dient.
Nutzung des Webroot Plugins und der http-01-Validierung:
certbot certonly --webroot -w /var/www/example -d www.example.com -d example.com -w /var/www/other -d other.example.net -d another.other.example.net
Parameter certonly
sollte verwendet werden. Sagt zumindest der certbot.
Falls man z.B. eine automatische Installation haben möchte, muss man bei Webroot-Validierung den Parameter --installer
verwenden.
Nginx
todo
Standalone
todo
DNS plugin
todo
Manual
ungetestet:
certbot --manual --preferred-challenges http -w /var/www/example -d www.example.com -d example.com -w /var/www/other -d other.example.net -d another.other.example.net
Server Hardening
Vergleiche Artikel über Server Hardening (Debian).
Expiration-E-Mails
Installation
Bei der Erstregistrierung einer Domain mit Certbot wird ein Account bei Lets Encrypt angelegt.
Der Dialogassistenten fragt daraufhin automatisch eine E-Mailadresse ab.
Diese ist für Notfallkommunikation betreffend des Accounts und für Expiration E-Mails benutzt.
Details siehe https://letsencrypt.org/docs/expiration-emails/
Änderung der E-Mailadresse
Deprecated:
certbot register --update-registration --email yourname+1@example.com
Aktuell:
cerbot update_account [options]
D.h. so?
cerbot update_account -m yourname+1@example.com
Abmeldung einer E-Mailadresse
In Expiration-E-Mails ist am Ende ein Abmelden-Link, mit dem man sich aus dem Mailverteiler entfernen kann.
Proxy-Domains
Wenn ein Server über einen Virtual Host mit Proxy in Apache eingebunden wird, kann dieser Virtual Host die DNS-Challenge von Let's Encrypt nicht erfolgreich erfüllen.
Für die Challenge in Letsencrypt ist Zugriff auf die Domainhinhalte notwendig.
Als Lösung kann die Webroot-Challenge genutzt werden. Hierfür muss Letsencrypt auf Webinhalte unter .well-known/acme-challange
zugreifen.
Für die Webroot-Challenge müssen die Unterverzeichnisse .well-known/acme-challange
explizit vom Proxy ausgeschlossen werden.
Die ProxyPass-Parameter werden in der Reihenfolge in der Konfig-Datei geladen. Daher werden darin folgende Zeilen eingefügt:
ProxyPass /.well-known/acme-challenge ! Alias /.well-known/acme-challenge /var/www/html/.well-known/acme-challenge <Directory "/var/www/html/.well-known/acme-challenge"> Options None AllowOverride None Require all granted AddDefaultCharset off </Directory>
Der ProxyPass-Parameter mit einem Ausrufe-Zeichen am Ende beschreibt ein Verzeichnis, welches nicht per Proxy an das Proxy-Ziel weiter geleitet wird.
Der Alias-Parameter erzeugt ein Verzeichnis im Webserver, und leitet diesen an den angegebenen Pfad weiter.
Quellen: