LetsEncrypt Frage

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Hi Shadow,

      so weit ich weiß muss der CertBot, wenn er in diesem Modus gestartet wird, auf Port 80 und 443 laufen, damit er die URLs verifizieren kann.
      Da der Apache bereits diese Ports belegt funktioniert das nicht, deshalb habe ich das Skript so geschrieben.

      Falls ich was falsch verstanden habe bei der Einrichtung, dann bin ich natürlich für korrekturen dankbar!

      Viele Grüße & frohe Ostern,
      piccolo
    • Ok,

      also dann zuerst mal


      Source Code

      1. touch /etc/apt/sources.list.d/jessie-backports.list
      2. mcedit /etc/apt/sources.list.d/jessie-backports.list




      Als Inhalt muss da

      Source Code

      1. deb http://ftp.debian.org/debian jessie-backports main

      rein. Dann ein

      Source Code

      1. apt-get update && apt-get upgrade
      gefolgt von einem

      Source Code

      1. apt-get install certbot -t jessie-backports
      Zum erzeugen eines Zertifikates benutzt du dann ein

      Source Code

      1. certbot certonly --webroot -w /var/www/virtual/domain.tld/htdocs -d domain.tld -d www.domain.tld
      Das war es. So benutzt er den vorhandenen Apache, ohne das man an der Konfiguration was ändern muss. Einziger Wermutstropfen ist das man die Zertifikate (noch) manuell einfügen muss. Ich mache es dann so, das ich die vorhandene config einer Webseite kopiere und um den suffix "-ssl.conf" ergänze. Dann bleibt diese immer bestehen, auch wenn man im Panel was ändert. Dort trage ich dann die letsencrypt Zertifikate ein. Einen Cronjob zum verlängern hat der certbot normal schon drinnen.

      Falls noch fragen sind einfach Bescheid sagen.
      Gruss
      Shadow
    • Ich habe für eine neue Domain ein Letsencrypt-Zertifikat generiert und dann versucht, in EasySCP den CSR und Key für die Domain einzutragen.
      Ich bekomme jetzt aber immer die Meldung, dass das Zertifikat und der Key nicht übereinstimmen.

      Ich hatte den Server seinerzeit mit EASYSCP Version 2.0.0 build 20160821 installiert und 2017 auf 2.0.1 upgedatet. Ich bin eigentlich der Meinung gewesen, dass ich direkt danach auch auf 2.0.2 upgedatet habe. Das scheint aber nicht geklappt zu haben, da noch php Admin Version 4.0.10.19 aktiv ist.

      Ich hatte dann irgendwann im Herbst 2017 mal kurzzeitig zum Test ein Zertifikat für eine andere Domain generiert und eingetragen. Zu dem Zeitpunkt klappte das noch.

      Inzwischen wurde der Server auf Debian V8.11 upgedatet und php auf Version 5.6. Sonst wurde seit 2017 nichts weiter geändert.

      Irgend eine Idee, warum das Zertifikat jetzt immer abgelehnt wird?
    • Hi,

      ich hoffe du meinst eigentlich das CRT, und nicht den CSR. Das letzteres ist der Signing Request, der ist nicht zum eintragen gedacht. Sondern das tatsächliche Zertifikat.

      Damit Let´sEncrypt geht, brauchst du den Inhalt aus dem cert.pem, chain.pem und privkey.pem. Das jeweils in die passenden Fehler im Panel eintragen, dann sollte es sofort laufen
      Gruss
      Shadow
    • Oh, sorry, mein Fehler. Mit dem CRT hat es jetzt geklappt.

      Ich habe jetzt noch das Problem, dass ich - analog zu der jetzt erzeugten ersten Domain - weitere Zertifikate für https und für postfix.für ein paar andere Domains eintragen muss, die in EASYSCP als Alias definiert sind.

      Das geht ja mit EASYSCP nicht, wie du mal sagtest.
      Hast du eventuell eine Liste dazu, in welche Config-Dateien ich da überall rein und Änderungen machen muss?
    • Hi,

      das Hauptproblem dürfte ja eher sein, das die Zertifikate automatisch vom CertBot erneuert werden, ohne das EasySCP das mitbekommt. Das dürfte vermutlich auch der Grund für die "Ablehnung" sein, da das hinterlegte Zertifikat mittlerweile abgelaufen ist.

      Bzgl. MultiDomain/Alias: Man erzeugt einfach ein Zertifikat, welches alle Domains/Aliase beinhaltet. Das Limit war beim CertBot irgendwas mit 100 Einträgen soweit ich mich erinnere.
      Gruss
      Shadow
    • Wie gesagt, das Zertifikat für die Hauptdomain funktioniert jetzt vorerst.

      Ein gemeinsames Zertifikat für Domains verschiedener Anwender ist auch nicht die wirkliche Lösung.

      Zum Anderen hatte ich das auch letztes Jahr schon mal probiert und das führte dazu, dass https für den Alias zwar ging, aber keine Emails mehr von der Domain versandt wurden, weil postfix da was an Infos fehlte...

      Die Erneuerung der Zertifikate ist dann noch ein weiteres Problem.

      Wie es aussieht, muss ich mich dann wohl doch mal nach einer Alternative zu EasySCP umschauen, die Letsencrypt mit virtuellen Domains besser unterstützt.
    • Hallo ShadowJumper,

      deine Anleitung ist zwar sehr schön und hat bei mir auch funktioniert, es gibt aber seit Anfang 2018 bei Letsencrypt eine schöne Möglichkeit, Wildcard-Zertifikate zu benutzen. Allerdings ist es etwas tricky und erfordert am Besten einen eigenen DNS-Server. Da man im Zusammenhang mit EasySCP vermutlich PowerDNS schon sowieso nutzt, habe ich dafür eine schöne Anleitung im Netz gefunden:

      marvingaube.de/lets-encrypt-wildcards-powerdns/

      Es läuft im Unterschied zur "hasugemachten" letsencrypt-Lösung etwas anders und erfordert einen relativ neuen PowerDNS in Version 4.1, was z.B. bei Debian 8 nicht so einfach zu installieren ist. Destotrotz hatte ich gerade diese Lösung bei meinem Debian8-basierten System zum Laufen gebracht.

      In diesem Zusammenhang hätte ich folgende Bitte an dich:
      Wenn du letsencrypt in EasySCP integrierst, denk bitte an diese Lösung mit wildcard-Zertifikaten. Wenn möglich, bitte eine vernünftige Schnittstelle zum Ablageort für Zertifikate in EasySCP implementieren, dass man nicht nur Zertifikate per Webinterface als Text einpflegt, sondern stattdessen einen Link dafür definieren kann. Z.B. global in der config-Datei von EasySCP. Die Übergangslösung mit separaten *ssl.conf-Dateien unter "sites-available" ist zwar machbar, aber schwer zu pflegen. Die von EasySCP automatisch generierten apache-configs sind schon gut, wenn man "ssl" im Webinterface aktiviert. Bloß anstelle der editierbaren Zertifikaten sollte der Pfad an eine andere Stelle "umlenkbar" sein.
      Ich weiß, dass so etwas nicht schön enden kann, wenn die Zertifikate an der Stelle nicht auffindbar sind und Apache danach dann nicht starten kann. Es sollte aber dann demjenigen überlassen sein, dafür zu sorgen, dass die Pfade nicht ins Leere zeigen.
      MfG

      August