Beiträge von kk

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

Uh, gute Frage. Wenn man das im vBulletin irgendwo abschalten kann machen wir das gerne (ich schaue mich später gerne noch mal im Backend um).

Wir planen übrigens das alte vBB in einigen Monaten durch ein neues Board zu ersetzen.

Zitat von Danny Patterson

Es steht doch ganz klar das es einen ersten Ausblick (wenn alles Glatt geht) mit der kommenden 2.9.2 gibt?!

Exakt.
Um genau zu sein: der Backup-Service selbst (lcbackup) ist tatsächlich schon fertig und wird auch seit v2.9.0 schon installiert (aber noch nicht aktiviert). Wir arbeiten aktuell "nur" noch an der Konfiguration der Backups. Und das ist in der Tat wesentlich komplexer als "nur mal nen Cron-Job einzurichten"...

Vorab schon mal ein paar Worte zu unserem System:
das Backup wird durch einen separaten Prozess durchgeführt (lcbackupd). Die einzelnen Backupjobs laufen in separaten Threads - die Anzahl der gleichzeitigen Threads ist konfigurierbar (kann man also dann je nach Serverleistung/-Last anpassen).
Ebenso ist frei konfigurierbar, zu welchen Zeiten welche Backups erzeugt werden - so kann man z.B. einmal täglich ein Vollbackup erstellen, und alle vier Stunden die Datenbanken sichern usw.
Damit Kunden den Server nicht "abschießen", ist ebenfalls konfigurierbar, ob Kunden ggf eine gewisse Zeit abwarten müssen bis sie ein neues Backup anstoßen können (um nicht alle zwei Minuten ein Backup zu erstellen
Last but noch least ist die Anzahl der vorgehaltenen Backups ebenfalls frei konfigurierbar - sowohl der vom System erstellten (automatischen) Backups, als auch der vom Kunden erzeugten.

Wenn alles glatt geht gibt's einen ersten Ausblick bereits mit dem kommenden Update v2.9.2.

Viele Grüße

-Klaus Keppler