ssl-Zertifikate für Domains mit getssl und letsencrypt

[TS]

Hello,

Zu lange schon steht die Aufgabe auf meinem Zettel. Ich muss für diverse Domains auf einem shared Host SSL-Zertifikate einrichten und komme damit nicht klar.

Ich habe mit getssl begonnen und dies mittels der Anleitung im github unter versucht zu verstehen. Es sind aber zuviele Fragen offen.

Bei den meisten Domains sollen auch die Subdomains mit erledigt werden. Kann man da später noch welche nachtragen, oder muss man dann ein neues Zertifikat erstellen lassen?

Müssen die ACME-Challenge-Locations per http/s erreichbar sein? In der Anleitung wird der Begriff "Website-Folder" benutzt für die ".well-known" Domains(?):
where "/path/to/your/website/folder/" is the path, on your web server, to the web root for your domain.
Ist damit die Document-Root gemeint? Ich verstehe unter "Web Root" bisher immer das der Domain zugeordnete Verzeichnis, in dem dann erst diverse NICHT von außen zugängliche Verzeichnisse, sowie die Document-Root liegen.

Sind leider nicht die einzigen Fragen. Die weiteren ergeben sich dann erst.

Ich will mir keine Löcher in das System reißen. Sprich: ich habe nicht den Mut, hier einfach "Versuch und Irrtum" zu spielen.

Hat vielleicht jemand Zeit, das mit mir durchzugehen und ich schreib es dann gleich mal inklusive meiner dämlichen Fragen und der (hoffentlich) richtigen Antworten auf für einen Feature-Artikel?

Liebe Grüße
Tom S.

[Christian Kruse]

Hallo TS,

Bei den meisten Domains sollen auch die Subdomains mit erledigt werden. Kann man da später noch welche nachtragen, oder muss man dann ein neues Zertifikat erstellen lassen?

Du musst ein neues Zertifikat erstellen lassen.

Da aber Let's Encrypt-Zertifikate nur eine Laufzeit von drei Monaten haben, ist es eh so vorgesehen, dass das automatisiert wird, niemand will sich alle drei Monate um Zertifikate kümmern müssen. Du musst also einfach nur die neue Subdomain hinzufügen und den Cronjob von Hand ausführen, um das Zertifikat upzudaten.

Müssen die ACME-Challenge-Locations per http/s erreichbar sein?

Die müssen per HTTP erreichbar sein, ja. Das ist ein Challenge-Response-Verfahren, du bekommst eine Challenge über das Protokoll und musst über HTTP oder DNS die Response erzeugen.

In der Anleitung wird der Begriff "Website-Folder" benutzt für die ".well-known" Domains(?):
where "/path/to/your/website/folder/" is the path, on your web server, to the web root for your domain.
Ist damit die Document-Root gemeint?

Damit ist der document root gemeint, ja.

Ich verstehe unter "Web Root" bisher immer das der Domain zugeordnete Verzeichnis, in dem dann erst diverse NICHT von außen zugängliche Verzeichnisse, sowie die Document-Root liegen.

Nein, web root und document root sind im allgemeinen Sprachgebrauch äquivalent.

LG,
CK

[Erik K.]

Hallo Tom,

ich setze getssl aufgrund seiner Einfachheit und fast nicht vorhandenen Abhängigkeiten sehr gerne ein und das auf mehreren Linux-Servern.

Ja, für neue Subdomains musst du ein neues Zertifikat beantragen bzw. die Konfig (siehe unten) ändern und das Zertifikat neu beantragen.

Du kannst mehrere (Sub-)Domains in ein Zertifikat eintragen, aber diese Liste ist öffentlich einsehbar und jede Domain wird bei einer Aktualisierung (spätestens alle 3 Monate) neu geprüft. Wenn sich also häufiger mal was ändert, erstelle für jede Domain besser ein eigenes Zertifikat.

Wildcard geht übrigens nicht, auch keine IP-Zertifikate.

Ich nehme mal an, dass du Apache einsetzt und bisher noch keine ssl-vhosts hast. Dann wäre der Weg für die allererste Domain wie folgt:

