Beiträge von kk

  • Erneuerung / Verlängerung

    Hallo,


    diese E-Mails werden von letsencrypt.org derzeit für alle Zertifikate verschickt - auch dann wenn diese mehrfach beantragt wurden oder auch wenn die zwischenzeitlich bereits verlängert sind.
    Das Thema ist dort bekannt und es wird bereits daran gearbeitet das zu verbessern. Es wurde allerdings beschlossen, in der Startphase lieber etwas vorsichtiger zu sein und Erinnerungen dennoch zu verschicken.


    LiveConfig führt die automatischen Verlängerungen ab v2.1.0 zuverlässig durch (wir haben eine ganze Menge Zertifikate aus der Beta-Phase absolut reibungslos verlängert). Dieses Update planen wir am Donnerstag (28.01.) als "stable" freizugeben, da dann auch ein als "kritisch" eingestuftes Update für OpenSSL verfügbar gemacht wird. Ab da bleiben also über vier Wochen Zeit, LiveConfig zu aktualisieren um dann auch Zertifikate automatisch erneuert zu bekommen.


    Die Authorisierungen für Domains sind übrigens 9-10 Monate gültig, daher dürften alle Verlängerungen reibungslos durchlaufen (da keine erneute Authorisierung erforderlich ist). Wir betreiben hier ja eine eigene Testinstanz vom "Boulder"-Server (das ist die CA-Software die auch hinter Let's Encrypt steckt). Damit testen wir den Fall, dass eine erneute Authorisierung nicht klappt (z.B. wenn eine Subdomain inzwischen nicht mehr existiert usw.), in dem Fall wird LiveConfig von sich aus rechtzeitig Warnungen verschicken.


    Viele Grüße


    -Klaus Keppler

  • v1.7.4-r3081 Spamassassin und Catachall-Adressen funktioniert nicht

    Mit v2.1.0-r4080 wird es bei CatchAll-Accounts nicht mehr möglich sein, den Spamfilter über die Oberfläche zu aktivieren. Bei bestehenden CatchAll-Accounts, bei denen diese Option gesetzt war, wird diese automatisch entfernt.
    Gleichzeitig unterstützt der LiveConfig SpamAssassin-Milter ("lcsam") ab dieser Version aber "CatchAll"-Einträge in der /etc/postfix/spamassassin.db
    Der Workaround wäre dann also, für die gewünschten CatchAll-Accounts manuell entsprechende Einträge in /etc/postfix/spamassassin anzulegen.


    Eine kurze Anleitung dazu gibt's wenn wir die Preview aktualisiert haben (spätestens Donnerstag).


    Viele Grüße


    -Klaus Keppler

  • FastCGI / FcgidPassHeader Authorization

    Kommt auf die Distribution an. Unter Debian könnten Sie diese Zeile z.B. in /etc/apache2/mods-enabled/fcgid.conf mit eintragen.


    Prinzipiell könnte LiveConfig das künftig auch in die vHost-Konfiguration schreiben. Wir müssen allerdings prüfen, ob oder welche Sicherheitsrisiken dabei tatsächlich bestehen (in der Doku wird ja zwischen den Zeilen davon abgeraten).

  • PREVIEW: LiveConfig 2.1.0

    Hallo,


    ab sofort steht die erste Preview auf LiveConfig 2.1.0 bereit. Das Changelog ist recht umfangreich, die wichtigsten Punkte sind:

    • AutoDiscover: die "autoconfig"- und "autodiscover"-Subdomains werden nun automatisch durch LiveConfig angelegt. Als CNAME wird dabei der Name eingetragen, den man unter Serververwaltung -> Mail für Autodiscover hinterlegt hat (zur Erinnerung: das muss ein Hostname sein, auf dessen IP nur ein Redirect stattfindet und auf der KEIN HTTPS (Port 443) erreichbar ist).
      Während des Upgrades auf LiveConfig 2.1.0 werden die beiden Subdomains automatisch für alle Domains angelegt, die von LiveConfig verwaltet werden, wenn Autodiscover aktiviert ist. AUSNAHME: wenn bereits autodiscover/autoconfig-Subdomains existieren, dann werden diese nicht geändert.
    • die Hostnamen für SMTP und POP3/IMAP-Server (die dann u.a. auch vom Autodiscover-Service ausgegeben werden) waren bislang automatisch gleich dem Hostnamen. Ab sofort können diese frei geändert werden. Wenn man den SMTP-Hostnamen ändert, werden z.B. auch automatisch alle MX-Einträge entsprechend aktualisiert.
    • Autodiscover kann nun pro Domain ein- und ausgeschaltet werden
    • Autodiscover kann zudem pro Postfach konfiguriert werden (ob keine Konfiguration ausgegeben werden soll, oder ob POP3 oder IMAP priorisiert werden sollen)
    • Let's Encrypt: auslaufende Zertifikate werden automatisch 30 Tage vor Ablauf verlängert und auf den Webservern ersetzt (für Mail/FTP wird das auch in Kürze automatisch erfolgen, ist aber noch in Arbeit).
    • Zudem wurde die Behandlung von Fehlern oder unerwarteten Antworten vom Let's Encrypt-Service verbessert, Fehlermeldungen werden vollständig ins LiveConfig-Log geschrieben.
    • Für alle Dienste stehen nun systemd-Unitfiles bereit.


    Das Update lief auf unseren eigenen Systemen reibungslos durch, dennoch empfehlen wir vorab (wie immer) ein Datenbank-Backup anzulegen (bei SQLite erfolgt das automatisch) und nach dem Upgrade das LiveConfig-Log zu prüfen.


    Es sind noch nicht alle offenen Änderungen in der Preview verfügbar, weitere Updates folgen nächste Woche.


    Viele Grüße & ein schönes Wochenende!


    -Klaus Keppler

  • Backup MX

    Ganz ehrlich?
    Das Zeitalter von "Backup-MX" ist eigentlich vorbei. Ein Backup-MX ist ja dazu gedacht, an Stelle des Primary-MX die E-Mails für eine Domain vorübergehend entgegenzunehmen und dann an den Primary-MX zuzustellen sobald dieser wieder erreichbar ist.
    Das ganze stammt aus einer Zeit als im Internet tatsächlich einige Netzsegmente untereinander nicht erreichbar waren (da war der Backup-MX quasi eine Alternativroute) und als Systeme auch nicht unbedingt durchgehend erreichbar waren (Stichwort: UUCP, falls das hier noch jemand kennt... ;-))


    Bei heute üblichen E-Mail-Setups müsste ein Backup-MX aber im Prinzip die komplette E-Mail-Konfiguration des Primary-MX klonen, um z.B. eingehende Mails (je nach Empfängereinstellungen) auf Spam zu prüfen und ggf. noch zur SMTP-Zeit vom Absender abzulehnen (bringt ja nichts die Mail anzunehmen, dann an den Primary zu leiten und bei Nichtannahme ein Bounce zu erzeugen...). Es gibt auch viele Spam-Tools, welche gezielt Mails an Backup-MXs zustellen, im Vertrauen darauf dass Mails vom Backup-MX einfacher durchgelassen werden.


    Mit einem Backup-MX könnte man also bestenfalls den Fall abfedern, dass der SMTP-Dienst (hier: Postfix) auf dem Primary-MX nicht erreichbar ist. Fällt aber der ganze Server oder dessen Anbindung aus (was eher der Fall ist), dann sind auch POP3/IMAP nicht erreichbar (und da werden sich meist mehr Kunden beschweren als wenn keine neuen Mails eintreffen).
    Jeder halbwegs vernünftige Mailserver versucht zudem bei Nichterreichbarkeit des Zielsystems eine erneute Zustellung in einem dynamischen Intervall (z.B. erstmals nach 5 Minuten, dann 4x alle 15 Minuten, dann stündlich, usw...). Sollte die Netzanbindung oder der Server mal weg sein, werden Mails also bei den Absendern gespooled und dann automatisch später zugestellt.


    Was LiveConfig betrifft planen wir aktuell keine spezielle BackupMX-Unterstützung. Falls hier tatsächlich großer Bedarf gemeldet wird, könnten wir aber gerne die notwendigen Schnittstellen bereitstellen um sich passende Backup-Server zu konfigurieren.
    Persönlich empfehle ich aber eher, den Primary-MX möglichst hochverfügbar zu machen (Redundanz, Monitoring, ...) statt zwei Systeme parallel pflegen zu müssen.


    Viele Grüße


    -Klaus Keppler

  • LiveConfig und Ioncube

    Die Umlaute haben mit ionCube höchstwahrscheinlich nichts zu tun, genauso wenig mit LiveConfig.
    Häufig ist das Problem ein schlampiger PHP-Code, der keinen korrekten "Content-Type:"-Header ausgibt. Sie können in Apache mit der Anweisung AddDefaultCharset einen Standard-Zeichensatz festlegen (z.B. in einer .htaccess-Datei).

  • 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