SSL Zertifikatsproblem

A

Andi1977hb

New Member
Hallo,
ich bin ganz Neu hier im Forum und hoffe meine Frage/Problem an dieser stelle hier richtig zu positionieren...ansonsten bitte verschieben

Folgendes: Ich bin derzeit technischer Verwalter eines Projekts (ein Internetradio). Leider hat unser Projekt seit längerer Zeit keinen Serveradministrator der unsere Systeme pflegt. Daher wird der Betrieb mit eigenem wissen versucht aufrecht zu erhalten, was aber bei der komplexität unserer System einen oftmals an die eignen Grenzen stossen lässt..

Jetzt zum aktuellen Problem: Wir haben eine sogenannte eigen Programmierte Moderatoren-Verwaltung. In dieser gibt es unter anderem die Möglichkeit für unsere Moderatoren den "AutoDJ" per klick zu starten oder zu stoppen. (Die Verwaltung liegt in einer VM und der AutoDJ liegt auf einem dedicated Server).

Seit dem 30.09.21 ist nun das Problem das eben diese Funktion gestört ist, klickt man in der Verwaltung auf den Menüpunkt "AutoDJ" erscheint eine Fehlermeldung (siehe Foto).

Was ich mit meinem halbwissen rauslese, da es sj auch ganz oben steht, besteht wohl ein Problem mit einem abgelaufenen "SSL-Zertifikat". Im Netz habe ich gelesen das da in zusammenhang mit Let's Encrypt wohl genau zum Datum 30.09. Probleme geben sollte... Kann das auf meinen Fehler hindeuten ? Wenn Ja, hab ich leider keine genaue Ahnung was ich jetzt machen muss um das wieder gerade zu biegen.

Was ich geprüft habe ist ob alle Let's Encrypt Zertifikate aktuell und gültig sind, das sind sie laut certbot.. (auf der VM wo die Verwaltung läuft). Auf dem Server wo der AutoDJ läuft gibt es keine Let's Encrypt Zertifikate..

Hat da eventuell jemand Ahnung und kann mir weiterhelfen ?
Wäre wunderbar .. :)
 

Attachments

  • error_modi.PNG
    error_modi.PNG
    129.2 KB · Views: 209
Auf dem anderen System, auf dem die Moderatoren arbeiten, sind da alle Zertifikate aktuell für das Programm curl? Die cUrl-Bibliothek konnte nämlich nicht die Gültigkeit überprüfen. Wird wohl irgendeine Datei cacert.pem sein. ca-bundle... o.ä. wird das Package auf einigen Linuxen genannt. Schau mal in den Packagemanager des Linux im Zusammenhang mit curl/libcurl.

Ich kann nicht dein Linux entziffern, um gerade weiter zu helfen.
 
Last edited:
Hi, Danke erstmal für Deine Antwort.
Wie kann ich überprüfen ob die Zertifikate für curl aktuell sind ?
Auf dem System auf dem die Moderatoren arbeiten (wo also der Fehler in der Verwaltung auftaucht) läuft Ubuntu 14.04.6 LTS

Update:
habe auf dem System wo die Verwaltung läuft mal den Befehl 'curl -Iv https://xxx.xxx-radio.de ausgeführt...

Connected to xxx.xxx-radio.de (1xx.xx.xx.xx3) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* Closing connection 0
curl: (60) SSL certificate problem: certificate has expired

Heißt für mich mit meinem halbwissen: Ja auf diesem System ist ein Problem mit einem SSL Zertifikat für curl ?!
 
Last edited:
Ubuntu 14 ist sehr alt, Supportende wurde 2019 erreicht.

Das Paket ca-certificates, von wann ist das denn auf jeweils jedem Server?
sudo dpkg -l ca-certifcates

Prüfe doch mal bei jedem System in der Shell (Domain anpassen):
curl -v --cert-status https://moderatoren-server.tld

ich denke mal es ist das hier:

USN-5089-2: ca-certificates update | Ubuntu security notices | Ubuntu

Ubuntu is an open source software operating system that runs from the desktop, to the cloud, to all your internet connected things.
ubuntu.com ubuntu.com

Bug #1944481 “Distrust “DST Root CA X3"" : Bugs : ca-certificates package : Ubuntu

[Impact] * ca-certificates trusts the letsencrypt CA certificate "ISRG Root X1" * ca-certificates also trusts the CA certificate "DST Root CA X3" which cross-signs letencrypt CA * "DST Root CA X3" is about to expire, however it has issued an updated cross-signature to letsencrypt beyond its...
bugs.launchpad.net bugs.launchpad.net

