Lets Encrypt SSL - Häufige Fragen

Debian? Kann ich sagen, soll mit Debian 7 und Debian 8 gehen. Kann ich auch bestätigen, geht auf beiden (manuelle Installation, nicht mit --apache). Das offizielle Paket kommt aber erst mit Debian 9, also gegen Ende Dez. 2016

Was meinst Du mit den Limits? Welche sind das genau, die Du da schreibst. Das Limit für die Ausstellung von Zertifikaten liegt nämlich bei 5 pro Domain binnen 7 Tagen. Dazu zählt auch renew.

Mach nicht zu viele auf, das bringt nichts. Verschieben und strukturieren kann man später immer noch.

So [USER="49"]Alex07[/USER] , ich bin glaube ich einen Schritt weiter... Bin gerade im Bereich SNI vs. SAN unterwegs.

Letsencrypt, sowohl als --apache als auch --webroot legt Einzelzertifikate an. Das liegt daran, dass das --apache -Modul automatisch die vHosts einzeln durchgeht und als Docroot verwendet und man für --webroot ja auch manuell den jeweiligen Docroot angeben muss. Für jeden Docroot wird dann ein Zertifikat erstellt. Alternativnamen sind nur die, die auch auf den gleichen Host zeigen.

Für ein SAN-Zertifikat, also mehrere verschiedene Hosts mit einem Zertifikat muss man --standalone oder --manuell nutzen und dazu den vorhandenen Webserver stoppen.

ferienunterkunft-bodensee.de nutzt ein Einzelzertifikat
fewo-theissen.de nutzt ein Einzelzertifikat

ferienunterkunft-italien.de und
ferienunterkunft-oesterreich.de und
ferienunterkunft-spanien.de nutzen ein SAN-Zertifikat.

Alle Domänen liegen auf dem gleichen Server. Das SAN und auf der gleichen IP wie Bodensee und Theissen. Die Seiten werden nicht weitergeleitet, sind ja nur ein Test, also beim Aufrufen immer *** Link veraltet ***. voranstellen.

Aktuell melden die Domänen mit dem SAN auch einen Fehler bei alten Browsern, da die eben kein SNI können und die Einzelzertifikate bzw. die Domänen damit in der Rangliste vorne liegen. Schalte ich jedoch die beiden Einzelzertifikate von Bodensee und Theissen ab, dann funktionieren die anderen drei Domänen ohne SNI-Warnung.

Nur, was ist nun besser?

Einzelzertifikate kann man direkt erzeugen und einbinden, ohne den Webserver zu stoppen. Auch kann man einfach eine Domain entfernen oder eine neue hinzufügen, ohne für alle neue Zertifikate zu erstellen. Dafür hat man lauter einzelne und muss die einzeln updaten. Da es SNI nutzt funktionieren Android 2.3.7 und IE8/WinXP nicht.

SAN ist schneller in der Einrichtung und man muss nur eines aktualisieren. Man hat nur ein Zertifikat für alle Seiten. Da es kein SNI nutzt funktionieren auch Android 2.3.7 und IE8/WinXP. Man muss aber den Webserver stoppen. Fügt man eine neue Domain hinzu oder zieht eine auf einen anderen Server, dann muss man ein neues SAN erstellen. Macht man das nicht, dann geht der renew nicht. Es müssen alle aufgeführten Domänen auf dem Server erreichbar sein. Fehlt eine, dann schlägt die ganze Zertifikatsaustellung fehl.

Welchen denn?

Habe mir das gestern Abend noch überlegt, denn Du hattest auf der free-ssl.org erst ein Zertifikat für die Domain selbst, und dann jetzt eines für alle Domains. Kann es sein, dass Du das jetzige selbst erstellt hast mit --standalone und das vorher per ISP? Wäre sogar denkbar, dass es durch die Mischung aus ISP und manuell und die "Umleitung" vom ISP durch die ganzen Symlinks zu Problemen kommt und der Server teilweise gar nicht mehr weiß, welches Zertifikat nun wann raus soll. Du hast wahrscheinlich auch mehrere Zertifikate und eine Domain wird da in verschiedenen vorkommen. So wie ich das gesehen habe nutzt ISP auch nicht nur Symlinks, sondern kopiert die Zertifikate in echt wo anders hin. Gut möglich also, dass letsencrypt das Zertifikat am eigentlichen Ort löscht, wenn Du manuell ein neues ausstellst, das alte kopierte von ISP aber noch da ist.

letsencrypt-auto --webroot -w /pfad/ -d free-ssl.org

erstellt ein Zertifikat für einen vhosts

letsencrypt-auto --webroot -w /pfad/ -d free-ssl.org -w /pfad2/ -d alex-sucht-frau.de

erstellt zwei einzelne Zertifikate und

letsencrypt-auto --standalone -d free-ssl.org -d alex-sucht-frau.de

