Let's Encrypt Dehydrated tut nicht wie's soll

Hallo,

ich denke, ich bin nun mit dem Wechsel auf Let’s Encrypt doch eine ganze Ecke weiter - nach dieser Anleitung:
https://www.21x9.org/de/letsencrypt-sh

Aber es tut halt noch nicht. Hier die gesamte Ausgabe von /usr/bin/dehydrated -c:

# INFO: Using main config file /etc/dehydrated/config
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
 + Creating chain cache directory /etc/dehydrated/chains
Processing subdomain1.unsereschule.de with alternative names: subdomain2.unsereschule.de subdomain3.unsereschule.de subdomain4.unsereschule.de subdomain5.unsereschule.de subdomain6.unsereschule.de
 + Creating new directory /etc/dehydrated/certs/subdomain1.unsereschule.de ...
” + Hook: Nothing to do…”
 + Signing domains...
 + Generating private key...
 + Generating signing request...
Can't load /root/.rnd into RNG
139993894310336:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd
 + Requesting new certificate order from CA...
 + Received 6 authorizations URLs from the CA
 + Handling authorization for subdomain3.unsereschule.de
 + Handling authorization for subdomain1.unsereschule.de
 + Handling authorization for subdomain6.unsereschule.de
 + Handling authorization for subdomain4.unsereschule.de
 + Handling authorization for subdomain5.unsereschule.de
 + Handling authorization for subdomain2.unsereschule.de
 + 6 pending challenge(s)
 + Deploying challenge tokens...
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
 + Responding to challenge for subdomain3.unsereschule.de authorization...
” + Hook: Nothing to do…”
 + Cleaning challenge tokens...
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
” + Hook: Nothing to do…”
 + Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:connection",
    "detail": "Fetching http://subdomain3.unsereschule.de/.well-known/acme-challenge/sic3-1R_CDeBIVELIApYRU9aMarBaA6lfPaddl6vYcU: Timeout during connect (likely firewall problem)",
    "status": 400
  },
  "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/2215137993/1KY6Iw",
  "token": "sic3-1R_CDeBIVELIApYRU9aMarBaA6lfPaddl6vYcU",
  "validationRecord": [
    {
      "url": "http://subdomain3.unsereschule.de/.well-known/acme-challenge/sic3-1R_CDeBIVELIApYRU9aMarBaA6lfPaddl6vYcU",
      "hostname": "subdomain3.unsereschule.de",
      "port": "80",
      "addressesResolved": [
        "80.144.30.190"
      ],
      "addressUsed": "80.144.30.190"
    }
  ]
})

Can’t load /root/.rnd into RNG
139993894310336:error:2406F079:random number generator:RAND_load_file:Cannot open file:…/crypto/rand/randfile.c:88:Filename=/root/.rnd

Dazu finde ich beim Googeln einen Bug. Die Frage ist, ob mir dieser bei der Funktonalität von Dehydrated in die Suppe spuckt - wahrscheinlich schon.

Das interpretiere ich so, dass - wie schon vermutet - doch Port 80 offen sein muss, zumindest als Weiterleitung auf 443.

Sieht jemand noch eine andere Baustelle oder interpretiere ich da was grundsätzlich falsch?

Viele Grüße
Steffen

Hallo,

zum Port 80:
Derzeit gibt’s in der Fritzbox nur eine Weiterleitung für 443 auf 443 an den Server.
Reicht es bereits aus, in der Fritzbox eine Weiterleitung von Port 80 auf 443 an den Server einzurichten, um den Server über Port 80 erreichbar zumachen?

Zumindest verstehe ich @jrichter so:

Viele Grüße
Steffen

Hallo Steffen,

  bei mir gab es 2 Probleme: das eine war ein Problem der

Namensauflösung (da man keinen Einfluss darauf hat, welchen
DNS-Server LetsEncrypt benutzt). Das hat mich ordentlich Nerven
gekostet, da man es nicht ohne weiteres nachvollziehen oder
reproduzieren kann. Manche DNS-Anbieter sind wohl - warum auch
immer - aus dem Ausland nicht zu erreichen…

  Das andere waren einfach Denkfehler, da ich ein wenig gebraucht

habe, die ganzen Mechanismen zumindest grob zu verstehen.

  Im Apache-Einstellungsverzeichnis (conf-available) legt

dehydrated eine Datei an - dort steht, worunter die
dehydrated-Dateien/acme-challenges erreichbar sind. Das muss halt
von außen gehen (kann man auch einfach testen).

  Unser Apache hört auf Port 80 auf die dehydrated-Dateien (der

Rest wird umgeleitet). Bei Dir erzeugt es einen Timeout -
vermutlich, weil Du eben Port 80 nicht weiterleitest.

  Also selbst, wenn Du sonst nichts auf Port 80 anbietest - die

ACME-Challenges, zumindest, wenn Du das ganze über HTTP machst,
sollten erreichbar sein (geht auch über Redirect, aber da muss man
aufpassen, dass das korrekt eingestellt ist).

  Es gibt auch andere Möglichkeiten als http-01, aber ich finde das

