2010-12-23 6 views
5

Ich habe viele Artikel zur WCF-Sicherheit gelesen, habe aber immer noch kein klares Bild von Zertifikatszenarios. Unsere Implementierungsumgebung verfügt über einen NLB-Cluster (Front-End) mit wenigen ASP.NET-Sites, die mit dem Anwendungsserver kommunizieren (Back-End, auch NLB-Cluster). Wir müssen es mit gegenseitiger Zertifikatauthentifizierung und SSL schützen. Bin ich richtig, dass wir das folgende tun müssen:Gegenseitige WCF-Zertifikatauthentifizierung/SSL in Clusterumgebung

  1. Ausgabe ein Zertifikat mit CN = app-Server-NLB-Host-Namen und ‚Server-Authentifizierung‘ Zweck in der Domäne CA.
  2. Geben Sie ein Zertifikat für Front-End-Boxen mit dem Zweck 'Client-Authentifizierung' aus.
  3. Importieren Sie den öffentlichen Schlüssel des Back-End-Zertifikats in die Speicher der Frontend-Knoten (und umgekehrt).
  4. konfigurieren WCF verwenden net.tpc mit Transportsicherheit
  5. Konfigurieren Sie das Betriebsverhalten (serviceCredentials Abschnitt)
  6. Konfigurieren Sie den Client-Endpunkt Verhalten (ClientCredentials Abschnitt)

Meine Fragen sind:

  1. Habe ich etwas verpasst?
  2. Muss ich zusätzliche Schritte ausführen, um SSL zu aktivieren?
  3. Welcher Hostname Frontend-Zertifikate sollten ausgestellt werden?
  4. Die Front-End-Knoten sind in DMZ und haben daher keinen Zugriff auf die Domäne (CA). Wird dies Probleme verursachen?

Antwort

3

HI dort. Da niemand anderes geantwortet hat, werde ich einen Fehler machen - aber eine faire Warnung - Ich bin ein Java/UNIX-Entwickler und einige der Fragen, die Sie stellen, sind Microsoft-spezifisch. Aber hier ist ein paar Antworten:

1 - Ausgabe ein Zertifikat mit CN = app-Server-NLB-Host-Namen und 'Server-Authentifizierung' Zweck in die Domäne CA.

Der Zweck ist eine etwas Microsoft-spezifische Sache. Das hört sich richtig an, aber auch - Sie brauchen die normale "Schlüsselverwendung", um etwas Besonderes zu sein - für SSL-Zertifikate verwende ich normalerweise keyEncipherment oder keyAgreement. Manchmal verwenden Websites digitalSignature. Alle drei sind im RFC gültig, aber manchmal ist Microsoft wierd darüber, was funktioniert. Wenn Sie eine Microsoft-Zertifizierungsstelle verwenden, würde ich feststellen, ob sie ein Zertifikatsprofil für SSL-Zertifikate besitzt und nur dieses verwendet.

2 - Geben Sie ein Zertifikat für die Front-End- Boxen mit "Client-Authentifizierung" Zweck.

Wie # 1 - jedes Zertifikat benötigt eine Art von Grundschlüsselnutzung. Die Felder, die Sie erwähnen, sind erweiterte Verwendungen, die wahrscheinlich auch notwendig, aber nicht obligatorisch sind.

3 - Importieren Sie den öffentlichen -Schlüssel des Back-End-Zertifikats in die Speicher der Frontend-Knoten (und umgekehrt).

Nur wenn dies eine spezielle Microsoft-Sache ist. In der richtigen PKI sollten Sie das Zertifikat der vertrauenswürdigen Zertifizierungsstelle importieren, das die SSL signiert hat, aber Sie sollten nicht jeden Endpunkt (wie das Back-End-Zertifikat) in das Frontend importieren müssen.Ich würde es versuchen, indem ich nur Ihre vertrauenswürdigen CA-Ketten konfiguriere und sehe, ob Sie es zum Laufen bringen können - es wird Ihre Architektur auf lange Sicht viel erweiterbarer machen.

4 - WCF Konfigurieren verwenden net.tpc mit Transportsicherheit

5 - Konfigurieren des Betriebsverhaltens (serviceCredentials Abschnitt)

6 - Konfigurieren der Client-Endpunkt Verhalten (ClientCredentials Abschnitt)

Klingt gut für mich ...

Von dort glaube ich nicht, dass Sie noch etwas verpasst haben. Der Schlüssel arbeitet normalerweise durch die obskuren Fehlermeldungen. Jedes System hat seine eigene unerklärliche Art zu erzählen, was falsch ist, wenn ein SSL-Handshake fehlschlägt, so dass es meistens ein Gefühl dafür bekommt, was falsch gelaufen ist.

Von dem Problem, das Sie beschreiben, ich nicht denken Ihre Sicherheitsarchitektur sagt, dass Sie eine Zertifikatstatusprüfung durchführen müssen. Dies ist eine zusätzliche Maßnahme, mit der Ihr System überprüfen kann, ob ein Zertifikat von der Zertifizierungsstelle widerrufen wurde. Es braucht einiges an Infrastruktur, um es funktionieren zu lassen (CRLs oder OCSP), also würde ich nicht sagen, dass Sie es ohne ernsthafte Diskussion in Ihrem Team tun sollten, welche Risiken Sie mindern wollen und wie wahrscheinlich sie sind auftreten.

Für welche Frontend-Zertifikate für den Hostnamen sollten Sie ausgestellt werden?

Der Hostname des Servers, den sie repräsentieren.

Eine Sache über Host-Namen - einige Systeme funktionieren nicht richtig, wenn Sie den voll qualifizierten Domain-Namen verwenden. Andere sind nicht so wählerisch. In jedem Fall sollte der Subject-DN des Zertifikats den Dienst, die Anwendung oder den Server eindeutig beschreiben.

Die Front-End-Knoten sind in DMZ und haben daher keinen Zugriff auf die Domäne (CA). Wird dies Probleme verursachen?

Sie werden keine Probleme haben.

UNBEDINGT - Sie müssen die oben genannte Zertifikatstatusprüfung durchführen. Wenn Sie den Zertifikatstatus validieren müssen, müssen Sie vom Endpunkt (dh der DMZ) zu den Informationen über den Status des Zertifikats (die CRL oder den OCSP-Server) gelangen. In komplexen Infrastrukturen geschieht dies in der Regel durch Öffnen eines Pfades zum OCSP-Server - es ist ein HTTP GET zu einem festen Domainnamen oder einer festen IP-Adresse, daher ist es normalerweise nicht zu schlecht, einen Pfad auf einer Firewall zu öffnen.

Wie ich schon sagte - das wäre die gehobene, ernsthafte Risikominderungstyp Lösung. Es könnte für Ihr System ein Overkill sein - ich weiß nicht genug über Ihr System, um Ihnen zu sagen, ob es gerechtfertigt ist oder nicht.

Verwandte Themen