erstellt ein Zertifikat, das für beide Hosts gilt.

--standalone unterscheidet nicht mehr nach dem Docroot, denn es betreibt einen eigenen temporären Webserver und leitet alle Domänen, die auf dem Server zeigen, in den gleichen vHost. Und in diesem temporären vhost wird die acme-challenge ausgeführt.

Eine neue Sache ist mir gestern auch noch aufgefallen. Ich nutze ja z.B. Piwik auf einer Maschine ohne eigene Domain. Es wird einfach der Hostname von Strato verwendet. Hat Vorteile: kostet nichts und ein Serverumzug geht in ohne Ausfälle, da man nicht auf DNS-Änderungen warten muss.

z.B. h240xxxx.stratoserver.net

Auch bei anderen Seiten nutze ich den Hostnamen als Testdomain ala dev-bodensee.h240xxxx.stratoserver.net. Das Problem ist nur, dass man dafür kein Zertifikat bekommt. Genau genommen ist das Problem die Anzahl der Abfragen. Diese 5 pro 7 Tage beziehen sich nämlich nicht auf die Subdomain, sondern auf die Hauptdomain.

Rufe ich ein Zertifikat für h240xxxx.stratoserver.net ab, dann kommt:

"There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: stratoserver.net"

Muss man also beachten. Gleiches zählt auch für normale Subdomains. Mehr als 5 geht nicht. mit meinen

domain1
*** Link veraltet ***
img0.domain1
img1.domain1
img2.domain1

habe ich das Limit also für domain1 erreicht, auch wenn die Subs teilweise auf verschiedenen Servern liegen. Es ist nicht möglich, hier noch mal ein Zertifikat zu bekommen oder auf Grund eines möglichen Fehlers ein renew zu starten, nicht binnen einer Woche.

Das Limit zählt also nicht für die Sub einzeln, sondern für die Hauptdomain.

Ja, das pro Domain war mir klar, aber ich dachte eine Sub wäre eine eigene Domain. Also *** Link veraltet *** 5x möglich und sub.domain1.de 5x möglich. Aber nee, das zählt zusammen

"Es sind glaube 5 Pro Woche / Domain"
Da glaubst Du richtig, hatte ich ja auch oben im 2. Post geschrieben

Ja Alex, das ist ja noch immer der Punkt wo ich nicht weiter weiß oder mich nicht entscheiden kann. Was würdest Du machen? Ein Server, 14 Domänen.

Ein SAN für alle oder 14 einzelne Zertifikate? Hatte das gestern mit einem SAN versucht und dabei eben das Problem mit stratoserver.net bemerkt (geht per --webroot ein Einzelzertifikat aber auch nicht). Wollte das als erstes in der Liste haben, damit das Zertifikat auch so benannt wird und nicht nach irgendeiner Domain.

Ansonsten, ohne die stratoserver.net ging das mit 13 Domänen als SAN.

Was mich allerdings etwas stört ist, dass ich den Webserver stoppen muss. Das ist das einzige, alles andere finde ich besser. Ein Renew, ein Cron, ein Zertifikat, überall den gleichen Code einbinden.

Zitat

Kannst du keinen eigenen Hostnamen definieren und das auch reverse?

Gute Frage. Nicht dass ich wüsste. Ich kann Reverse schon ändern, aber der muss dann auf eine offizielle Domain zeigen, was ja nicht vorliegt. Daher nutzte ich ja den Host von Strato Default ist der Hostname von Strato, mit Mails gibt es keine Probleme.

Vs oder Root. Beides, ist auch bei beiden identisch. Um den Revers zu ändern brauche ich eine Domäne auf der Maschine. Und gerade wenn die neu ist, dann gibt es die noch nicht, dann nutze ich den Hostnamen zum Testen. Wenn dann alles passt, dann ziehe ich die Domäne um. Ansonsten nutze ich den Hostnamen auch so gerne für Admin-Tools, dann muss man nicht suchen, unter welcher Domäne z.B. der phpma läuft, sondern nimmt einfach den Host und fertig.

Zitat

13 Domänen als San sollten gehen, wenn da keine Subs bei sind.

Doch, Subs sind dabei, aber max drei pro Domain. Also das SAN ging zu erstellen, das ist nicht das Problem (halt ohne h20xxxx.stratoserver.net). Ich habe hier eher eine Glaubensfrage, wo es mich hin und her reißt. Und eben den Punkt mit "Apache stoppen".

Zitat

Was ist daran elegant und wo liegen die Fehler?

Hm, war das eine Frage an mich?

Was elegant ist weiß ich nicht bzw. verstehe es nicht. Fehler ist da bei "letsencrypt-auto -d seo-nw.de" auch keiner zu sehen (gut, eine Kleinigkeit. Du solltest die www mit nehmen.). Ist halt genau der andere Weg, kein SAN. Du nutzt damit also automatisch das --apache - Modul.