Hast du schon das SSL-Modul vom Apache aktiviert? Wenn nicht:

a2enmod ssl

Zuerst musst du entscheiden, wo getssl die Challenge mit den LE-Servern aushandeln soll.

Da gibt es grundsätzlich 2 Möglichkeiten:

1. du gibts getssl hier ein Verzeichnis für alle Domains (Schreib- & Leserechte Webserver nicht vergessen) und trägst das hier ein.

2. du legst für jede Webseite ein eigenes Verzeichnis an (Schreib- & Leserechte Webserver nicht vergessen) und musst das bei jeden Zertifikat individuell hier aufgrund des DODUMENT_ROOT hinterlegen.

Meine best-practise Empfehlung: Nr. 1 (weil: einmal einstellen und es läuft dann für jede Domain ohne Anpassung)

Wenn Du Nr. 1 haben möchtest, brauchst du noch diese Konfigerweiterung beim Apachen: Solltest du noch Apache 2.2. haben, musst du die "allow from all" Anweisungen noch eintragen und "Require all granted" löschen.

Alias /.well-known /var/www/html/letsencrypt/.well-known
<Directory /var/www/html/letsencrypt/.well-known>
  Require all granted
  AllowOverride None
  Options -Indexes
</Directory>

Jetzt das Verzeichnis anlegen - die Verzeichnisrechte musst du selber anpassen:

mkdir -p /var/www/html/letsencrypt/.well-known/acme-challenge
chown -R www-data.www-data /var/www/html/letsencrypt/

... und Webserver neu starten.

Ok, nach dieser Grundsatz-Entscheidung gehts los:

Du kopierst den vhost für die erste Domain und änderst folgende Zeilen:

von: <VirtualHost *:80>

zu: <VirtualHost *:443>

Schau dir an, was in ServerName und ServerAlias steht - das brauchst du gleich noch. Notiere dir es vielleicht am besten in einer einfachen Textdatei (notepad, kwrite, oder so).

Danach folgen diese Zeilen - in ##DOMAIN## setzt du ein, was im ServerName steht (auch weiter unten):

  SSLEngine on
  SSLCertificateFile /etc/apache2/certs/##DOMAIN##.crt
  SSLCertificateKeyFile /etc/apache2/certs/##DOMAIN##.key
  SSLCertificateChainFile /etc/apache2/certs/##DOMAIN##.inter

Ok, Datei speichern & schließen. Wenn du eine extra-Datei dafür angefangen hast, aktiviere diese neue Site:

a2ensite neuer-dateiname

Lade dir jetzt getssl runter:

curl --silent https://raw.githubusercontent.com/srvrco/getssl/master/getssl > /usr/local/sbin/getssl ; chmod 700 /usr/local/sbin/getssl

... und bereite das Zertifikat vor:

getssl -c ##DOMAIN##

Du bekommst eine Ausgabe, in der die neu angelegten Konfig-Dateien genannt werden.

Öffne /root/.getssl/getssl.cfg

Zeile 5 ein # an den Anfang setzen.

Zeile 7 sollte so aussehen:

CA="https://acme-v01.api.letsencrypt.org"

Zeile 12ff sollten so aussehen:

ACCOUNT_EMAIL="##email-adresse-fuer-benachrichtigung-eingeben##"
ACCOUNT_KEY_LENGTH=4096
ACCOUNT_KEY="/root/.getssl/account.key"

Zeile 19:

RELOAD_CMD="/usr/sbin/apache2ctl -t && /etc/init.d/apache2 restart"

In Zeile 22 steht eine Zahl. Wenn ein Zertifikat nur noch diese Anzahl an Tagen gültig ist, soll es erneuert werden. Da LE-Zertifikate nur 3 Monate gültig sind, sollte die Zahl hier nicht zu groß sein. Aber auch nicht zu klein (wegen Urlaub, Feiertagen, etc).

RENEW_ALLOW="5"

Datei speichern & Schließen.