an sich recht logisch und es funktioniert - einmal eingerichtet -
auch problemlos.

Viele Grüße
Thomas

Hallo Thomas,

Da wurde nichts angelegt (habe das Debian Paket von dehydrated installiert).
Nach dieser Anleitung Home | 21x9.org | System Administration | Home Automation | Smart Home habe ich dann /etc/apache2/conf.d/letsencrypt angelegt:

Alias /.well-known/acme-challenge /var/www/letsencrypt/
Options None
AllowOverride None
Order allow,deny
Allow from all

Das Verzeichnis /var/www/letsencrypt/ ist von extern erreichbar, eine index.html im Verzeichnis liefert „It works“. Das sollte hoffentlich passen.

Allerdings steht da ansonsten schlicht nichts drin, was von extern erreichbar sein könnte.
Imho sollte dehydated doch da auch was reinschreiben, das dann von extern abgerufen werden kann?!?

Ok. Wie erreiche ich, dass die ACME-Challenges per http über Port 80 erreichbar sind, bei allem anderen aber Port 80 auf 443 umgeleitet wird?

Momentan habe ich für jede der geplanten Subdomains einen virtuellen Host für *:443

Momentan ist das Verzeichnis für die ACME-Challenges erreichbar über https://subdomain1.unsereschule.de/letsencrypt

Vermutlich brauche ich je noch einen virtuellen Host für *:80, in dem die Weiterleitung auf 443 drin steht?
Dann wird aber http://subdomain1.unsereschule.de/letsencrypt ebenfalls auf 443 umgeleitet.

Fetching http://subdomain1.unsereschule.de/.well-known/acme-challenge/sic3-1R_CDeBIVELIApYRU9aMarBaA6lfPaddl6vYcU wird also ebenfalls auf 443 weitergeleitet

Viele Grüße
Steffen

Hallo,

https://domainxyz.unsereschule.de/.well-known/acme-challenge/ ist übrigens auch nicht per https erreichbar. Also stimmt irgendwas mit der Apache Config noch nicht…

Wenn ich eine Datei /etc/apache2/conf-available/letsencrypt.conf mit Inhalt

Alias /.well-known/acme-challenge /var/www/letsencrypt/
Options None
AllowOverride None
Order allow,deny
Allow from all

mit a2enconf letsencrypt.conf aktiviere, startet der Apache nicht mehr.

Viele Grüße
Steffen

Hallo,

entgegen den Anleitungen habe ich jetzt

Alias /.well-known/acme-challenge /var/www/letsencrypt/

nicht in die Apache-Config eingetragen, sondern in einen virtuellen Host. Jetzt wird https://subdomain1.schulserver.de/.well-known/acme-challenge/ gefunden.

Also habe ich die Zeile in alle virtuellen Hosts ergänzt, damit das für jede Subdomain funktioniert.

Allerdings steht da weiterhin nichts im Verzeichnis drin außer meiner index.html mit „It works“.

Viele Grüße
Steffen

Hallo Steffen,

Vielleicht hilft das?

https://www.sslforfree.com/

Grüße Alois

Hallo Steffen,

die Apache-Datei steckt im Paket „dehydrated-apache2“.

Viele Grüße
Thomas

Hallo Alois

für den Fall, dass ich Let’s Encrypt/Dehydrated nicht vor Zertifikatablauf zum Laufen kriege, wäre das eine Option, um nicht nochmal Geld ausgeben zu müssen.
Da das aber auch über Let’s Encrypt läuft, müsste man da halt alle 90 Tage das Procedere von Hand wieder durchmachen. Daher sehe ich das nur als Übergangs-/Notlösung.

Viele Grüße
Steffen

Hallo Thomas,

ok, danke, das hilft weiter, um den Alias für well-known nicht in jeden virtuellen Host eintragen zu müssen. Ich bin nur etwas irritiert, warum es offensichtlich keine saubere / vollständige Anleitung für die Einrichtung von Dehydrated gibt, in der wirklich alles Punkt für Punkt aufgeführt wird, was man tun muss.

Aus welcher Glaskugel soll man z.B. das mit dem Paket dehydrated-apache2 denn lesen?
Die Anleitungen mit "schreibe die Datei in „conf.d“ funktionieren halt gleich gar nicht.

Wie auch immer. https://irgendeinesubdomain.meineschule/.well-known/acme-challenge liefert mit dem Paket jetzt ein „It works“.

Die Ausgabe von /usr/bin/dehydrated -c bringt noch immer dieselben Ausgaben, das Verzeichnis acme-challenge bleibt bis auf meine index.html leer.

Ich hoffe, dass sich das ändert, wenn der Zugriff über Port 80 auf http://irgendeinesubdomain.meineschule/.well-known/acme-challenge geht.

Allerdings würde ich, wenn ich den Server über Port 80 erreichbar machen muss, gerne erreichen, dass ausschließlich http://irgendeinesubdomain.meineschule/.well-known/acme-challenge eine unverschlüsselte Ausgabe ergibt.

