TLS-Zertifikat: Schlüssel ohne führende Null macht SecPKCS12Import unbrauchbar, Server fällt auf HTTP #48

New issue

Closed

opened 2026-10-16 09:58:41 +00:00 by alf · 1 comment

alf commented

2026-10-16 09:58:41 +00:00

Owner

Problem

Nach einem Neustart zeigte Iris — Lokal „Nicht verbunden“, die iPhone-App konnte sich nicht verbinden. Der Mac-Server auf Port 8765 sprach unverschlüsseltes HTTP, die Clients erwarten HTTPS.

Ursache

CertificateManager.generateAndStoreLeaf erzeugt den Schlüssel mit /usr/bin/openssl ecparam -genkey (LibreSSL). In etwa 1 von 256 Fällen schreibt LibreSSL den privaten Skalar ohne führende Null (31 statt 32 Byte). SecPKCS12Import liefert dann errSecSuccess, aber keine Identität. Die Funktion gab nil zurück, der Server lief ohne TLS weiter.

Fix

Erzeugung wird bis zu 10-mal wiederholt (generateAndStoreLeaf → generateAndStoreLeafOnce).
Die P12 wird vor dem Speichern per importP12 geprüft, eine unbrauchbare Datei wird nie persistiert.

Nicht Teil dieses Issues

Beim Start unmittelbar nach dem Login kann detectLocalIPAddress() noch keine en*-IPv4 finden und fällt auf 127.0.0.1 zurück. Das erzeugt ein Zertifikat nur für 127.0.0.1, das für LAN-Clients (iPhone) nicht passt. Das ist ein eigenes Thema.

## Problem Nach einem Neustart zeigte Iris — Lokal „Nicht verbunden“, die iPhone-App konnte sich nicht verbinden. Der Mac-Server auf Port 8765 sprach unverschlüsseltes HTTP, die Clients erwarten HTTPS. ## Ursache `CertificateManager.generateAndStoreLeaf` erzeugt den Schlüssel mit `/usr/bin/openssl ecparam -genkey` (LibreSSL). In etwa 1 von 256 Fällen schreibt LibreSSL den privaten Skalar ohne führende Null (31 statt 32 Byte). `SecPKCS12Import` liefert dann `errSecSuccess`, aber keine Identität. Die Funktion gab `nil` zurück, der Server lief ohne TLS weiter. ## Fix - Erzeugung wird bis zu 10-mal wiederholt (`generateAndStoreLeaf` → `generateAndStoreLeafOnce`). - Die P12 wird vor dem Speichern per `importP12` geprüft, eine unbrauchbare Datei wird nie persistiert. ## Nicht Teil dieses Issues Beim Start unmittelbar nach dem Login kann `detectLocalIPAddress()` noch keine `en*`-IPv4 finden und fällt auf `127.0.0.1` zurück. Das erzeugt ein Zertifikat nur für `127.0.0.1`, das für LAN-Clients (iPhone) nicht passt. Das ist ein eigenes Thema.

alf commented

2026-10-16 09:59:41 +00:00

Author

Owner

Stand (2026-10-16)

Gemessen: Das gespeicherte tls-identity.p12 enthielt einen Schlüssel mit 31-Byte-Skalar; Zertifikat und Schlüssel passten zusammen (openssl pkey -pubout identisch), SecPKCS12Import lieferte status 0, items 1, aber keine kSecImportItemIdentity. Frisch erzeugte P12-Dateien mit 32-Byte-Schlüssel importierten sauber. Nach Entfernen von tls-identity.p12 und Neustart lief der Server wieder mit HTTPS, das Zertifikat galt für die LAN-IP.

Nicht gebaut und nicht getestet: Die Änderung ist nur gegengelesen, nicht per Xcode gebaut (kein xcodebuild aus dem Terminal wegen TCC). Beim nächsten „Bau und starte lokal“ ist sie enthalten.

Offen / bewusst nicht Teil dieses Fixes:

Erkennt detectLocalIPAddress() beim Start keine en*-IPv4 (Start direkt nach dem Login, WLAN noch nicht verbunden), wird ein Zertifikat nur für 127.0.0.1 erzeugt. Sinnvoll wäre, in dem Fall das vorhandene Zertifikat zu behalten.
Der stille Rückfall auf HTTP bei fehlendem Zertifikat bleibt bestehen.

**Stand (2026-10-16)** Gemessen: Das gespeicherte `tls-identity.p12` enthielt einen Schlüssel mit 31-Byte-Skalar; Zertifikat und Schlüssel passten zusammen (`openssl pkey -pubout` identisch), `SecPKCS12Import` lieferte `status 0, items 1`, aber keine `kSecImportItemIdentity`. Frisch erzeugte P12-Dateien mit 32-Byte-Schlüssel importierten sauber. Nach Entfernen von `tls-identity.p12` und Neustart lief der Server wieder mit HTTPS, das Zertifikat galt für die LAN-IP. Nicht gebaut und nicht getestet: Die Änderung ist nur gegengelesen, nicht per Xcode gebaut (kein `xcodebuild` aus dem Terminal wegen TCC). Beim nächsten „Bau und starte lokal“ ist sie enthalten. Offen / bewusst nicht Teil dieses Fixes: - Erkennt `detectLocalIPAddress()` beim Start keine `en*`-IPv4 (Start direkt nach dem Login, WLAN noch nicht verbunden), wird ein Zertifikat nur für `127.0.0.1` erzeugt. Sinnvoll wäre, in dem Fall das vorhandene Zertifikat zu behalten. - Der stille Rückfall auf HTTP bei fehlendem Zertifikat bleibt bestehen.

alf referenced this issue from a pull request that will close it,

2026-10-16 09:59:56 +00:00

fix(remote): TLS-Leaf-Zertifikat bei defektem Schlüssel wiederholen und P12 vor dem Speichern prüfen (#48) #49

alf closed this issue

2026-10-16 09:59:57 +00:00

alf referenced this issue from a commit

2026-10-16 09:59:57 +00:00

fix(remote): TLS-Leaf-Zertifikat bei defektem Schlüssel wiederholen und P12 vor dem Speichern prüfen (#48)

alf referenced this issue

2026-10-27 18:03:22 +00:00

Plugin-Panel im rechten Seitenpanel — dritter Reiter „Plugin“, chat-gebunden, Plugin-UI im WKWebView #169

alf referenced this issue