Sollte ich separate Stammzertifizierungsstellen für interne Serverzertifikate, externe Clientzertifikate und HTTPS-Zertifikate verwenden?

Sollte ich separate Stammzertifizierungsstellen für interne Serverzertifikate, externe Clientzertifikate und HTTPS-Zertifikate verwenden?

Sollte ich für die folgende Situation 3 Stammzertifizierungsstellen, 1 Stammzertifizierungsstelle + 3 Zwischenzertifizierungsstellen oder eine andere PKI-Konfiguration haben?

Ich habe drei Anwendungsfälle:

  1. Bereitstellen einer Web-API über HTTPS (Serverzertifikate)
  2. Ermöglichen Sie Clients die Authentifizierung mit einem Client-Zertifikat anstelle von Benutzername/Passwort (externe Client-Zertifikate).
  3. Validieren Sie interne Server als Clients (interne Client-Zertifikate).

Jedes Schlüsselpaar wird für genau einen der Anwendungsfälle verwendet.

Nehmen wir an, ich benötige keine Drittanbieter-CA und arbeite stattdessen mit einer benutzerdefinierten PKI in einem geschlossenen System. Ich sehe zwei Möglichkeiten, dies zu unterstützen:

  1. 1 Stammzertifizierungsstelle mit 3 Zwischenzertifizierungsstellen (eine Zwischenzertifizierungsstelle für jeden Fall)
  2. 3 Stammzertifizierungsstellen (eine Stammzertifizierungsstelle für jeden Anwendungsfall)

Ich habe versucht, mit Nr. 1 zu beginnen, habe aber festgestellt, dass ich, um openssl s_clientClient-Zertifikate gegen einen node.js-HTTPS-Server testen zu können, von Intermediate zu Root validieren muss, nicht nur von Intermediate. Das bedeutet, dass Client-Zertifikate zwischen Anwendungsfall 2 und 3 ausgetauscht werden können, da Root der Vertrauensanker ist. Ich habe mich umgesehen, kann aber keine Möglichkeit finden, die Intermediate-CA zum Vertrauensanker für den node.js-HTTPS-Server zu machen.

Ich verstehe also etwas völlig falsch und muss zur Implementierung Nr. 2 oder einer Mischung aus beiden übergehen.

Antwort1

X.509-Zertifikate können Vertraulichkeit und Authentifizierung gewährleisten. Das heißt, sie können zur Verschlüsselung einer Verbindung und optional zur Authentifizierung des Benutzers oder Servers verwendet werden.

Sie stellen keine Autorisierung dar. Vielmehr muss die Anwendung entscheiden, ob die Entität, die sich mit einem X.509-Zertifikat authentifiziert hat, auf die Ressourcen zugreifen darf.

Das heißt, dass Punkt (1) oben in Ordnung ist. Verwenden Sie eine Wurzel und stellen Sie sicher, dass die Autorisierung auf andere Weise erfolgt.

Wenn Sie jedoch darauf bestehen, dass X.509-Zertifikate auch eine Autorisierung bereitstellen, müssen Sie Folgendes tun:

  • Verlassen Sie sich auf Zertifikatsrichtlinien, um sicherzustellen, dass Anwendungen nur bestimmten Zertifikaten vertrauen. Viel Glück dabei, da Sie wahrscheinlich Ihre eigenen Anwendungen codieren müssen, die die Richtlinien überprüfen.
  • Verwenden Sie für jede Anwendung ein anderes Stammzertifikat, wie oben unter (2).

verwandte Informationen