Öffne Datei /root/.getssl/##DOMAIN##/getssl.cfg

In Zeile 14 trägst du alles ein, was in ServerAlias steht, z.B.: Wichtig: Hier nur öffentlich existierende (Sub-)Domains.

SANS="subdomain.expample.org"

In Zeile 28 trägst du ein, wo getssl die Challenge mit den LE-Servern aushandeln soll.

ACL=('/var/www/html/letsencrypt/.well-known/acme-challenge')

Zeile 36ff:

DOMAIN_CERT_LOCATION=/etc/apache2/certs/##DOMAIN##.crt
DOMAIN_KEY_LOCATION=/etc/apache2/certs/##DOMAIN##.key
CA_CERT_LOCATION=/etc/apache2/certs/##DOMAIN##.inter

Datei speichern & schließen.

Fast fertig. Jetzt das Zertifikat bei LE beantragen:

getssl ##DOMAIN##

Wenn es Fehler beim Abruf gab, musst du prüfen, ob die Schreibrechte des ACL-Verzeichnisses stimmen.

Die Datei wird angegeben. Wenn du sie selber nicht aufrufen kannst (nur im Fehlerfall, getssl löscht sie eigenständig, wenn alles ok war), stimmen die Schreibrechte des ACL-Verzeichnisses wahrscheinlich nicht.

Ansonsten melde dich hier mal mit der ganzen Fehlermeldung.

Wenn alles geklappt hat, startet dein Webserver neu und du kannst die Domain per https erreichen.

Wenn https für diese Domain klappt, kannst du darüber nachdenken, per PermanentRewrite oder einer rewrite-Rule alles von http nach https umzuleiten, z.B.:

      RewriteEngine on
      RewriteCond %{SERVER_PORT} !^443
      RewriteRule ^(.*)$         https://##DOMAIN##/$1 [L,R=301]

Jetzt noch den Cronjob einrichten (siehe offizielle Anleitung), damit die Verlängerung der Zertifikate auch klappt.

[TS]

Hello Erik, hallo Christian,

vielen Dank für die Antworten und Eriks ausführliche Anleitung.
Ich kämpfe mich da jetzt durch.
Ich habe noch Apache/2.2.22. Könnte ich auch mal upgraden (nicht wechseln :-P).

Und ich hatte bereits SSL/TLS aktiviert. Das ging mit dem damaligen Cert-Anbieter aber nur für eine Domain pro IP. Das Zertifikat war ja nun schon eine Weile abgelaufen. Das war aber dafür noch etwas leichter Verständlich, weil kein Autoupdate und kein Challenge-Response eingerichtet wurde.

Schaun wir also mal, ob ich es heute noch hinbekomme.

Für das gemeinssame ACL-Verzeichnis [Habe ich auch erst gestutzt, was "Access Control Lists" nun mit SSL/TLS zu haben sollten, aber kein ausschließliches Recht auf Abkürzungen. Das verwirrt dann aber. "ACME Chellenge Location" passt dann schon besser ;-)] hatte ich bei Thomas Leister schon etwas gefunden.

Ich habe also Hoffnung, das es klappt.

Liebe Grüße
Tom S.

[Christian Kruse]

Hallo TS,

Und ich hatte bereits SSL/TLS aktiviert. Das ging mit dem damaligen Cert-Anbieter aber nur für eine Domain pro IP.

Ich denke nicht, dass das stimmt. SNI ist keine Frage des Zertifikats, sondern ob Server und Client das unterstützen. Und Apache unterstützt es seit Ewigkeiten (seit 2.2 mindestens). Ein Problem war lange Zeit der IE, der unter Windows XP das prinzipiell nicht unterstützt hat.

LG,
CK

[TS]

Hello,

Und ich hatte bereits SSL/TLS aktiviert. Das ging mit dem damaligen Cert-Anbieter aber nur für eine Domain pro IP.