http://irgendeinesubdomain.meineschule und http://irgendeinesubdomain.meineschule/wasauchimmer soll grundsätzlich auf https umgeleitet werden.
Da stehe ich aber mit meinen rudimentären Apache-Kenntnissen auch noch auf dem Schlauch, wie ich das umsetze.

Viele Grüße
Steffen

Hallo,

ich hoffe, dass das so funktioniert:
Eintrag in die virtuellen Hosts für *:80 und *:443 (ich weiß nicht, ob das nötig ist)

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/.*$ [NC]
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Das kann ich leider erst testen, wenn Port 80 von extern an den Server weitergeleitet wird, und da muss ich wie schon erwähnt auf das Gutdünken des „Dienstleisters“ warten. Bis Anfang 2018 hätte ich das von daheim schnell selbst eingerichtet :wink:

Viele Grüße
Steffen

… hattest du nicht schon mal einen reverse Proxy laufen? Ich habe unter OPNSense den HAProxy aufgesetzt. Der fängt diese Anfragen ab und liefert auch die Zertifikate aus … wäre das eine Option für dich?

Schöne Grüße,
Michael

Hallo Michael,

yep, als wir noch eine linuxmuster.net und ich Zugriff auf und die volle Kontrolle über die gesamte Infrastruktur hatte :wink:

da ich nur Zugriff auf die VM des Webservers habe und zumindest dabei definitiv unabhängig von unserem „Dienstleister“ bleiben will, leider nein :frowning:

Viele Grüße
Steffen

Hallo Steffen,
ich nehme für LE-Zertifikate den ganz normalen Certbot und je nachdem, wo die Domain registriert ist, gibt es da diverse Plugins. Das Ergebnis ist bei uns jetzt folgendes:

  • dank Plugin muss überhaupt kein Port nach draußen offen sein, denn nach Aufruf des Certbot legt dieser direkt eine CNAME Challenge an und kann so das Zertifikat verifizieren.
  • man bekommt sogar ein Wildcard-Zertifikat (wenn man will). Also „*.meine-Schule.de“ und kann das überall hin verteilen.
  • Der Certbot kann auf irgendeiner VM liegen - das Zertifikat wird dann per Hook.sh einfach geholt und verteilt.

Falls du mehr wissen willst, kann ich das gerne noch ausführlicher ausführen.
Ich bin jetzt sehr zufrieden - keine offenen Ports mehr, nur noch ein Zertifikat für alles.

viele Grüße
Manuel

Hallo Manuel,

das klingt super. Ja sehr gerne. Eine ausführliche Beschreibung/Anleitung wäre sicher nicht nur für mich interessant.

Viele Grüße
Steffen

Hallo,

Wunder oh Wunder, der „Dienstleister“ hat bereits Port 80 freigeschaltet - vermutlich, weil der neue Schulleiter ihm doch deutlich mehr Druck macht und ich diesen in cc genommen habe und vom „Dienstleister“ die Bestätigung der Durchführung an den Schulleiter und mich haben wollte.

Jedenfalls mit

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.$ [NC]
RewriteRule ^/?(.
) https://%{SERVER_NAME}/$1 [R,L]

in jeder VirtualHost-Config im Bereich *:80, also grundsätzlicher Umleitung von http auf https bis auf .well-known/acme-challenge, läuft Let’s Encrypt dehydrated durch. Die Zertifikate sind da und funktionieren auch.

Jetzt habe ich nur noch eine Frage zur Zertifikatsnerneuerung:

Viele Grüße
Steffen

Hallo Steffen,
hier eine etwas längere „Zusammenfassung“ zum Thema „Zertifikat ohne Port nach draußen“

  • Unsere Domain liegt zur Verwaltung bei INWX (cloudflare ist bei vielen Beispielen aber „Standard“). Wichtig ist nur, dass es ein Certbot-DNS-Plugin gibt.
  • Man installiert also Certbot auf einem Server mit aktuellem Ubuntu (bei mir eine eigene virtuelle Maschine) https://certbot.eff.org/ und anschließend das Plugin (bei uns INWX) https://github.com/oGGy990/certbot-dns-inwx
  • Anschließend Konfiguriert man das ganze wie auf der Plugin-Seite beschrieben.
  • Vom Linuxmusterserver (bei uns 6.2) richtet man zur Zertifikatmaschine, zur Firewall, zu Unifi usw. einen passwortlosen ssh-Zugang ein
  • Der Linuxmusterserver bekommt ein kleines Skript, dass das Zertifikatholen auf der Zertifikatmaschine anstößt. Anschließend kopiert und verteilt er die Zertifikate auf die anderen Server.
  • Das Skript (schicke ich gerne per PM - für die „Öffentlichkeit“ ist es leider zu schlampig, sorry) wird dann einmal pro Woche aufgerufen.
  • Alle haben also die selbe Zertifikatsdatei (dank Wildcard - also *.unsere-schule.de)

viele Grüße
Manuel