Beiträge von kk

  • Lets's Encrypt Fehler (ACME-Challenges) - Invalid response

    Wenn Sie die "/.well-known/acme-challenge/"-URL geringfügig ändern (konkret: am Hash-Wert am Ende irgendeine Zahl austauschen), bekommen Sie dann immer noch einen 403 (Forbidden) oder einen 404 (Not Found)?


    Alternativ: stellen Sie Ihre Subdomain vorübergehend mal von der App (ownCloud) auf "Webspace" um und versuchen damit das Let's Encrypt-Zertifikat anzufordern (auch einfach wieder nur beim SSL-Zertifikat auf "speichern" klicken um eine neue Authorisierung auszulösen). Vielleicht beißt sich das .htaccess-File von ownCloud mit der Acme-Challenge.

  • Lets's Encrypt Fehler (ACME-Challenges) - Invalid response

    Wenn Sie via LiveConfig en Let's Encrypt-Zertifikat anfordern, passiert Folgendes:

    1. LiveConfig fordert via Let's Encrypt einen Authentifizierungs-Token für die Domain an
    2. diesen Token verwendet LiveConfig anschließend, um die vHost-Konfiguration für die Prüfung durch Let's Encrypt anzupassen. Konkret wird also in /etc/apache2/sites-enabled/<Vertrag>.conf ein Abschnitt für "/.well-known/acme-challenge/<Token>" eingefügt.
    3. ca. 90 Sekunden nach dieser Änderung triggert LiveConfig bei Let's Encrypt die Prüfung dieses Tokens an (90 Sekunden deshalb, weil es bis zu 60 Sekunden dauern kann bis die neue Apache-Konfiguration aktiv ist).
    4. wenn die Authentifizierung abgeschlossen ist (egal ob erfolgreich oder erfolglos) wird der ".well-known/acme-challenge/"-Abschnitt wieder aus der vHost-Konfiguration entfernt.


    Gehen Sie bitte im LiveConfig noch mal auf "SSL-Zertifikate", öffnen das (bislang unvollständige) Zertifikat und klicken erneut auf "speichern".
    Unter "Berichte" -> "ACME-Zertifikate" sollten Sie dann neue Einträge mit dem Status "pending" sehen. Gleichzeitig sollte die Konfigurationdatei /etc/apache2/sites-available/<Vertrag>.conf aktualisiert werden. Wenn alles klappt müsste nach ca. 2-3 Minuten das Zertifikat ausgestellt sein.


    Viele Grüße


    -Klaus Keppler

  • Let's Encrypt: ACME: can't get certificate

    Mit dem User der das Zertifikat anfordert dürfte das Problem nicht zusammenhängen, da der komplette ACME-Teil unabhängig von irgendwelchen Benutzern etc. abläuft. Es dürfte sich da eher um einen Zufall gehandelt haben.
    Wir beobachten derzeit, dass es seitens Let's Encrypt zu bestimmten Stoßzeiten dazu kommt, dass Zertifikate nicht sofort nach der Anforderung bereitstehen, sondern erst nach kurzer Wartezeit. Wir arbeiten gerade an einer Lösung, weitere Infos dann in den nächsten Stunden.


    Viele Grüße


    -Klaus Keppler

  • DNS management fails

    I assume this is a "chicken-and-egg" problem. If I understand this correctly, you've created a DNS template with "ns1.domain.com" as nameserver, while the domain "domain.com" didn't have any A record for "ns1" at that time.


    The following workaround should help:
    1.) issue "rndc freeze domain.com"
    2.) edit /var/lib/bind/domain.com.db:
    - add A records for your "ns*" subdomains
    - increase the serial number in the SOA
    3.) run "rndc thaw domain.com"
    4.) run "rndc reload domain.com"
    Then wait a moment to let BIND re-read that zone. Check with "dig @127.0.0.1 ns1.domain.com A" if you get the correct A record.
    5.) then restart LiveConfig - this should flush the DNS update queue.


    I think we'll have to add a check if all nameserver names used (in DNS templates) are actually available in DNS.

  • LiveConfig v2.0.2 freigegeben

    Ab sofort steht mit LiveConfig v2.0.2 ein kleineres Update bereit. Gegenüber der Lab-Version vom 29.12.2015 gibt es darin keine Änderungen, alle Details finden Sie im Änderungsverlauf.
    Dieses Update behebt hauptsächlich kleinere Fehler und schafft etwas mehr Komfort bei der Verwendung von Let's Encrypt-Zertifikaten.


    Die erste Preview auf v2.1.0 wird Ende dieser Woche bereitgestellt, diese enthält einen ganzen Schwung neuer Funktionen. Details folgen dann.


    Viele Grüße


    -Klaus Keppler

  • SSL Zertifikat

    LiveConfig konnte keine Schlüssel decodieren, die im verschlüsselten PKCS#8-Format ("BEGIN ENCRYPTED PRIVATE KEY") vorlagen. Mit Version 2.1.0-r4045 klappt das künftig aber auch.


    In diesem Fall (StartSSL) wäre es übrigens sicherer, den Key und den CSR auf dem LiveConfig-Server zu erzeugen und anschließend (nur) das CSR für die Beantragung des Zertifikats an StartSSL zu schicken. Wenn der Key bei StartSSL erzeugt wurde, haben die (theoretisch) Zugriff darauf.


    Viele Grüße


    -Klaus Keppler

  • SSL Zertifikat

    Ich habe mal anhand der o.g. Fehlermeldung im OpenSSL-Source gestöbert. Die Meldung deutet darauf hin, dass der private Schlüssel mit einem Algorithmus verschlüsselt ist, den LiveConfig nicht "kennt". Wenn das der Fall ist, dann ist das ziemlich interessant, da LiveConfig die OpenSSL 1.0.1 in der neuesten Version enthält und somit alle üblichen Algorithmen unterstützen sollte.


    Sie können mal versuchen, Ihren privaten Schlüssel "manuell" zu entschlüsseln:
    openssl rsa -in <Dateiname>
    Wenn dann (nach der Passworteingabe) der decodierte RSA-Schlüssel angezeigt wird, können Sie den einfach in die SSL-Eingabemaske im LiveConfig einfügen.


    Viele Grüße


    -Klaus Keppler

  • CentOS 7: LCSAM läuft nicht

    Seit CentOS 7.2 gibt es scheinbar ein Problem, wenn ein Init-Script (z.B. /etc/init.d/lcsam) keine normale Datei sondern ein symbolischer Link ist. Mit LiveConfig 2.1.0 ändern wir das daher (u.a. gibt es da gleich systemd-Unit-Files).


    Lösung also: löschen Sie den Symlink in /etc/init.d/lcsam und kopieren Sie das Startscript selbst (/usr/lib/liveconfig/lcsam) dorthin. Dann müsste es wieder klappen.


    Viele Grüße


    -Klaus Keppler

  • Well-known DH parameters in LiveConfig 2.0.1-r3988

    Seit Version 1.9.1-r3707 fügt LiveConfig individuelle DH-Parameter an die jeweilige Zertifikatsdatei hinzu. Debian Wheezy unterstützt das seit Apache 2.2.22-13+deb7u4.


    Mit anderen Worten: eigentlich sollten da aktuelle (nicht allgemeinbekannte) DH-Parameter mit ausgeliefert werden. Wenn das noch nicht der Fall ist, prüfen Sie bitte mal folgende Schritte:
    1.) öffnen Sie die Datei /etc/apache2/sites-available/<Vertrag>.conf. Suchen Sie dort nach "SSLCertificateFile".
    2.) öffnen Sie die angegebene Zertifikats-Datei (/etc/ssl/certs/[...].crt). Dort sollte erst das Zertifikat stehen ("---BEGIN CERTIFICATE ..."), danach ein Abschnitt mit DH-Parametern ("# custom DH parameters...").


    Falls dort keine DH-Parameter stehen, prüfen Sie bitte ob die Datei /etc/apache2/dhparam.pem existiert. Falls nicht, geben Sie bitte Bescheid.
    Wenn die Datei existiert, speichern Sie den Webhosting-Vertrag in LiveConfig neu (z.B. indem Sie irgendeine Subdomain-Einstellung für diesen Vertrag neu speichern). Damit sollte u.a. die /etc/apache2/sites-available/<Vertrag>.conf neu geschrieben werden, also auch die o.g. SSL-Zertifikats-Datei. Diese sollte dann eigentlich auch die (neuen) DH-Parameter enthalten.


    Viele Grüße


    -Klaus Keppler

  • DB-Namensvergabe

    Ab v2.1.0-r4040 sind die Präfixe nun flexibler ("%c" kann an beliebiger Stelle verwendet werden).


    Bitte achten Sie dennoch darauf, dass die Namen nicht zu lang werden. MySQL-Benutzernamen sind aus historischen Gründen fest auf maximal 16 Zeichen begrenzt (das ist in MySQL selbst begrenzt, LiveConfig wäre das prinzipiell egal).

  • Fehler bez Zuornung von Ordner bei FTP Benutzern und Domains

    Hallo Herr Krüger,


    wir können das von Ihnen beschriebene Problem leider nicht reproduzieren, daher habe ich noch ein paar Fragen:
    - handelt es sich um ein Multiserver-Setup?
    - - falls ja: tritt das Problem bei Webspaces auf allen Client-Servern auf? Was wird unter "Serververwaltung" in der Spalte "Verbunden seit" für den betroffenen Client angezeigt?
    - haben Sie den LiveConfig-Server (und bei Multiserver-Setup: den LiveConfig-Client) schon mal neu gestartet?


    Mit freundlichen Grüßen


    -Klaus Keppler