Das bei Dir ist ja was anderes. Dein ISPConfig erstellt keine SANs für den Server, sondern einzelne Zertifikate per --webroot.
Der manuelle Aufruf von letsencrypt-auto --apache erstellt es auch nicht.

Nur --standalone macht das und da muss man dann eben in den einen Aufruf alle Domänen mit rein packen. Aber wie gesagt, der Nachteil, Apache stoppen, Zertifikat erstellen lassen, Apache starten.

Also kurz gesagt:
--webroot: Keine Unterbrechung, kein Server-SAN
--standalone: Unterbrechung von ein paar Minuten, Server-SAN möglich (unter Beachtung der max. 5 pro Domain).

P.S. Wegen SAN. Kannste da schauen, eben neu erzeugt. Da läuft eines mit glaube 16 Domänen drinnen

*** Link veraltet ***. ferienunterkunft-bodensee.de/

Mir stellt sich aber eine neue, ganz andere Frage... Was macht man bei einem Serverumzug? Also ich meine nun nicht eine einzelne Domain umziehen, sondern alle. Das Zertifikat kann man ja nicht mitnehmen, sondern muss es neu erstellen. Das geht auf dem neuen Server und eben per DNS. Doch, was wenn DNS länger braucht und noch auf den alten Host auflöst? So lange das nicht durch ist, kann man kein neues Zertifikat erstellen und das kann ja bekanntlich 48 Stunden dauern ....

Zitat

Und da hat er gemeckert, was ich nicht verstehe ist Chinesisch

Bitte was?

Zitat

Die Subs sind von meinem Lieblingsprojekt

ok, jetzt raffe ich es, oder? Du meinst Pagespeed? Wenn ja, dann sind die Subs dort ein Problem, denn zu viele.

Klar, dass die 48 Stunden das äußerste Limit sind, aber Du weißt ja, der Teufel ist ein Eichhörnchen. Will sagen, wenn ich den Server mit 16 Domänen umziehe und nur eine einzige länger im DNS braucht, dann kann ich kein Zertifikat erstellen. Oder eine einzelne Domain. Das macht schon einen Unterschied, ob man einen fertigen Server hat, fertig eingerichtet und dann umzieht und alles vom alten weiterleitet und fertig oder ob man dann noch 4 Stunden auf ein Zertifikat warten muss. Weil ich ziehe ja eigentlich erst um, wenn alles fertig ist und dann alt sofort tot und neu aktiv.

P.S. Genau das ist z.B. auch so ein Fall, wo ich mit den Hostnamen arbeite. z.B.
ferien-netzwerk umziehen. Neuer Server fertig, DNS ändern. Zu dem Zeitpunkt kommen aber noch immer Zugriffe auf den alten Server. Diese leite ich dann temporär um auf ferien-netzwerk.hxxxx.stratoserver .net vom neuen Server. Ergibt ein paar Sekunden Ausfallzeit und definitiv keine verlorenen Daten oder Zugriffe, die ins Leere laufen. Und nach 2 oder 3 Tagen wird die ferien-netzwerk.hxxxx.stratoserver .net dann einfach entfernt, denn DNS passt und alle sind auf dem neuen Server.

Ja gut, das hat mit letsencrypt aber nicht viel zu tun. Die testen mehrere DNS-Server von verschiedenen Standorten. Ich weiß zwar nicht, was passiert, wenn da verschiedene Antworten kommen, aber egal. Der eigentliche Punk ist ja das DNS an sich. Kommt halt auch drauf an, wo man hostet, wo man das DNS ändern kann, wann man es ändert und wie schnell der eigene Provider das an die übergeordneten weitergibt bzw. die übergeordneten das abholen.

Das Einzige was da helfen könnte wäre die TTL ein paar Tage vorher runterzusetzen auf eine Stunde oder 30 Minuten oder so, damit das schneller verbreitet wird.

Die stratoserver .net sind im Grunde global gesehen Wildcard-Einträge ala *.stratoserver .net, Aufgelöst wird dann über die Strato-DNS-Server und die sind immer aktuell. Server bestellen und sobald der aktiv ist ist der Host weltweit erreichbar, keine Wartezeit.

Bezüglich "richtigen Hostnamen": Da habe ich mich heute Nacht noch mit rumgeschlagen. Bei Strato ist es nicht möglich, den Hostnamen zu ändern, der ist fest vorgegeben, bei vServern und bei Root. Reverse ja, aber das bringt ja nichts, wenn keine Domain drauf ist^^

*** Link veraltet ***

P.S. Der Teufel kann ein Eichhörnchen sein, aber nicht jedes Eichhörnchen ist ein Teufel Hatte aber schon so ein paar teuflische von denen. Da stellt man was auf den Frühstückstisch draußen hin, Äpfel, etc und geht wieder rein. Dann kommt man zurück und was hockt da auf dem Tisch und isst meine Apfelscheibe?