FHEM CApath und CAfile Konfiguration

Begonnen von Burny4600, 31 Dezember 2022, 17:48:49

Vorheriges Thema - Nächstes Thema

Burny4600

Wo findet man bei FHEM etwas über die Konfiguration von CApath und CAfile.

Ich möchte die SSL Konfigurationen abschließen.
Grundsätzlich funktioniert die SSL Konfiguration, bis auf einige kleinere Fehler.

$  openssl s_client -connect rasp01:8083 -showcerts
Can't use SSL_get_servername
verify error:num=20:unable to get local issuer certificate

Verify return code: 21 (unable to verify the first certificate)
Secure Renegotiation IS NOT supported

Mfg Chris

Raspberry Pi 2/2+/3/3+/4 / Betriebssystem: Bullseye Lite
Schnittstellen: RFXtrx433E, SIGNALduino, MQTT, nanoCUL, HM-MOD-UART, 1-Wire, LAN, ser2net, FHEM2FEHEM
Devices: S.USV, APC-USV, Fronius Datalogger Web 2, FS20, IT, Resol VBUS & DL2, TEK603, WMR200, YouLess, Homematic, MQTT

rudolfkoenig

FHEMWEB / MQTT2_SERVER / telnet verwenden das Zertifikat aus /opt/fhem/certs/server-cert.pem.
Mit dem Attribut sslCertPrefix kann man auch andere Zertifikate verwenden.
Falls diese Datei nicht existiert, dann wird mit openssl beim ersten Zugriff ein self-signed Zertifikat erstellt.

Burny4600

#2
Ich habe für jeden eigenem Fhem Server die Zertifikate angelegt und im richtigem Verzeichnis abgelegt.
Und somit dürften diese Meldungen nicht auftauchen, wenn ich den Test auf der Konsole durchführe.
Grundsätzlich funktioniert die SSL Konfiguration.

Ich habe den Tipp bekommen, das eine Konfigurationsfehler vorliegt wenn diese Meldungen auftauchen.
OpenSSL benötigt die Info des Pfads und der Files.

Ich habe folgende Info dazu gefunden.
Zitat-CApath directory
    The directory to use for server certificate verification. This directory must be in "hash format", see verify for more information. These are also used when building the client certificate chain.
-CAfile file
    A file containing trusted certificates to use during server authentication and to use when attempting to build the client certificate chain.
Mfg Chris

Raspberry Pi 2/2+/3/3+/4 / Betriebssystem: Bullseye Lite
Schnittstellen: RFXtrx433E, SIGNALduino, MQTT, nanoCUL, HM-MOD-UART, 1-Wire, LAN, ser2net, FHEM2FEHEM
Devices: S.USV, APC-USV, Fronius Datalogger Web 2, FS20, IT, Resol VBUS & DL2, TEK603, WMR200, YouLess, Homematic, MQTT

rudolfkoenig

Ad 1: "unable to get local issuer certificate"

Bei mir zeigt "openssl s_client -connect localhost:8083 -showcerts" fuer ein automatisch von FHEM erzeugtes, selbst signiertes Zertifikat deutlich mehr an, unter anderm "verify error:num=18:self-signed certificate", was richtig ist.

Wenn man von den Browsern akzeptierte Zertifikate haben will, dann muss man mehrere Sachen beachten:

- der SAN (Subject Alternate Name) Eintrag muss dem im Browser verwendeten Rechnernamen entsprechen. Das von FHEM selbst erstellte Zertifikat traegt zwar localhost und die Ausgabe von hostname ein, das muss aber nicht dem entsprechen, was man im Browser eingibt.

- das Zertifikat muss von einem bekannten CA signiert sein. Das sind entweder die, die mit dem Browser oder OS ausgeliefert sind (konstenpflichtige, oder sowas wie letsencrypt), oder ein selbst erstelltes CA-Zertifikat, was aber im Browser explizit installiert werden muss. Das von FHEM automatisch erstellte Zertifikat verwendet kein CA-Zertifkat / es ist selbst-signiert. Auch openssl kennt CA-Zertifikate, diese sind per default im /etc/ssl/certs, man kann aber einen abweichenden Verzeichnis mit -CAPath angeben.

- bin nicht ganz sicher, wann/ob Certificate Transparency notwendig ist

- es gibt noch weitere (optionale) Mechanismen, um moegliche (theoretische?) Angriffsmoeglichkeiten zu minimieren, wie HKPK, aber nicht alle sind der Ansicht, das die sinnvoll sind.

Bestimmte Browser-Features (Stichwort PWA) sind nur auf einer vom Browser "akzeptiert-verschluesselten" Seite moeglich.
Leider ist es nicht realistisch, dass ein durchschnittlicher FHEM-Anwender das konfigurieren kann. 


Ad 2: "Secure Renegotiation IS NOT supported":
Ich habe dazu Folgendes gefunden: https://docs.mojolicious.org/Net/SSLeay#Secure-Renegotiation-and-DoS-Attack
Die erwaehnten Flags werden nicht gesetzt, es sei denn, man setzt das explizit mit der sslVersion FHEMWEB Attribut.


Burny4600

#4
Zitatder SAN (Subject Alternate Name) Eintrag muss dem im Browser verwendeten Rechnernamen entsprechen.
Die SAN habe ich für meinen Bereich angepasst und müsste soweit auch stimmen.
DNS:copycn, DNS:ccs-ht-rasp01, DNS:ccs-ht-rasp01.fhem.lokal, IP:127.0.0.1, IP:192.168.17.181

ZitatAuch openssl kennt CA-Zertifikate, diese sind per default im /etc/ssl/certs,
Ich vermute, dass betreffend FHEM -CApath und -CAfile in der OpenSSL Konfiguration (/etc/ssl/openssl.cnf ) Anpassungen nötig sind.
OpenSSL wird das Verzeichnis \opt\fhem\certs so in der Form nicht erkennen, und wird unter [ CA_default ] Anpassungen erfordern.

Zumindest was die Überprüfung auf der Konsole betrifft.

Grundsätzlich funktionieren die Zertifikate bis auf diese erwähnten Hinweise.
Die Erstellung der Zertifikate habe ich nach dieser Anleitung durchgeführt
https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle
was für die Erstellung funktioniert. Auch für den Betrieb mit FHEM funktionieren die Zertifikate.
Gleiches gilt auch für die Erstellung der Zertifikate mit XCA.
Mfg Chris

Raspberry Pi 2/2+/3/3+/4 / Betriebssystem: Bullseye Lite
Schnittstellen: RFXtrx433E, SIGNALduino, MQTT, nanoCUL, HM-MOD-UART, 1-Wire, LAN, ser2net, FHEM2FEHEM
Devices: S.USV, APC-USV, Fronius Datalogger Web 2, FS20, IT, Resol VBUS & DL2, TEK603, WMR200, YouLess, Homematic, MQTT