Beiträge von kk

Danke für die Rückmeldungen!

Aktueller Stand ist, dass die betroffenen Zertifikate heute (04.03.2020) um 20:00 UTC (also 21:00 MEZ) zurückgerufen werden (Quelle).

Version 2.9.3 steht ab sofort zur Installation bereit.

Diese behebt einen Fehler aufgrund dessen v2.9.2 mit MySQL-Backend nicht starten konnte.
Ansonsten gibt's keine Änderungen (wer also SQLite nutzt braucht dieses Update nicht einspielen).

Bitte entschuldigt die Unannehmlichkeiten.

Viele Grüße

-Klaus Keppler

Danke für die Rückmeldungen - Fehler ist gefunden und behoben. In unserer Testumgebung hatte die Schemaänderung funktioniert, mit älteren MySQL/MariaDB klappt's offenbar nicht.
Update (v2.9.3-release) wird eben gebaut und steht in ca. 20 Minuten online. Ich gebe dann noch mal Bescheid.

Zitat von bfal

Code

[2020/03/03 21:39:40.928042] [1531|1531] Upgrading database schema (r209021 -> 2.9.2-2)
[2020/03/03 21:39:41.826993] [1531|1531] Database connection failed: Table 'SSLCERTS' is specified twice, both as a target for 'UPDATE' and as a separate source for data

Oha. Dürfte mit MySQL zusammenhängen - wir prüfen das sofort.
Welche MySQL-Version genau setzen Sie ein? Und wissen Sie, ob diese im "strict mode" läuft?

Weil uns diese Frage inzwischen schon öfter erreicht hat:
es sind nicht alle Let's-Encrypt-Zertifikate betroffen, die in dem o.g. Zeitraum ausgestellt wurden.
Es betrifft nur die Fälle, in denen die CAA-Prüfung für die Domains älter als 8 Stunden waren - meistens also bei Zertifikaten die (unnötigerweise) in sehr kurzen Intervallen verlängert wurden.

In v2.9.2 (das Release von eben) ist das nicht enthalten - wir haben das Let's-Encrypt-Hotfix in den letzten stabilen Zweig integriert.

Das o.g. Feature ist dann im kommenden regulären Update enthalten (das wird auch nicht mehr lange dauern). Da wir heute zwingend ein "stable" Update freigeben mussten, ging das leider nicht anders.

Viele Grüße

-Klaus Keppler

Hallo,

ab sofort steht LiveConfig v2.9.2 zur Installation bereit.

Es handelt sich hierbei um ein ungeplantes Release, daher sind nur relativ wenige Änderungen enthalten (vollständige Liste siehe Changelog).

Der Grund für dieses kurzfristige Release ist der CAA Rechecking Bug beim SSL-Anbieter Let's Encrypt. Heute Nachmittag (!) hatte Let's Encrypt damit begonnen, Inhaber von betroffenen SSL-Zertifikaten (soweit möglich) per E-Mail darüber zu informieren, dass diese Zertifikate am 04.03.2020 um 00:00 zurückgezogen werden.

Der Grund für den so kurzfristigen Rückruf sind strenge Vorgaben des Browser-Forums. Let's Encrypt versucht zwar noch etwas mehr Zeit für den Zertifikatsaustausch auszuhandeln (siehe Bugzilla), aber ob das klappt ist derzeit noch nicht absehbar.

Die Begeisterung über diese gar so kurzfristige Aktion hält sich natürlich in Grenzen, wie man im Let's-Encrypt-Forum verfolgen kann.

Wir haben die Datenbank mit den betroffenen Zertifikaten (hier) heruntergeladen, die reinen Seriennummern aller 3.048.289 Zertifikate extrahiert und in eine Datenbank geschrieben. Auf http://www.liveconfig.com haben wir eine API eingerichtet, um zu prüfen ob ein Zertifikat betroffen ist.

LiveConfig v2.9.2 macht nun Folgendes:

• beim Start von LiveConfig werden alle SSL-Zertifikate, die von Let's Encrypt zwischen dem 04.12.2019 00:00 und dem 29.02.2020 04:00 ausgestellt wurden, speziell markiert (SSLCERTS.SSL_CHECKSTATUS=1)
• alle paar Minuten werden jeweils bis zu 100 dieser Zertifikate über den Webservice unter https://www.liveconfig.com geprüft - dabei wird lediglich eine JSON-Liste mit den Seriennummern (ohne Domainnamen) übermittelt und ggf. eine Liste mit den betroffenen Seriennummern zurück übermittelt.
  In /var/log/liveconfig/liveconfig.log sieht das dann so aus:
  
  
  Code

  Checking SSL CA reissue status for 100 certificates...

  
  

• Alle ggf. betroffenen Zertifikate werden anschließend automatisch neu beantragt (SSL_CHECKSTATUS wird dann auf "3" geändert). Alle nicht betroffenen Zertifikate erhalten SSL_CHECKSTATUS=2
• Nach wenigen Minuten sollte der Spuk somit vorbei sein.

Es sind wohl rund 2,6% aller Zertifikate betroffenen - unseren ersten Tests nach sieht das plausibel aus.

Sollten Fragen oder Probleme auftauchen melden Sie sich bitte einfach.

Viele Grüße

-Klaus Keppler

Das Update ist fertig, unsere Tests waren bislang positiv. Von knapp 500 SSL-Zertifikaten mussten 2 neu ausgestellt werden, was automatisch und fehlerfrei durchlief.