Ob das ca-certificates package von Xenial (nächste Version des Ubuntu nach Trusty) passt, das weiß ich nicht.
Ich denek aber du weißt wie du das testen kannst, oder?

Falls nicht, frage mal falls aufwändiger nach bezahlter Hilfe auf Suche
 
Last edited:
GwenDragon said:
Ubuntu 14 ist sehr alt, Supportende wurde 2019 erreicht.
Click to expand...
Ja da hast Du recht, da ist auch geplant das zu überarbeiten..aber ohne Fachkundige Hilfe wird das nix :/
GwenDragon said:
Das Paket ca-certificates, von wann ist das denn auf jeweils jedem Server?
sudo dpkg -l ca-certifcates
Click to expand...
gebe ich das ein kommt:
~ # sudo dpkg -l ca-certifcates
dpkg-query: no packages found matching ca-certifcates
GwenDragon said:
Prüfe doch mal bei jedem System in der Shell (Domain anpassen):
curl -v --cert-status https://moderatoren-server.tld
Click to expand...
~ # curl -v https://xxx.xxx-radio.de
* Rebuilt URL to: https://xxx.xxx-radio.de/
* Hostname was NOT found in DNS cache
* Trying 1xx.xx.xx.xxx...
* Connected to xxx.xxx-radio.de (1xx.xx.xx.xxx) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* Closing connection 0
curl: (60) SSL certificate problem: certificate has expired
More details here: http://curl.haxx.se/docs/sslcerts.html

https://moderatoren-server.tld
GwenDragon said:
ich denke mal es ist das hier:

USN-5089-2: ca-certificates update | Ubuntu security notices | Ubuntu

Ubuntu is an open source software operating system that runs from the desktop, to the cloud, to all your internet connected things.
ubuntu.com ubuntu.com

Bug #1944481 “Distrust “DST Root CA X3"" : Bugs : ca-certificates package : Ubuntu

[Impact] * ca-certificates trusts the letsencrypt CA certificate "ISRG Root X1" * ca-certificates also trusts the CA certificate "DST Root CA X3" which cross-signs letencrypt CA * "DST Root CA X3" is about to expire, however it has issued an updated cross-signature to letsencrypt beyond its...
bugs.launchpad.net bugs.launchpad.net

Ob das ca-certificates package von Xenial (nächste Version des Ubuntu nach Trusty) passt, das weiß ich nicht.
Ich denek aber du weißt wie du das testen kannst, oder?

Falls nicht, frage mal falls aufwändiger nach bezahlter Hilfe auf Suche
Click to expand...
 
Eigentlich solltet ihr auf ein aktuelleres Ubuntu upgraden, denn ohne Sicherheitsupdates werdet ihr einen angreifbaren Server haben. Den Ärger wollt ihr bestimmt nicht.
 
GwenDragon said:
Eigentlich solltet ihr auf ein aktuelleres Ubuntu upgraden, denn ohne Sicherheitsupdates werdet ihr einen angreifbaren Server haben. Den Ärger wollt ihr bestimmt nicht.
Click to expand...
klar, da stimme ich Dir zu. Soll wie erwähnt auch gemacht werden, aber dafür brauchen wir erst wieder einen Serveradmin...
 
GwenDragon said:
was zeigt denn: sudo apt-search ca-certificates bzw. sudo apt search ca-certificates
Click to expand...
Sorting... Done
Full Text Search... Done
ca-certificates/trusty-updates,trusty-updates,now 20170717~14.04.2 all [installed]
Common CA certificates

ca-certificates-java/trusty,trusty 20130815ubuntu1 all
Common CA certificates (JKS keystore)
 
Zu alt wie du siehst. Da ihr bestimmt keinen speziellen EMS-Service-Vertrag mit Canonical oder eurem Serverhoster habt, gibt es da ein neueres Update nicht mehr.

Rein theoretisch und auf auf dein Risiko
Ich übernehme keine Haftung.

1. ca-certificates manuell holen
wget http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20210119~16.04.1_all.deb

2. Um zu testen ob sowas wirklich ohne Probleme zu installieren ginge:
sudo dpkg --dry-run -i ./ca-certificates_20210119~16.04.1_all.deb

3. Wenn Punkt 2. ohne irgendwelches Fehler vonstatten ging dann:
sudo dpkg -i ./ca-certificates_20210119~16.04.1_all.deb
 
GwenDragon said:
Zu alt wie du siehst. Da ihr bestimmt keinen speziellen EMS-Service-Vertrag mit Canonical oder eurem Serverhoster habt, gibt es da ein neueres Update nicht mehr.