Ich denke nicht, dass das stimmt. SNI ist keine Frage des Zertifikats, sondern ob Server und Client das unterstützen. Und Apache unterstützt es seit Ewigkeiten (seit 2.2 mindestens). Ein Problem war lange Zeit der IE, der unter Windows XP das prinzipiell nicht unterstützt hat.

Der Zertifizierer hatte pro Account nur ein kostenloses Zertifikat zugelassen.

Gleich noch eine Frage: Was hat es mit den *.pem-Files auf sich? Da habe ich plötzlich ganz viele im Verzeichnis /etc/ssl/certs/ liegen. Hat der Hoster wohl eingespielt. Aber wofür brauche ich davon 519 Stück? Ich hatte einst nur einen dort stehen.

Liebe Grüße
Tom S.

[Erik K.]

Hallo,

in /etc/ssl/certs/ liegen die (Zwischen-)Zertifikate, anhand derer z.b: wget, lynx, curl, etc. (auf einem Server) die Gültigkeit eines Zertifikates erkennen können.

Sprich: mit diesen Zertifikaten wird die Zertifikats-Kette geprüft (Vertrauenswürdigkeit).

Die Installation ist eigentlich Aufgabe des Server-Admins (von Varianten wie uberspace mal abgesehen), wird aber meist als Abhängigkeit installiert, wenn man Zertifikate erstellen will. Bei welchem Hoster bist du denn?

Grüße

[TS]

Hello,

Die Installation ist eigentlich Aufgabe des Server-Admins (von Varianten wie uberspace mal abgesehen), wird aber meist als Abhängigkeit installiert, wenn man Zertifikate erstellen will. Bei welchem Hoster bist du denn?

Vautron.

Die haben die Sym-Links wohl neulich mal gesetzt, als etwas repariert werden musste.
Das meiste auf dem Server habe ich selber gemacht. Aber bevor ich nicht weiß, wie sich was wo warum auswirkt, lasse ich es lieber weg. Was nicht drauf ist, kann keine Seiteneffekte erzeugen. Die Files liegen in /usr/share/ca-certificates/mozilla/ und ich vermute, dass die jemand auch dort (mozilla) bezogen hat.

Liebe Grüße
Tom S.

[Erik K.]

Hallo Tom,

gern geschehen.

Apache 2.2? Das klingt nach Debian 7, ist das richtig?

Mit Debian 8 kommt Apache 2.4 und dabei ändert sich einiges: Upgrade

Debian 9 steht an (wahrscheinlich Herbst), ein Upgrade klingt also sinnvoll ;-)

Grüße

[TS]

Hello,

Apache 2.2? Das klingt nach Debian 7, ist das richtig?

Stimmt.

Mit Debian 8 kommt Apache 2.4 und dabei ändert sich einiges: Upgrade

Debian 9 steht an (wahrscheinlich Herbst), ein Upgrade klingt also sinnvoll ;-)

Dann wird es wenigstens nicht langweilig :-)

Liebe Grüße
Tom S.

[TS]

Hello Erik,

hab endlich Zeit gehabt, die ersten Zertifikate (erfolgeich) einzurichten.

In meiner alten Konfiguration (mit dem abgelaufenen Zertifikat) hatte ich noch stehen

#       SSLProtocol all -SSLv2
#       SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

Wofür war das genau gedacht?
Da mir Firefox mit dem neuen Zertifikat auf der Domain (ohne diese Zeilen) TLS v1.2 meldet, nehme ich an, dass das überholt ist?

Liebe Grüße
Tom S.

[Auge]

Hallo

#       SSLProtocol all -SSLv2
#       SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

Wofür war das genau gedacht?

Zumindest SSLv2 und RC4 sagen, dass du bisher mit völlig veralteten Methoden ^[1][2] unterwegs warst.

Da mir Firefox mit dem neuen Zertifikat auf der Domain (ohne diese Zeilen) TLS v1.2 meldet, nehme ich an, dass das überholt ist?

Die oben genannten Verfahren sind sowas von überholt! Über den Rest kann ich dir allerdings nichts erhellendes sagen.

Tschö, Auge

---