Wenn nichts dazwischen kommt, werden wir v2.9.2 (release) noch vor 22:00 freigeben. Fortsetzung folgt...

Kurzer Zwischenstand: der Webservice ist fertig, ebenso die Prüfung der Zertifikate. Aktuell wird noch das Anstoßen der Neuausstellung eingebaut.

Hallo,

bei Let's Encrypt ist vor einigen Tagen ein Fehler bei der Ausstellung von Zertifikaten (CAA Rechecking Bug) bekannt geworden. Vereinfacht gesagt wurde die Prüfung von CAA-Records in bestimmten Fällen nicht korrekt durchgeführt.
Gemäß der Bedingungen des Browser-Forums müssen fälschlicherweise ausgestellte Zertifikate innerhalb eines sehr kurzen Zeitraums zurückgezogen (revoked) werden.

Konkret ist das so, dass Let's Encrypt seit wenigen Stunden (!) E-Mails an die Accounts versendet, deren Zertifikate betroffen sind (natürlich nur wenn eine Mailadresse beim Let's-Encrypt-Account hinterlegt ist).
Die Frist für den Zertifikatsablauf endet am 04.03.2020 um 00:00 UTC (also 01:00 MEZ).

Wir haben die Liste der betroffenen Zertifikate heruntergeladen (3.048.289) und machen derzeit folgendes:

• wir bereiten einen REST-Webservice unter http://www.liveconfig.com vor, dem eine Liste an Seriennummern übergeben werden kann und der dann eine Liste der davon betroffenen Seriennummern zurückgibt
• wir bauen in LiveConfig eine Funktion ein, die beim Start von LC eine Liste aller Zertifikate des betroffenen Zeitraums zusammenstellt und über den o.g. Webservice abgleicht
• zeitgleich wird es eine Funktion in LC geben, um eine Neuausstellung der betroffenen Zertifikate anzustoßen

Wir arbeiten mit Hochdruck an der Sache. Über den Fortschritt werden wir in diesem Thread informieren.

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.28, 7.3.15 und 7.4.3 aktualisiert.

Viele Grüße

-Klaus Keppler

(PS: die Wiki-Seite mit den zusätzlichen PHP-Versionen wird in ca. 3 Wochen komplett ersetzt, die Links werden daher nicht mehr manuell gepflegt)

Um das noch klarzustellen: in PHP 7 gibt es keinen Mechanismus, um hochgeladene Dateien automatiscn (erzwungen) zu scannen. Suhosin für PHP 7 hat leider nie das Alpha-Stadium verlassen.

Der Upload-Scan ist über die suhosin-Erweiterung realisiert.

Ich habe das eben mal unter Debian 10 mit PHP 5.6.40 getestet - eine Textdatei und einmal die Eicar-Testsignatur hochgeladen. Die Virus-Erkennung hatte geklappt, die andere Datei wurde fehlerfrei angenommen.

- wie läuft PHP bei Ihnen? FPM oder FastCGI?
- was passiert, wenn Sie als Web-User das uploadscan-Script ausführen?
(also z.B. mit "su -s /bin/bash <Vertrag>" in einen User wechseln, dann uploadscan.sh mit einer Datei innerhalb des User-Webspaces ausführen)
- klappt der File-Upload mit anderen PHP-Versionen?

Also, wenn ich in Google die Begriffe

liveconfig dane tlsa

eingebe, dann erhalte ich diese Seite als ersten Treffer...

Mit LiveConfig v2.9.2 wird es auch möglich sein, Wildcard-Domains bei den Postfach-spezifischen Blacklists/Whitelists anzugeben - zum Beispiel *.example.org oder sogar *.tld.

Viele Grüße

-Klaus Keppler

Als Workaround (wenn man den Stick nicht zur Hand hat): das Passwort + OTP zusammen eingeben (also den OTP-Code direkt ans Passwort dranhängen).

Wir haben diesen Effekt mit neueren Browsern auch schon beobachtet und das auf die ToDo-Liste gesetzt.

Viele Grüße

-Klaus Keppler

Zitat von aziegler

seit wann gibt es denn eine domainname.httpd.conf, hast du einen Link für mich?

Changelog zu Version 2.8.0:

Zitat

Unterstützung individueller Apache-Konfigurationsanweisungen pro Domain (/var/www/<Vertrag>/conf/<Domain>.httpd.conf)

Die von LiveConfig erzeugte Mobileconfig verwendet als "PayloadIdentifier" den Namen des Mailservers.
Das führt dann vermutlich zum Ersetzen.

Wir werden das mit dem kommenden Update (v2.9.2) durch die E-Mail-Adresse ersetzen - damit sollte das eindeutig bleiben.

Bis dahin müssten mehrfache Adressen auf dem selben Mailserver ggf. manuell auf dem iPhone angelegt werden.

Viele Grüße

-Klaus Keppler

Ich beende die Diskussion an dieser Stelle.

Die gewünschte Funktion wird es (um des Friedens willen) geben, aber natürlich optional und standardmäßig nicht aktiviert.

Wir raten aus mehrfach genannten Gründen dringend vom automatischen Verschieben verdächtiger Mails in einen Spam-Ordner ab.

Thread hiermit geschlossen.

Ich habe da was gefunden... das neue Limit sollte nun bei 2 Buchstaben liegen.
Ich weiß aber nicht ob Begriffe aus 3 Zeichen bereits im Index sind - das müssen wir mal beobachten (vBB scheint selber einen Suchindex zu erzeugen, unabhängig von der dahinterstehenden Datenbank)

Viele Grüße

-Klaus Keppler