Rocky Linux: update_host_certificate.sh zerschießt Zertifikats Setup

  • Ich habe jetzt sehr lange nach einem Problem gesucht:
    Mein erster und bisher einziger Rocky Linux Server (Rocky Linux 9.1 Blue Onyx) hatte immer wieder Probleme, https Verbindungen aufzubauen - zum Beispiel via wget oder curl. Es kamen immer wieder Zertifikatsfehler (unknow authority).

    Nach einem "dnf reinstall ca-certificates" funktionierte es stets wieder.


    Beispiel:


    Code
    # curl https://www.github.com
    curl: (60) SSL certificate problem: unable to get local issuer certificate
    More details here: https://curl.se/docs/sslcerts.html
    
    curl failed to verify the legitimacy of the server and therefore could not
    establish a secure connection to it. To learn more about this situation and
    how to fix it, please visit the web page mentioned above.


    Zuerst dachte ich an einen Bug seitens Rocky Linux, bin hier aber nicht vorangekommen.


    Jetzt bin ich einen Schritt weiter: Es scheint an der wöchentlichen Ausführung von /opt/pdadmin/bin/update_host_certificate.sh zu liegen.

    Dieses Script schreibt das Hostzertifikat nach /etc/ssl/cert.pem (in der Gegend von Zeile 45). Diese Datei ist unter Rocky Linux aber ein Symlink auf /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem und scheint somit eine wesentliche Rolle beim gesamte CA Setup von Rocky Linux zu spielen. Durch dieses Überschreiben geht wohl die ganze Geschichte kaputt, durch das "dnf reinstall ca-certificates" wird das wieder auf Normalstand gebracht und es geht wieder bis zum nächsten Lauf von update_host_certificate.sh


    Vielleicht könnte das PD-Admin Team diese Geschichte prüfen. Ich glaub nicht dass ich hier selbst etwas tun kann, zumal mir der Zweck warum dieses Script das Host Zertifikat nach /etc/ssl/cert.pem kopiert, gar nicht klar ist.

  • Ich habe gerade bemerkt, dass dieses Problem weiterhin (oder wieder) existiert, obwohl laut Release Notes pd-admin v4.107 gefixt.


    Problem ist weiterhin der wöchentliche Cronjob von update_host_certificate.sh, welcher (in der Gegend von Zeile 45) die Datei /etc/ssl/cert.pem (die bei rocky und alma ein symlink ist) überschreibt.


    Mich wundert dass das noch niemand sonst aufgefallen ist.

  • Ich nutze Oracle Linux 8.

    Code
    $ /usr/local/pd-admin2/bin/curl -sI https://github.com | head -1
    HTTP/2 200
    
    $ /usr/bin/curl -sI https://github.com |head -1
    HTTP/2 200
    
    $ ls -al /etc/ssl/cert.pem
    -rw-r--r--. 1 root root 1827 19. Mär 04:04 /etc/ssl/cert.pem

    Weder curl aus der Distribution, noch aus der Serverumgebung hat Probleme wenn die Datei ersetzt wurde. Stellt sich mir die Frage, wenn es an der Datei liegen sollte, wieso tritt das Verhalten nicht auch bei mir auf?

  • Ich kann es mir nur so erklären dass das Setup der ca-certificates bei rocky/alma halt ein anderes ist als bei Oracle. Weil bei ersteren muss es so aussehen:


    Code
    # ls -l /etc/ssl/cert.pem
    lrwxrwxrwx 1 root root 49 Sep 12  2023 /etc/ssl/cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem


    Ist das nicht der Fall, hagelt es Zertifikatsfehler bei Verbindungen zu anderen Servern.
    Derzeit wird diese /etc/ssl/cert.pem aber eben mindestens jeden Sonntag überschrieben von /opt/pdadmin/bin/update_host_certificate.sh aufgrund dieses Cronjobs


    Code
    31   4  * * 0 /opt/pdadmin/bin/letsencrypt --renew 2>&1 | /opt/pdadmin/bin/log.sh dehydrated-renew ; /opt/pdadmin/bin/update_host_certificate.sh


    Mir persönlich ist ein Rätsel, warum die pd-admin Cronjobs überhaupt die /etc/ssl/cert.pem beschreiben. Zumindest ich sehe hierfür keine Notwendigkeit.

  • Ich kann es mir nur so erklären dass das Setup der ca-certificates bei rocky/alma halt ein anderes ist als bei Oracle.

    Wenn man curl mit -v ausführt wird der Pfad von CAfile angezeigt. Ich nehme an bei Ihrem Test wird die curl Version der Distribution verwendet. Bei der curl Binary aus der Serverumgebung wird


    CAfile: /usr/local/pd-admin2/share/curl/curl-ca-bundle.crt


    verwendet. Bei der curl Binary aus der Distribution wird bei mir


    CAfile: /etc/pki/tls/certs/ca-bundle.crt


    verwendet. Dies wird wohl der Grund sein, weshalb es bei mir keine Probleme gibt.

  • Zitat

    CAfile: /etc/pki/tls/certs/ca-bundle.crt


    Das ist interessant, danke für den Hinweis. Das wird bei mir auch so angezeigt.

    Ich muss mir das nochmal genauer ansehen wenn der Fehlerzustand besteht.

  • So, ich hab jetzt mal händisch den Sonntags Cronjob


    Code
    /opt/pdadmin/bin/letsencrypt --renew 2>&1 | /opt/pdadmin/bin/log.sh dehydrated-renew ; /opt/pdadmin/bin/update_host_certificate.sh

    ausgeführt. Danach das Fehlerbild:



    Allerdings scheint meine Spur, dass die Datei /etc/ssl/cert.pem etwas damit zu tun hat, möglicherweise Quatsch zu sein. Weil die betroffene Zeile habe ich testweise in der update_host_certificate.sh auskommentiert. Die Datei blieb bei diesem Testlauf unverändert.


    Somit bin ich weniger schlau als zuvor. Allerdings sehe ich schon das die Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem genau in der Minute des Scriptaufrufs verändert wurde.

  • Bash
    $ ls -al /etc/pki/tls/certs/ca-bundle.crt
    lrwxrwxrwx. 1 root root 49 20. Sep 2023  /etc/pki/tls/certs/ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
    $ ls -al /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
    -r--r--r--. 1 root root 222082 28. Sep 11:52 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

    Bei mir wird die gleiche Datei verwendet. Und diese wurde zuletzt am 28.09.2023 geändert. Auch bei mir wird der gleiche Cronjob jede Woche ausgeführt. Ist jetzt die Frage wieso bei Ihnen die Datei angerührt wird 🤔 Ändert sich auch der Inhalt darin? Was ist vorher und nachher enthalten?

  • Mir ist das auch ein völliges Rätsel. In diesem Update Script wird die Datei meiner Meinung nach nicht angerührt, mit dem Aufruf von letsencrypt vorher ja wohl hoffentlich auch nicht.


    Vor dem Aufruf des Cronjobs ist die Datei 217K groß und enthält eine ganze Menge Certs - wie man es eben bei so einem Bundle erwarten würde.

    Code
    # md5sum /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem # vor aufru
    72f205fe6e0fbe28eed65773e289544d  /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem


    Nach dem Aufruf hat die Datei nur mehr 1,8K und enthält nur mehr eine einzige "-----BEGIN CERTIFICATE-----" Sektion.


    Code
    # md5sum /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem #nach dem Aufruf.
    c92a7db9c0faccd6b3157af32b646f07  /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem


    Ich kenne das Verhalten von bereits von einem völlig anderen Server, da war es exakt gleich. das war ja der Grund warum ich dieses Topic damals begonnen habe. Der Server wurde aber dann nicht mehr benötigt, daher hab ich das nicht weiterverfolgt. Nun habe ich es eben wieder bei einem völlig (mit Ausnahme von pd-admin) jungfräulich aufgesetzten Server.

  • Okay, nach weiterer Analyse kehre ich zu meiner ursprünglichen Theorie zurück. Es hat mit der /etc/ssl/cert.pem zu tun.


    Nach einem dnf reinstall ca-certificates (also wenn wieder alles so ist wie es sein soll) ist diese Datei eben ein Symlink auf die besprochene ca-bundle datei:


    Code
    # ls -l /etc/ssl/cert.pem
    lrwxrwxrwx 1 root root 49 Sep 12  2023 /etc/ssl/cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem


    Im übrigen eben die Datei, auf die eben auch /etc/pki/tls/certs/ca-bundle.crt zeigt, jenes Bundle das zum Beispiel das curl des OS verwendet.

    In /opt/pdadmin/bin/update_host_certificate.sh wird hier in Zeile 45 aber eben das CAcert des Hosts rein ge-catet


    Code: /opt/pdadmin/bin/update_host_certificate.sh
    mkdir -p /etc/ssl/
    cat /opt/pdadmin/sslcerts/$H-cacert > /etc/ssl/cert.pem


    So kommt es eben zur Überschreibung des CA Bundels des OS mit dieser Datei.
    Bei Oracle Linux scheint das kein Problem zu sein, weil dieser Symlink so wohl nicht existiert. Das update Script legt also diese /etc/ssl/cert.pem an, um die kümmert sich dort aber vermutlich niemand weiter.

    Ich hab mich leider durch das ganze Herumtesten zwischendurch mal verwirren lassen und dachte bei einem Testlauf dass ich die Zeile auskommentiert hatte, war aber wohl quatsch.

    Ich werde also fürs erste mal wieder diese Zeile auskommentieren.


    Daniel Bradler, wozu wird das gemacht?

  • Mich wundert dass das noch niemand sonst aufgefallen ist.

    Ich hab auf einem Rocky 8 Server nachgeschaut. Dort tritt das Problem auch nicht auf. Scheint mir erst einmal ein Rocky 9 Problem zu sein.


    Mit der curl Version aus der Serverumgebung sollte dies nicht auftreten. Da die Version auch immer aktuell ist, würde ich als workaround vorschlagen /usr/local/pd-admin2/bin mit vorne in die PATH Variable aufzunehmen. Dann funktioniert curl korrekt.

  • Da die Version auch immer aktuell ist, würde ich als workaround vorschlagen /usr/local/pd-admin2/bin mit vorne in die PATH Variable aufzunehmen. Dann funktioniert curl korrekt.

    Mir geht es gar nicht so um curl, das habe ich nur zur Demonstration des Problems eingebracht.


    Bei einem OS mit zerschossenem CA Tusted Bundle krankt es an allen Ecken und es lässt sich halt generell kaum administrieren.
    yum/dnf bricht ab wegen Zertifikatsfehler, meine Backups zu Backblaze schlagen fehl, und und und. Alles was irgendwie eine verschlüsselte Verbindung nach aussen aufbaut, funktioniert in dem Zustand nicht mehr. Natürlich kann ich bei vielen Tools die Zertifikatsüberprüfung abschalten, aber das ist ja nicht der Sinn der Übung.

  • Dann wäre es wohl besser in dem Skript die Zeile raus zu nehmen, damit der Symlink nicht überschrieben wird. Hilft natürlich erst einmal nur bis zum nächsten Update, aber besser als jede Woche Probleme durch das Überschreiben zu haben.