1. SSL 2.0: Seit 2011 "deprecated (prohibited)" durch RFC 6176. (Hervorhebung durch mich) ↩︎

2. Im Februar 2015 wurde mit RFC 7465 der Einsatz von RC4 im Rahmen von TLS verboten, da es erhebliche Sicherheitsmängel aufweist. (Hervorhebung durch mich) ↩︎

[TS]

Hello,

#       SSLProtocol all -SSLv2
#       SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

Wofür war das genau gedacht?

Zumindest SSLv2 und RC4 sagen, dass du bisher mit völlig veralteten Methoden [^1][^2] unterwegs warst.

Ups
Das hatte ich auch angenommen.
Ist mit den Domains vom alten Hoster mit zum neuen übernommen worden (so vor 4-5 Jahren) und es hat sich keiner darum gekümmert, weil es (eigentlich) auch keiner gebraucht hat. Jetzt hab ich das an der Backe.

Da mir Firefox mit dem neuen Zertifikat auf der Domain (ohne diese Zeilen) TLS v1.2 meldet, nehme ich an, dass das überholt ist?

Die oben genannten Verfahren sind sowas von überholt! Über den Rest kann ich dir allerdings nichts erhellendes sagen.

Ich werde da mal weiterforschen. ;-)

Liebe Grüße
Tom S.

[TS]

Hello,

#       SSLProtocol all -SSLv2
#       SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

Wofür war das genau gedacht?

Ich hatte es vergessen. Aber aus der mod_ssl-Einrichtung geht es hervor.

SSLProtocol all -SSLv2 bedeutet, dass alle Protokolle außer SSLv2 erlaubt sind.

Aber ob ich noch eine Cipher-Suite angeben muss, habe ich noch nicht gefunden.

Liebe Grüße
Tom S.

[Erik K.]

Hallo Tom,

ja, "Cipher-Suite angeben" ist sinnvoll.

Hier kannst du abhängig von deinen installierten Versionen eine gute Config erstellen lassen. Deine Software-Versionen musst du natürlich noch ermitteln und eintragen.

Und danach bitte bei SSL-Labs testen.

Grüße

[TS]

Hello,

ja, "Cipher-Suite angeben" ist sinnvoll.

Hier kannst du abhängig von deinen installierten Versionen eine gute Config erstellen lassen. Deine Software-Versionen musst du natürlich noch ermitteln und eintragen.

Ok!?
Wie lege ich den HSTS Header fest?
Ist das nur ein "AddHeader ???" in der virt-Host-Einrichtung?

Und danach bitte bei SSL-Labs testen.

Also doch noch nicht Feierabend ;-)

Liebe Grüße
Tom S.

[Erik K.]

Hallo,

ja, eigentlich braucht es dazu nur "AddHeader" und das richtige Modul (headers). Was hast du erwartet? Wenn du die richtigen Software-Versionen eingetragen hast, sollte der Konfigurator doch auch was zu HSTS angeben, auch bei Debian 7 ;-)

Grüße

[TS]

Hello,

Da ist es wieder, das alte Problem:

Reloading web server config: apache2[Wed May 10 16:39:10 2017] [warn] _default_ VirtualHost overlap on port 443, the first has precedence

Der Apache 2.2 will doch kein TLS für name based Hosts. Das hatte ich allerdings im Web anders gelesen.
Upgraden auf 2.4 kann ich noch nicht.
Was tun? Fehlt mir ein Modul?

Liebe Grüße
Tom S.

[Christian Kruse]

Hallo TS,

Reloading web server config: apache2[Wed May 10 16:39:10 2017] [warn] _default_ VirtualHost overlap on port 443, the first has precedence

Der Apache 2.2 will doch kein TLS für name based Hosts.

Nein, er warnt dich, dass der _default_-Vhost mehrfach definiert wurde. Name-based VHosts gehen auch mit 2.2 über SSL (dank SNI).

LG,
CK

[TS]

Hello,

Reloading web server config: apache2[Wed May 10 16:39:10 2017] [warn] _default_ VirtualHost overlap on port 443, the first has precedence

