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:

# 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 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:

# 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

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.

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

/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:

# curl -v https://github.com
*   Trying 140.82.121.4:443...
* Connected to github.com (140.82.121.4) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
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.

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.

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.

# 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.

# 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.

Ich habe nun auch erkannt, dass der Inhalt von dieser /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem nach dem Lauf des Cronjobs das Intermediate CA Cert von Letsencrypt ist.

also das hier : https://letsencrypt.org/certs/lets-encrypt-r3.pem

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:

# 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

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?

Zitat von Sumeragi

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.