SSL-Zertifikatsfehler bei selbst-signierten Zertifikaten trotz importierter CA

Hallo Experten,

offenbar gab es jüngst ein Update bei allen möglichen Webbrowsern, an erster Stelle zu Nennen Mozilla Firefox, welches dazu führt, dass selbst erstellte Zertifikate auch DANN zu Zertifikatsfehlern führen, wenn die signierende CA in den Zertifikatsspeicher importiert wurde.
Das ist ein ziemliches Problem bei der Schulkonsole, wenn man auf den Default linuxmuster.net Standardzertifikaten bleibt, die beim setup generiert wurden. Dann erhält man beim Aufruf der Webseite server.linumuster.lan einen Zertifikatsfehler mit wrong domain name, OBWOHL der cn des Zertifikats server.linuxmuster.lan lautet…und es spielt keine Rolle, ob man die CA ins Zertifikat aufnimmt (fullchain) oder nicht. Der Fehler geht nicht weg. Habe ich auch bei anderen selbstgenerierten und signierten Zertifikaten festgestellt…ABER wohlgemerkt…die CA ist in den vertrauneswürdigen Stammzertifizierungsstellen vorhanden! Also dies ist der Fehler nicht…

Jemand eine Idee, außer weiterhin kompetent wirken und guten Eindruck oder langes Gesicht machen?

Liebe Grüße
Thomas

PS: Problem bleibt auch dann bestehen, wenn ich CA und Server-Zert vollständig neu generiere…

Hallo Thomas,

… vorsicht: vielelicht ist es diese Problem: bei Firefox kann man das
Cert nicht mehr dauerhaft installieren, wenn der Browser im privaten
Modus läuft.
Außerdem muß „irgend was Speichern“ unter Einstellungen → Datenschutz
→ Chronik auch an sein (warum auch imemr).
Damit hab ich es am Ende geschfft doch noch ein selbstsigniertes Cert
dauerhaft zu integrieren (also das Cert, nicht die CA).

Hab aber lange rumsuchen müssen …

LG

Holger

Hallo,

das CA/Browser Forum (Zusammenschluss vieler CAs und Browser-Hersteller) hat schon vor vielen Jahren beschlossen, dass der CN (Common Name) des Zertifikats nicht mehr ausschlaggebend sein soll, sondern die Hostnamen (FQDN) im Erweiterungsfeld SAN (Subject Alternative Name). Möglicherweise haben sich neuere Browser-Versionen da jetzt zickiger, wenn nur der CN existiert.

Ein selbstsigniertes Zertifikat ist von keiner CA signiert, sondern selbstsigniert. Dann muss ggf. das Zertifikat selbst in den Speicher für vertrauenswürdige Stammzertifizierungsstellen.

Vielleicht könnt ihr eure Konfiguration vereinfachen, wenn Firefox den Windows-Zertifikatspeicher verwendet. Dazu schaltet man security.enterprise_roots.enabled ein, wie auf Zertifizierungsstellen in Firefox einrichten | Hilfe zu Firefox für Unternehmen beschrieben.

MfG Buster

Hallo,

ich habs gefunden!

Man muss bei der Generierung bzw. Signierung durch die CA die Extentions mit angeben z.B. über ein Extension File:
openssl x509 -req -in newserver.csr -CA cacert.pem -CAkey cakey.pem -CAcreateserial -out newserver.crt -days 720 -sha256 -extensions v3_req -extfile ssl-ext.conf
Die ssl-ext.conf sieht ungefähr so aus:
[v3_req]
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = IP:10.0.0.1, DNS:server.linuxmuster.lan, DNS:server

Erst dann sind die Extensions im signierten Zertifikat drin.

Hallo tjordan,

das ist genau was ich suche, um den neueren Firefox Versionen und Chrome endlich die Zertifikatswarnung wieder abzugewöhnen.

Ich habe aber noch eine Frage. Werden durch das neue Zertifikat irgendwelche Server-Dienste beeinflusst? LDAP usw?

Kannst Du falls das so sein sollte, bitte noch Deine zusätzlichen Schritte beschreiben, damit alles weiterhin funktionsfähig bleibt?

LG

Michael

Hallo Michael,

normalerweise sollte das keine größeren Auswirkungen haben, es sei denn, du generiest die CA neu. Braucht man aber normalerweise nicht.

Gruß
Thomas

Perfekt. Dann werde ich mir das nächste Woche mal vornehmen. :slight_smile:
Herzlichen Dank für die Rückmeldung.

@tjordan
Hallo Thomas,

leider brauche ich doch nochmal Deine Hilfe.