Der Apache 2.2 will doch kein TLS für name based Hosts.

Nein, er warnt dich, dass der _default_-Vhost mehrfach definiert wurde. Name-based VHosts gehen auch mit 2.2 über SSL (dank SNI).

Das hatte ich ja vorher überprüft und war deshalb jetzt schon wieder leicht frustiert. Ich habe auf diesem Host noch Apache 2.2.24 laufen.

Musste zwar noch eine Weile grübeln, weil das eigentlich genau anders herum bemängelt wird, als man es dann vermutet:

Die Vereinbarung

NameVirtualHost *:443

hat gefehlt, weil bisher nur ein einziger Virt Host auf Port 443 lief. Ich hatte ja berichtet, dass der alte Zertifizierer nur IP-basierte Zertifikate ausgestellt hatte.

Da die Konfiguration bei Apache auf Debian ja nahezu atomisiert (oder "atomarisiert"?) ist, steht das dann irgendwo (hier in sites-available), ist aber erstmal nicht "enabled". Ich hatte also gar keinen definierten default für Port 443.

Liebe Grüße
Tom S.

[Erik K.]

Hallo Tom,

der default-port wird eigentlich auch in /etc/apache2/ports.conf fest gelegt (Listen ...)

Grüße

[TS]

Hello,

die Fragen nehmen kein Ende.

Jetzt habe ich eine Domain dazwischen, bei der der beim https-Zugriff immer das Zertifikat auf der Startseite bemängelt wird. Ich bin da für die Zertifikate genauso vorgegangen, wie bei den anderen Domains.

Wenn man aber eine der beiden vorhandenen Unterseiten aufruft, wird das Zertifikat nicht bemängelt.

Ich finde den Fehler nicht.

Bei einer anderen Domain hatte ich den Effekt auch kurz, aber da waren noch hartkodierte URLs drin für Sekundärrequests (also z. B. hhtp://images/...). Nachdem ich die beseitigt hatte, wurde auch das Zertifikat nicht mehr bemängelt. Bei dieser Domain finde ich aber nichts dergleichen mehr...

Liebe Grüße
Tom S.

[Erik K.]

Hallo Tom,

du meinst mit "bemängelt" die mixed-Content-Warnung im Browser.

Auf der Startseite ist ein Bild fest per http eingebunden (ab Zeile 171). Lass dir den Quelltext anzeigen und suche nach "http:" (ohne "), dann findest du den Störenfried. Diese Methode funktioniert fast immer.

Wenn per JS Dinge per http nachgeladen werden, wirst du mit der Entwicklerkonsole (Firefox: Taste F12) fündig.

Grüße

[Erik K.]

Ah, offenbar hast du es gerade selber gefunden ;-)

[TS]

Hello,

Ah, offenbar hast du es gerade selber gefunden ;-)

Ja, danke.

Aber das ist eine Kettenreaktion bei dieser Domainsammlung. Die Mitglieder unserer Arbeitsgemeinschaft haben soviele tolle Ideen, aber dann werden die Seiten doch nicht fertig. Und alleine ist mir das zu viel.

Ich stelle jetzt erstmal alle auf https um.

Liebe Grüße
Tom S.

[TS]

Hello Erik,

du meinst mit "bemängelt" die mixed-Content-Warnung im Browser.

Auf der Startseite ist ein Bild fest per http eingebunden (ab Zeile 171). Lass dir den Quelltext anzeigen und suche nach "http:" (ohne "), dann findest du den Störenfried. Diese Methode funktioniert fast immer.

Wenn per JS Dinge per http nachgeladen werden, wirst du mit der Entwicklerkonsole (Firefox: Taste F12) fündig.

Es war wohl schon zu spät gestern. Ich war schon blind :-O
Mit der Konsole habe ich es eben auch gefunden. Habe ich bestimmt dreißig Mal dran vorbeigeschaut vorher. Bei den anderen betroffenen Seiten hatte ich das ja auch schon repariert...

Danke für deine Mühe.

Liebe Grüße
Tom S.