Rein theoretisch und auf auf dein Risiko
Ich übernehme keine Haftung.

1. ca-certificates manuell holen
wget http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20210119~16.04.1_all.deb

2. Um zu testen ob sowas wirklich ohne Probleme zu installieren ginge:
sudo dpkg --dry-run -i ./ca-certificates_20210119~16.04.1_all.deb

3. Wenn Punkt 2. ohne irgendwelches Fehler vonstatten ging dann:
sudo dpkg -i ./ca-certificates_20210119~16.04.1_all.deb
Click to expand...
Nein, wir haben keinerlei Service Vertrag mit irgendwem...

Habe es nach Deiner Anleitung durchgeführt und danach die Maschine neu gestartet.. Leider bleibt der Fehler immer noch genauso...
Zum prüfen dann nochmal 'sudo apt search ca-certificates gemacht' mit dem Ergebnis das es wohl aktualisiert wurde
 

Attachments

  • ca.PNG
    ca.PNG
    33 KB · Views: 180
Sind denn auf beiden servern die Zertifikate wirklich aktuell?

1. Was gibt das hier in der shell:
sudo dpkg-reconfigure ca-certificates

sudo update-ca-certificates

2. Was zeigt dann die Abfrage mit curl in der shell?
Also auf beide Domains!
 
Last edited:
GwenDragon said:
Sind denn auf beiden servern die Zertifikate wirklich aktuell?

1. Was gibt das hier in der shell:
sudo dpkg-reconfigure ca-certificates

sudo update-ca-certificates

2. Was zeigt dann die Abfrage mit curl in der shell?
Click to expand...
Zu 1.: führt eine Grafische Oberfläche aus und fragt: "Trust new certificates from certificate authorities?", beantwore ich mit ja, dann kann ich auswählen weleche Zertifikate aktiviert werden sollen... sind alle mit * gekennzeichnet, bestätige ich mit OK.. Antwort dann: Updating certificates in /etc/ssl/certs .... 0 added, 0 removed , done

ausführen von sudo update-ca-certificates
Ergebnis: Updating certificates in /etc/ssl/certs .... 0 added, 0 removed , done

Zu2. Abfrage ergibt leider noch immer Zertifikat abgelaufen...

Auf dem anderen System wo der eigentliche Auto DJ läuft, haben wir Debian 4.9.144-3.1 laufen, dort scheint auch etwas nicht aktuell zu sein....
 

Attachments

  • deb.PNG
    deb.PNG
    14.5 KB · Views: 152
Andi1977hb said:
Auf dem anderen System wo der eigentliche Auto DJ läauft haben wir Debian 4.9.
Click to expand...
Was? Seit 11 Jahren bekommt Debian 4 keine Updates mehr. Sowas erschreckt mich schon, wenn ihr so veraltete Systeme habt, das öffnet Hackern riesige Einfallslücken.
 
Viel Glück morgen.
Solche Updates sind nicht einfach, aber ich warnte ja schon früher dich vor Risiken be Updates.
Am besten vor solchen Update Backups der Server, damit du zurück spielen kannst, wenn was nicht mehr geht.
 
Nabend... hat das mit deinen Updates geklappt und ist nun wieder Ruhe??

Ich hab nämlich einen Server, bei dem scheint es auch seit dem 30.09. aufgrund des Root CA von Lets Encrypt Probleme zu geben. Heute hab ich auf meinem Test Notebook Windows 11 und Nextcloud installiert und Nextcloud mag nämlich mein mit Lets Encrypt erstelltes Zertitifikat nicht. Firefox und Chrome scheinen es zu schlucken, aber Nextcloud selbst, nimmt es nicht.
 
Browser nutzen einen eigenen unabhängigen Zertifikatsspeicher und nicht den vom OS.
(Nahezu) Alle andere Software (wie etwa PHP/curl bei Nextcloud) nutzt den Zertifikatsspeicher des OS.

Deshalb machen Zertifikatstests mit Browsern meistens nicht viel Sinn.

Bei den betroffenen Systemen muss zwingend der Zertifikatsspeicher des OS aktualisiert werden, meist sind es die Pakete mit den Mozilla-CA-Certs welche jede Distribution/jedes BSD unterschiedlich benennt. Die Doku der jeweiligen Distro / BSD hilft hier jedem weiter...


Wer Pest^WPlesk und Co verwendet, der hat möglicherweise weitergehende Probleme, aber damit darf sich dann der Pest^wPlesk und Co Support rumschlagen, die werden schliesslich dafür bezahlt, ihren Schrott lauffähig zu halten...
 
You must log in or register to reply here.
Back
Top