Beiträge von TCRserver


    Mal in den Ordner "/etc/ssl/certs" wechseln und dort "ls -la | grep 'ca.crt' | grep '\->'" ausführen. Es sollten dann Verlinkungen sichtbar werden, die man löschen muss. Danach funktioniert das mit Let's Encrypt Zertifikaten wieder.


    Stimmt! Ich habe mir die Deltas zwischen den Servern angeschaut und alle problematischen Server hatten als xxxxxx.0 folgendes Zertifikat enthalten:


    Let's Encypt X3

    Code
    -----BEGIN CERTIFICATE-----
    MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
    MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
    DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
    ....


    Sobald diese Verlinkung gelöscht wird, nutz zumindest CURL wieder die korrekte Kette.
    Ich vermute das ist ein "Feature", dass hier nicht die komplette Kette abgearbeitet, sondern nur der erste Pfad und dann mit einem Fehler abgebrochen wird.


    OpenSSL streikt aber weiterhin noch.

    Nach einer langen Debug Nacht bin ich einen Schritt weiter aber habe noch keine Lösung!


    Ein simpler CURL Test zeigt auf, dass ein Teil unsere Server ein Problem mit dem ISRG Root X1 Zertifikat hat.
    Alle Server sind dank SaltStack absolut identisch! Aber trotzdem haben einige Server das Problem, dass sie das neue Zertifikat nicht nutzen.


    Der Fehler äußert sich zum Bsp. darin, dass roundcube keine Verbindung mit dem Mailserver herstellen kann.
    (Dazu muss natürlich der Mailserver mit einem LE Zertifikat abgesichert sein. Wird ein alternatives Zert. verwendet, funktioniert es wieder.)
    Log von RC:

    Code
    SMTP Error: Connection failed: Failed to connect socket: fsockopen(): unable to connect to ssl://smtp.domain.de:465 (Unknown error)


    Test mit CURL auf valid-isrgrootx1.letsencrypt.org


    Testschritt 2 - kann OpenSSL auf das Zertifikat zugreifen:

    Code
    # openssl x509 -in ISRG_Root_X1.crt -noout -text
    Can't open ISRG_Root_X1.crt for reading, No such file or directory
    140091262317696:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('ISRG_Root_X1.crt','r')
    140091262317696:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:
    unable to load certificate


    >> NEIN


    Ist das System kompatibel?

    Code
    # openssl version
    OpenSSL 1.1.1d  10 Sep 2019


    OpenSSL >= 1.1 wird als kompatibel gelistet


    Code
    # cat /etc/*release
    PRETTY_NAME="Debian GNU/Linux 10 (buster)"
    NAME="Debian GNU/Linux"
    VERSION="10 (buster)"
    
    
    # apt list --installed ca-certificates
    ca-certificates... 20200601~deb10u2 all  [installiert]


    Aktuelles CA Bundle ist installiert


    Einmal checken ob das Zertifikat via dpkg konfiguriert wurde (* beim entsprechenden Zertifikat)

    Code
    # dpkg-reconfigure ca-certificates


    >> JA


    Ist das ISRG Root X1 Zertifikat auch wirklich installiert?!

    Code
    # awk -v cmd='openssl x509 -noout -subject' '
        /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt
    ...
    Subject: O = Digital Signature Trust Co., CN = DST Root CA X3
    ...
    subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
    ...


    >> JA


    Ist das Zertifikat auch wirklich in /etc/ssl/certs/ca-certificates.crt enthalten?

    Code
    grep 'MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw' /etc/ssl/certs/ca-certificates.crt


    >> Ja


    Und jetzt gehen mir im Moment die Ideen aus.

    Konkretes Beispiel aus unseren Support Tickets:
    Windows 10 20H2
    iPhone 12 (keine Ahnung welches OS)


    Aber es ist immer eine Drittsoftware im Spiel!
    Die vermutlich ggü. einer alten OpenSSL Bibliothek gelinkt ist.


    Und es trifft nicht LiveConfig! Sondern nur Webseiten! Also kein wirkliches LC Problem.


    Mein Workaround oben führt auch eher zu unerwünschten Querwirkungen und nicht ans Ziel.
    Warum auch immer es bei einem Kunden geholfen hat.


    Auf Serverseite können wir vermutlich echt nichts machen, außer eben von LE weg zu wechseln solange bis es sich beruhigt hat und die meisten Anwendungen aktualisiert wurden.

    Bei uns ruckelt das Internet heute auch etwas (um heise.de mal zu zitieren)


    Die Probleme mit den Ablauf des LE Zertifikates scheinen doch größer zu sein als erwartet.
    Ein Muster in den betroffenen Geräten können wir nicht erkennen. Es sind aber in allen Fällen aktuelle Geräte mit aktueller Software!


    Eine Lösung die zumindest vereinzelt hilft, aber nicht praktikabel für große Massenupdates ist:

    Code
    # Debian/Ubuntu
    # entfernt, weil Querwirkungen


    - Server neu starten (evtl. unnötig)
    - Zertifikat löschen und neu ausstellen


    Danach ist auch der Anzeige Fehler in LC behoben, bei dem jeweiligen Zertifikat.


    Haben das sogar im Blog gepostet und verweisen alle Kunden bei Problemen auf diesen Artikel: https://blog.aditsystems.de/20…obleme-durch-spamversand/


    Sehr guter Artikel! Respekt und Anerkennung, da hat sich jemand echt richtig Mühe gegeben. :)


    Bounce Mails nach Mattermost zu schicken ist auch eine gute Idee. Muss ich mal überlegen wie wir so etwas in unsere Prozesse einbauen können. Kleines Skript was uns eine Nachricht an Telegram schickt... hmm... *grübel*

    Ich kann das Vorgehen von antondollmaier bestätigen.
    Weiterleitungen zu hotmail und Co. verbieten, jeder einzelnen SPAM Meldung von MS nachgehen, die Ursache klären und beseitigen.
    Anmeldung beim SNDS und beim Junk Mail Reporting Programm sollten natürlich auch sein.
    Und ganz zur Not, auch mal einen Kunden freundlich aber bestimmt auf einen Fehler hinweisen und eine Lösung anbieten.


    Kostet alles zusammen viel Manpower aber es hilft.

    Ist bei uns auch so. Mir sagt der Name aber was, ich hatte mal eine Frist sehr deutlich überschritten... aber er war trotzdem nicht unhöflich. Ich hatte nur die Hoffnung er veröffentlicht seine Abhandlungen. Vielleicht mal direkt anschreiben und Fragen.

    Hi.


    Das ist ein Thema für die AGB. Du hat u.A. auch die Pflicht (soweit möglich und zumutbar), Deine Kunden vor Schäden zu schützen.
    Herr Friemel von der Bundesnetzagentur hat da eine nette Abhandlung dazu verfasst und bei uns das Ganze im Rahmen des "Prüftermin Umsetzung des Sicherheitskonzeptes" so als Korrekt abgenommen.


    Gruß Ralf


    Gibt es dazu zufällig einen Link?
    Ich bin zu doof es zu finden und würde die Abhandlung gerne mal lesen.

    Die Frage ist halt auch, wie professionell ist es heute noch, Mails überPHP mail() zu versenden?!
    Wir unternehmen alle möglichen Anstrengungen um uns gegen SPAM zu schützen, DKIM ein zu bauen, usw. und dann versendet jede Wordpress Installation Mails via php anstatt sauber über einen korrekt konfigurierten Mailserver zu versenden...


    Oder die beliebten Kontaktformulare.... Kunde jammert über unmengen von SPAM die sein eigenens uraltes Kontaktformular an ihn sendet.

    Wenn ich es noch richtig im Kopf habe, dann war es irgendwas im Zusammenspiel mit dem syslog^bzw. dem postrotate Befehl.
    Betroffen waren bei uns nur Systeme die ein Debian 9 auf 10 Upgrade bekommen haben.


    So aus dem Kopf raus:
    Edit: /etc/logrotate.d/rsyslog


    suche nach:

    Code
    postrotate
                    invoke-rc.d rsyslog rotate > /dev/null
            endscript


    und ersetze durch:

    Code
    postrotate
                    /usr/lib/rsyslog/rsyslog-rotate
            endscript


    Aber wirklich aus dem Kopf raus und ohne Gewähr!

    Verwendet von euch noch jemand sourceDESK?
    Wir nutzen es seit einem Jahr mit gemischten Gefühlen.


    Nur seit gut 3 Wochen hören wir nichts mehr von der Firma hinter sourceDESK.
    Tickets werden nicht bearbeitet, Zahlungen nicht verbucht und somit werden auch akute Probleme nicht mehr gelöst.


    Um da eigentlich Thema nochmal auf zu greifen:
    Hat jemand Erfahrungen mit HostBill?

    Ich zitiere mal aus einer Mail die wir von einem unserer Registrare bekommen haben:


    Zitat


    Bei allen Produkten, die über die Smart-NIC GmbH bzw. das Domain-Bestellsystem bezogen werden, handelt es sich unserer Auffassung nach um Dienstleistungen (insbesondere die Registrierung und Verwaltung von Internet Domains). Diese Dienstleistung ist unteilbar und wird üblicherweise im Sinne von § 13 UStG mit Registrierung bzw. Verlängerung der Domain erbracht. Die weitere Bereitstellung von Verwaltungsmöglichkeiten ist eine reine Nebenpflicht und wird darüber hinaus über die monatliche Grundgebühr für den jeweiligen Leistungszeitraum berechnet. Daraus abgeleitet werden wir die Umsatzsteuer auf unseren Rechnungen gemäß dem Zeitpunkt der Leistungserbringung ausweisen.


    Wir bitten zu beachten, dass dies keine (steuer-)rechtliche Beratung darstellt und ersuchen alle Kunden, die für ihren Geschäftsbetrieb geltenden steuerlichen Verpflichtungen eigenständig zu prüfen.


    Das deckt sich so ziemlich zu der Meinung von Herr Keppler bzgl. Domains.
    Aber (hoffentlich) ganz korrekt kann es nur der Steuerberater sagen ;)