Bisher war es ja IMHO so, dass man vom Linuxmuster-Server die Datei /etc/ssl/private/server.crt im Firefox als Zertifizierungsstelle importiert hat. Daraufhin wurde das Zertifikat dann vom Browser beim Aufruf der Schulkonsole akzeptiert. Dies funktioniert aus den im Thread beschriebenen Gründen nun nicht mehr.

Leider habe ich Schwierigkeiten, Deine beschriebene Lösung umzusetzen.

Die ssl-ext.conf Datei habe ich mit dem von Dir angegebenen Inhalt erstellt und darin die IP und die DNS Namen an meinen LML-Server angepasst.

Woher genau bekomme ich jetzt die anderen Dateien, die Du in dem von Dir aufgeführten Befehl verwendest?

Sind das die Dateien, die auf dem LML-Server in /etc/ssl/private gespeichert sind? Also newserver.csr = server.csr, cacert.pem = server.pem und cakey.pem = server.key?

Wenn ich das so angebe, bekomme ich neue server.crt Datei. Diese kann ich aber nicht wie gewohnt in den Zertifikatsspeicher importieren. Es kommt eine Fehlermeldung, dass es sich nicht um ein Zertifikat für eine Zertifizierungsstelle handeln würde und dieses deshalb nicht importiert werden kann.

Hast Du eine Idee, was ich falsch mache?

LG

Michael

Hallo Michael,

das neue Zertifikat brauchst du ja nicht zu importieren. Das liefert der Webserver aus. Was du generiert hast, ist ja keine CA. Der Server zeigt nur seinen neuen „Ausweis“. Die „ausstellende Behörde“ kennst du bereits. Nur wenn man eine neues CA-Zertifikat („eine Ausweisbehörde“) erstellt, mit muss man die importieren. Sonst bekommst du den typischen Zertifikatsfehler „diese Ausweisbehörde kenne ich nicht, und deswegen Lehne den Ausweis ab“.

Wenn du ein neues Server-Zertifikat erstellt hast, muss man Ajenti Dienst bzw. Schulkonsole neu starten, damit das neue Zertifikat eingelesen und ausgeliefert wird.

Gruß
Thomas

Mit der Hilfe von @tjordan konnte ich das Problem endlich lösen. Nochmals vielen herzlichen Dank dafür!

Wir haben noch die LML 6.2 und ich konnte das LML Skript zur Erstellung neuer Zertifikate so anpassen, dass es die von Thomas vorgeschlagenen Änderungen in die Zertifikate integriert. Endlich zeigen Chrome und Firefox keine Warnungen mehr an.

Falls jemand eine Beschreibung des genauen Vorgehens braucht, bitte einfach nachfragen.

Hallo!

Es wäre schön wenn du es hier posten würdest. Danke!

Beste Grüße

Thorsten

Hallo,

mich würde das auch sehr interessieren.
Freundliche Grüße
Christoph

Hallo!

Hier mein Vorgehen:

Ich wollte das Linuxmuster-Skript nicht direkt verändern, deshalb habe ich mir in /root/ ein neues Verzeichnis cert_new angelegt.

cd /root
mkdir cert_new
cd cert_new

Dann habe ich das Linuxmuster-Skript kopiert,
cp /usr/share/linuxmuster/scripts/create-ssl-cert.sh .

und das von @tjordan beschriebene extension file angelegt und auf meine Schule angepasst.
nano ssl-ext.conf

[v3_req]
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = IP:10.16.1.1, DNS:server.sbbs-leinefelde.lokal, DNS:server

Dann das Skript angepasst:
nano create-ssl-cert.sh

Inhalt:

#!/bin/sh
# create ssl certificate script
# for linuxmuster.net
# 04.11.08 Thomas Schmitt <tschmitt@linuxmuster.de>
#
# 10.11.22 modified by Michael Wehr to generate certificate including v3_req extensions
# thread: https://ask.linuxmuster.net/t/ssl-zertifikatsfehler-bei-selbst-signierten-zertifikaten-trotz-importierter-ca/9021

# modify this to your needs
days=3650
country="DE"
state="TH"
location="Leinefelde"
schoolname="sbbs_eichsfeld"
section="linuxmuster.net"
[ -z "$myname" ] && myname="server.sbbs-leinefelde.lokal"
mymail="administrator@sbbs-leinefelde.lokal"

# from here on nothing has to be modified
[ -z "$SSLDir" ] && SSLDir=/root/cert_new/private
SSLCertificateFile=$SSLDir/server.crt
SSLCertificateKeyFile=$SSLDir/server.key
SSLCertificateCSRFile=$SSLDir/server.csr
SSLPemFile=$SSLDir/server.pem

