LCOS Version 9.24 RU3 => Benutzerzertifikat für HTTPS/SSL

[GrandDixence]

Beim Wechsel von LCOS 9.20.0566Rel auf 9.24.0153RU3 musste ich feststellen, dass der LANCOM-Router nicht mehr das von mir hochgeladene Benutzerzertifikat für die HTTPS-Verbindung zum Webconfig verwendet. Mit LCOS 9.24.0153RU3 wird nur das Geräte-interne LANCOM-SSL-Serverzertifikat für den verschlüsselten Webconfig-Zugriff verwendet.

Beim Zugriff auf das verschlüsselte Webconfig (https://192.168.3.1) unter LCOS 9.24.0153RU3 erscheint im Webbrowser nur eine entsprechende Fehlermeldung.

Nach dem Wechsel zurück auf die alte LCOS-Version (9.20.0566Rel) funktioniert das selber hochgeladene Benutzerzertifikat mit eigener CA wieder einwandfrei.

Eine Kontrolle unter LCOS 9.24.0153RU3 zeigt, dass keine Fehlkonfiguration vorliegt und das selber hochgeladene Benutzerzertifikat (*.p12-Format) im LANCOM-internen Dateisystem als "ssl_pkcs12_int" verfügbar ist.

Ist dieser Mangel von LCOS 9.24.0153RU3 bekannt und auch von anderen LANCOM-Kunden reproduzierbar?

[GrandDixence]

LCOSv9_24RU3_Dateisystem.png

[alf29]

Moin,

nein, dergleichen Probleme sind mir nicht bekannt. Kannst Du mir mal so einen PKCS12-Container erzeugen und schicken?

Gruß Alfred

[GrandDixence]

Der PKCS12-Container wurde gemäss der nachfolgenden Anleitung erstellt. Ich werde versuchen, einen PKCS12-Container für die Fehlersuche zu erstellen und bereit zustellen.

Code: Alles auswählen

Eigene Zertifikate ausstellen mit einer eigenen Zertifizierungsstelle (CA)
============================================================================

Umgebung: SUSE Linux Enterprise Desktop (SLED)

Vorbereitungsarbeiten
========================
# su
# cd /home/Installation/Zertifikate/CA_MyCompany/2019
# touch index.txt
# echo 01 > serial
# cp /etc/ssl/openssl.cnf /home/Installation/Zertifikate/CA_MyCompany/2019/
# mv openssl.cnf openssl2019.cnf

Folgende Zeilen in der openssl2019.cnf editieren:

[ CA_default ]
dir             = /home/Installation/Zertifikate/CA_MyCompany/2019
certs           = $dir
crl_dir         = $dir
database        = $dir/index.txt
new_certs_dir   = $dir
certificate     = $dir/cacert.pem
serial          = $dir/serial
crlnumber       = $dir/crlnumber
crl             = $dir/crl.pem
private_key     = $dir/cakey.pem
RANDFILE        = $dir/.rand

default_md	= sha256

[ policy_match ]
stateOrProvinceName     = optional

[ req ]
default_bits		= 4096

Mit einer zusätzlichen Konfigurationsdatei den Schlüsselgebrauch
einschränken auf Server- und Clientidentifizierung mit TLS:

/home/Installation/Zertifikate//CA_MyCompany/2019/MyCompany.ext
-----------------------------------------------------------------------
extensions = x509v3

[ x509v3 ] 
extendedKeyUsage = serverAuth, clientAuth
-----------------------------------------------------------------------


Eigene Zertifizierungssstelle erstellen (CA -> Certificate Authority)
======================================================================
caMyCompany2019cert.pem -> Öffentlicher Schlüssel der CA
caMyCompany2019key.pem  -> Geheimer Schlüssel der CA (mit Passwort!)

# su
# cd /home/Installation/Zertifikate/CA_MyCompany/2019

# openssl req -new -x509 -newkey rsa:4096 -sha256 -keyout caMyCompany2019key.pem -out caMyCompany2019cert.pem -days 1685
-> Wo keine Angabe gewünscht wird, einfach "." eingeben.


Serverzertifikat für LANCOM-Firewall einrichten
=================================================
Schlüssel für das Serverzertifikat erstellen:

# su
# cd /home/Installation/Zertifikate/CA_MyCompany/2019
# openssl genrsa -out routerMyLancom2019.pem 4096

Zertifikatsanforderung (Request) für das Serverzertifikat erstellen:

# openssl req -key routerMyLancom2019.pem -new -subj /CN=192.168.3.1 -sha256 -out routerMyLancom2019.req 

Auf dem Computer das Firewall-Zertifikat beglaubigen lassen:

# su
# cd /home/Installation/Zertifikate/CA_MyCompany/2019
# openssl x509 -req -days 1685 -sha256 -extfile MyCompany.ext -in routerMyLancom2019.req -CA caMyCompany2019cert.pem -CAkey caMyCompany2019key.pem -CAcreateserial -out routerMyLancom2019trusted.pem

Alle für die Firewall erforderlichen Zertifikate in eine PKCS#12-Datei
packen:

# openssl pkcs12 -export -inkey routerMyLancom2019.pem -in routerMyLancom2019trusted.pem -certfile caMyCompany2019cert.pem -out routerMyLancom2019Alle.p12
-> Leeres Passwort eingeben (Kein Passwort)!

Im Webinterface der Firewall unter Dateimanagement -> Zertifikat oder Datei hochladen 

Das Zertifikatspaket routerMyLancom2019Alle.p12 hochladen. Die Option 
"Vorhandene CA Zertifikate ersetzen" aktivieren und den Dateityp:

SSL - Container als PKCS#12-Datei (*.pfx, *.p12) wählen.

Das neue Zertifikat wird erst nach einem Neustart der Firewall aktiviert.

[GrandDixence]

Anbei der gewünschte PKCS12-Container für Testzwecke. Der gewünschte PKCS12-Container wurde gemäss der oben stehenden Anleitung erstellt. Auch der für Testzwecke erstellte und hier veröffentlichte PKCS12-Container funktioniert nicht unter LCOS 9.24 RU3. Der für Testzwecke erstellte und hier veröffentlichte PKCS-Container funktioniert einwandfrei unter LCOS 9.20 Rel.

Ich habe jetzt im myLancom eine Support Anfrage an LANCOM eröffnet.

[alf29]

Ich versuche's mir morgen anzuschauen, kann aber nicht versprechen, daß das kurzfristig klappt. Um die Sache einzuengen: wie sieht es bei der 9.24 RU2 aus?

Gruß Alfred

[alf29]

Ich denke, die Ursache wurde gefunden und der Fehler wurde behoben.

Gruß Alfred

[GrandDixence]

Hallo Alfred

Vielen Dank für die schnelle und kompetente Mangelbehebung!

[maiki]

Hallo Ihr beiden,

was war den falsch, bzw. wo lag das Problem ?

Grüße

Maik

[alf29]

Moin,

der SSL/TLS-Stack im LCOS unterstützt aktuell nur Zertifikate mit RSA-Schlüsseln. Zertifikate mit anderen Schlüsseltypen sind zwar (noch) eine ziemliche Rarität, das LCOS hat sich aber beim Auspacken des Containers auf die Nase gelegt, wenn man einen PKCS#12-Container mit etwas anderem als RSA hochgeladen hat. Beim Fixen dieses Bugs ist dann etwas durcheinandergegangen und der TLS-Stack konnte den aus dem PKCS#12-Container ausgepackten privaten (immer noch RSA-)Schlüssel nicht mehr einlesen.

Bevor jemand nachhakt: nein, das heißt nicht, daß das TLS im LCOS jetzt z.B. Zertifikate mit elliptischen Kurven unterstützen würde. Container mit solchen Zertifikaten werden jetzt abgelehnt. Wann das kommt, steht noch in den Sternen...

Gruß Alfred

[maiki]

Hi Alfred,

danke für deine ausführliche Erklärung...

Grüße

Maik

[kelm]

@Alfred, gibt es einen Workaround hierzu?

Zur Info: Wir haben es nach mehreren Anläufen geschafft, auf einem 1781EW unsere SSL-Zertifikatskette mit 9.24 RU3 einzuspielen und aktiviert zu bekommen - allerdings in Einzelteilen als PEM. Blöderweise fällt das Gerät nach einem Neustart trotzdem auf das Lancom-generierte Zertifikat zurück...

Beste Grüße,

Peter

[alf29]

Moin,

@Alfred, gibt es einen Workaround hierzu?

Ja, auf die RU2 zurückgehen

Zur Info: Wir haben es nach mehreren Anläufen geschafft, auf einem 1781EW unsere SSL-Zertifikatskette mit 9.24 RU3 einzuspielen und aktiviert zu bekommen - allerdings in Einzelteilen als PEM. Blöderweise fällt das Gerät nach einem Neustart trotzdem auf das Lancom-generierte Zertifikat zurück...

Ja, das ist eine bekannte Macke in diversen LCOS-Versionen, daß der PKCS#12-Container bei jedem Gerätestart neu ausgepackt und die ssl_privkey-Datei neu geschrieben wird - in der RU3 eben in einem Format, das der TLS-Stack nicht versteht. Das wird sich vermutlich erst zur 10.10 ändern.

Falls Eure Zertifikatskette nur zweistufig ist (Root-CA-Zertifikat -> Gerätezertifikat), könnt Ihr versuchen, den PKCS#12-Container ganz zu löschen (del /status/filesystem/contents/ssl_pkcs12[_int]) und die drei Komponenten (Root-CA-Zertifikat, Gerätezertifikat, privater Schlüssel) einzeln einzuspielen. Längere Ketten gehen nur per PKCS#12-Container, dann kommt Ihr mit der RU3 nicht weiter.

Gruß Alfred

[kelm]

Hallo Alfred,

besten Dank für die rasche Antwort. Den "Workaround" hatten wir für uns schon umgesetzt.

Danke für die Erklärung zur PKCS#12-Handhabung. Unsere Zertifikatskette ist (aktuell noch) zweistufig - der von Dir beschriebene Weg der Installation der drei Komponenten war das, was wir mit der RU3 gemacht hatten. Nur doof, dass das keinen Neustart überlebt...

Viele Grüße,

Peter

[alf29]

Moin,

was ich im Nebensatz erwähnt hatte - habt Ihr im Dateisystem des Geräts noch den PKCS#12-Container liegen ('ssl_pkcs12_int' unter /status/file-system/contents)? Wenn ja, müßt Ihr den löschen. Dann sollte das mit dem Upload der Einzeldateien klappen.

Gruß Alfred