Private CA unter macOS und Windows als vertrauenswürdig einrichten und die Wirkung prüfen

Ziel

Ein privates Root-CA-Zertifikat wird dem systemweiten Vertrauensspeicher unter macOS und Windows Server hinzugefügt, damit TLS-Clients, die den Speicher des Betriebssystems verwenden, die von dieser CA ausgestellten Zertifikate akzeptieren.

Voraussetzungen

Administrator- bzw. Root-Rechte (unter Windows eine PowerShell oder Eingabeaufforderung mit erhöhten Rechten, da der Maschinenspeicher das Ziel ist); das CA-Zertifikat im DER- oder PEM-Format für macOS, eine .cer-, .crt- oder .p7b-Datei für Windows (macOS 13 und neuer; Windows Server 2016 und neuer, PowerShell 5.1+). Ab macOS 11 erfordert das Ändern der Admin-Vertrauenseinstellungen über die Kommandozeile zusätzlich eine interaktive Autorisierung in einer angemeldeten GUI-Sitzung; bei Ausführung über SSH oder in einem unbeaufsichtigten Skript kann add-trusted-cert mit einem Autorisierungsfehler scheitern ("no user interaction was possible"). Für einen unbeaufsichtigten oder flottenweiten Rollout ist ein per MDM verteiltes Konfigurationsprofil mit Zertifikat-Payload der unterstützte Weg.

Schritte

macOS:

1. sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/ca.pem -d schreibt die Vertrauenseinstellung in die Admin-Domäne (Standard ist die Domäne des aufrufenden Benutzers) und gilt damit für alle Benutzer des Rechners. -r trustRoot (zugleich der Standardwert für den Ergebnistyp) markiert ein selbstsigniertes Root-Zertifikat für alle Richtlinien als vertrauenswürdig; für ein Zwischenzertifikat wäre trustAsRoot nötig. -k legt das Zertifikat im System-Schlüsselbund ab statt im Login-Schlüsselbund des aufrufenden Benutzers.
2. Ein Neustart ist nicht erforderlich; neue TLS-Verbindungen sehen die Änderung normalerweise, bereits laufende langlebige Daemons müssen aber gegebenenfalls neu gestartet werden.

Windows:

1. PowerShell: Import-Certificate -FilePath C:\ca.cer -CertStoreLocation Cert:\LocalMachine\Root
2. Alternativ certutil -addstore -f "Root" C:\ca.cer (ohne -user verwendet certutil den lokalen Maschinenspeicher; -f überschreibt eine bereits vorhandene Kopie). Beide Varianten schreiben in den Speicher «Vertrauenswürdige Stammzertifizierungsstellen» des lokalen Computers, sodass für Dienste oder geplante Tasks unter anderen Konten kein zusätzlicher Schritt pro Benutzer nötig ist.
3. Nicht interaktiv: Beim Hinzufügen zu LocalMachine\Root erscheint keine Bestätigungsabfrage, daher laufen beide Befehle in einer Sitzung mit erhöhten Rechten unbeaufsichtigt.

Erwartetes Ergebnis

macOS: security find-certificate -c "<CA common name>" /Library/Keychains/System.keychain liefert das Zertifikat, security dump-trust-settings -d führt es unter den Admin-Vertrauenseinstellungen auf, und ein TLS-Client (curl, eine App, die den Systemspeicher verwendet) akzeptiert ein Leaf-Zertifikat, dessen Kette zu dieser CA führt. Windows: Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*<CA name>*" liefert es, und Invoke-WebRequest gegen einen Server mit einem Leaf-Zertifikat dieser CA meldet keinen Vertrauensfehler mehr.

Grenzen und Prüfbasis

Ein Zertifikat, das ohne Vertrauenseinstellungen in einen Schlüsselbund importiert wurde (etwa mit security import oder per Drag-and-drop in die Schlüsselbundverwaltung), wirkt installiert, gilt aber nicht als vertrauenswürdiges Root-Zertifikat; deshalb dump-trust-settings prüfen, nicht nur find-certificate. Unter Windows gilt ein Eintrag in CurrentUser\Root statt in LocalMachine\Root nur für diesen Benutzer, nicht für Dienste, und löst einen Bestätigungsdialog mit Sicherheitswarnung aus, der unbeaufsichtigte Läufe blockiert. Rückgängig machen: unter macOS sudo security remove-trusted-cert -d /path/to/ca.pem und danach sudo security delete-certificate -c "<name>" /Library/Keychains/System.keychain, unter Windows certutil -delstore "Root" "<serial number or thumbprint>" (mit erhöhten Rechten).