echo
echo "################################################################"
echo "############## creating selfsigned certificate #################"
echo "################################################################"
echo
echo "Enter your fully qualified ServerName at the Common Name prompt."
echo
openssl genrsa -out $SSLCertificateKeyFile 1024
chmod 600 $SSLCertificateKeyFile
echo -e "$country\n$state\n$location\n$schoolname\n$section\n$myname\n$mymail\n\n\n" | openssl req -new -key $SSLCertificateKeyFile -out $SSLCertificateCSRFile
openssl x509 -req -days $days -sha256 -in $SSLCertificateCSRFile -signkey $SSLCertificateKeyFile -out $SSLCertificateFile -extensions v3_req -extfile ssl-ext.conf
mv -f $SSLPemFile $SSLPemFile.old 2> /dev/null 1>/dev/null
cp $SSLCertificateKeyFile $SSLPemFile
cat $SSLCertificateFile >> $SSLPemFile
if [ "$SSLDir" = "/root/cert_new/private" ]; then
  chmod 640 $SSLPemFile
  chown root:ssl-cert $SSLPemFile
  chmod 750 $SSLDir
  chown root:ssl-cert $SSLDir
fi
echo
echo "ssl certificate was created in $SSLDir and is $days days valid."
echo

exit 0

Die Zeilen [ -z "$SSLDir" ] && SSLDir=/root/cert_new/private und if [ "$SSLDir" = "/root/cert_new/private" ]; then zu verändern ist vermutlich nicht wirklich nötig, aber ich wollte nicht, dass meine alten Zertifikate einfach so überschrieben werden. Deshalb der neue Speicherort im home von root.

Die entscheidende Änderung ist der Einbau der von Thomas vorgeschlagenen zusätzlichen Parameter in der Zeile zum Erzeugen der Zertifikate (-sha256 und -extensions v3_req -extfile ssl-ext.conf):

openssl x509 -req -days $days -sha256 -in $SSLCertificateCSRFile -signkey $SSLCertificateKeyFile -out $SSLCertificateFile -extensions v3_req -extfile ssl-ext.conf

Danach kann man das Skript ausführen und erhält im Unterordner private die neuen Zertifikate.
./create-ssl-cert.sh

Nachdem ich ein Backup der alten Zertifikate im Ordner /etc/ssl/private/ erstellt hatte, habe ich sie durch die neuen Zertifikate ersetzt und den Server neu gestartet. Ich habe bisher keine negativen Auswirkungen an unserem Server durch die Änderung feststellen können. Trotzdem geschieht das Ganze natürlich auf eigenes Risiko. Bitte erstellt unbedingt vorher ein Backup/Snapshot usw. Ich kann keine Verantwortung übernehmen, falls etwas schief läuft.

Anschließend ist noch die Windows-Seite zu bearbeiten:
Dafür importiert man das server.crt (wie bisher auch) in den Windows-Zertifikatsspeicher für Vertrauenswürdige Stammzertifizierungsstellen. IE, Edge und Chrome sollten dann keinen Zertifikatsfehler mehr anzeigen.

Firefox verwendet normalerweise seinen eigenen Zertifikatsspeicher. Aber dort konnte ich das Zertifikat leider nicht installieren. Es half schließlich nur, über die GPOs für Firefox einzustellen, dass er ebenfalls den Windows Zertifikatsspeicher verwenden soll. Danach wurde auch vom Firefox das importierte Zertifikat akzeptiert und die Fehlermeldungen waren Geschichte. Zum Schluss natürlich nicht vergessen ein neues Image zu erstellen.

Ich hoffe ich habe keinen Schritt vergessen und konnte helfen das Problem auch für andere zu lösen. Wenn noch etwas unklar ist, fragt gerne nach.

LG

Michael

1 „Gefällt mir“

Hallo Michael,

Danke! :+1:

Beste Grüße

Thorsten

Hallo,

auf diesen alten Thread nochmal eine Nachfrage - weil das Problem irgendwie erst jetzt bei uns aufschlägt - bisher konnte man in Firefox ja eine Ausnahme hinzufügen, das geht jetzt nicht mehr. (Mit Chromium geht es noch)

Den Lösungsvorschlag von tjordan:

Ich führe das auf dem Server aus, mach ein ajenti restart, und danach akzeptiert Firefox von sich aus das Zertifikat, ohne dass ich an den einzelnen Firefoxen der User irgendwas einstellen muss? Wie kann ich vorher das alte Zertifikat sichern, damit ich mir dabei nichts zerschieße?

Viele Grüße,
Stefan