Wie vermeide ich SSL-Zertifikate während der Entwicklung für einen WCF-Endpunkt, der während der Produktion gesichert wird?

8

Wir entwickeln eine Reihe von WCF-Diensten. Anfragen werden eine Domänengrenze überschreiten; Das bedeutet, dass die Clients in einer Domäne ausgeführt werden und die Server, die die Anforderungen verarbeiten, sich in einer anderen (Produktions-) Domäne befinden. Ich weiß, wie man diese Verbindung mit SSL und Zertifikaten sichert. Wir werden die Benutzer nach ihren Benutzernamen und Passwörtern in der Produktionsdomäne fragen und diese in den SOAP-Headern übergeben.

Mein Problem ist, was während der Entwicklung und "Beta" -Tests zu tun ist. Ich weiß, dass ich ein temporäres Zertifikat bekommen und das während der Entwicklung benutzen kann. Ich frage mich, was meine Alternativen zu diesem Ansatz sind. Was haben andere in dieser Situation getan?

Update: Ich bin mir nicht sicher, ob ich eine "gute" Antwort auf meine Frage bekommen habe. Ich bin Teil eines großen Teams (50+) von Entwicklern. Die Organisation ist ziemlich agil. Jeder der Entwickler könnte am Projekt arbeiten, das WCF verwendet. In der Tat machen einige der anderen Projekte etwas ähnliches, aber für verschiedene Websites und Dienste. Nach was ich suchte, war ein Weg, auf dem ich für ein paar Tage kommen und an diesem Projekt arbeiten konnte, ohne durch eine Reihe von Reifen springen zu müssen. Das Installieren des Entwicklungszertifikats ist einer dieser Reifen. Ich verstehe vollkommen, dass "Dogfooding" der WCF-Struktur während der Entwicklung die beste Vorgehensweise ist. Die meisten Antworten gaben das als Antwort. Ich wollte wissen, was, wenn überhaupt, einen Sinn ergab, der anders war als "hol ein Testzertifikat (oder zwei) und installiere es auf allen Entwicklerboxen."

Jon

    
JonStonecash 24.02.2009, 15:45
quelle

6 Antworten

5

UPDATE: Wir verwenden tatsächlich das viel einfachere Keith Brown-Lösung statt dessen jetzt, siehe den Quellcode, den er zur Verfügung gestellt hat. Vorteil: Kein zu verwaltender nicht verwalteter Code.

Wenn Sie immer noch sehen wollen, wie man es mit C / C ++ macht, lesen Sie weiter ...

Nur für den Einsatz in der Entwicklung natürlich, nicht für die Produktion empfohlen, aber es gibt eine reibungsarme Möglichkeit, X.509-Zertifikate zu generieren (ohne auf makecert.exe zurückgreifen zu müssen).

Wenn Sie Zugriff auf CryptoAPI unter Windows haben, besteht die Idee darin, CryptoAPI-Aufrufe zu verwenden, um öffentliche und private RSA-Schlüssel zu generieren, ein neues X.509-Zertifikat zu signieren und zu codieren, es in einen Nur-Speicher-Zertifikatsspeicher zu übernehmen Verwenden Sie PFXExportCertStore() , um die PFX-Bytes zu generieren, die Sie dann an X509Certificate2 constructor übergeben können.

Sobald Sie eine X509Certificate2 -Instanz haben, können Sie sie als eine Eigenschaft der entsprechenden WCF-Objekte festlegen, und die Dinge fangen einfach an zu arbeiten.

Ich habe einen Beispielcode, den ich geschrieben habe, natürlich keine Garantien, und Sie werden etwas C-Erfahrung brauchen, um die Bits zu schreiben, die nicht verwaltet werden müssen (es wäre viel schmerzhafter zu schreiben) P / Invoke für alle CryptoAPI-Aufrufe, als dass dieser Teil in C / C ++ ist).

Beispiel-C # -Code, der die nicht verwaltete Hilfsfunktion verwendet:

%Vor%

Die X509GenerateSelfSignedCertificate -Funktionsimplementierung könnte in etwa so aussehen (Sie benötigen WinCrypt.h ):

%Vor%

Wir haben dies verwendet, um beim Start SSL-Zertifikate zu generieren. Das ist in Ordnung, wenn Sie nur die Verschlüsselung testen und die Vertrauenswürdigkeit / Identität nicht verifizieren wollen. Die Generierung dauert nur etwa 2-3 Sekunden.

    
Leon Breedt 22.08.2009 01:11
quelle
2

Sie möchten, dass Ihre Entwicklungsumgebung so weit wie möglich mit der Produktion übereinstimmt. WCF überprüft Sperrlisten während der Transportverhandlung oder Signaturprüfung und selbstsignierten Zertifikaten, oder gefälschte Zertifizierungen, die makecert verwenden, unterstützen keine CRLs.

Wenn Sie einen Ersatzcomputer haben, können Sie die Windows-Zertifikatsdienste verwenden (kostenlos mit Server 2003 und 2008). Dadurch wird eine Zertifizierungsstelle bereitgestellt, und Sie können Zertifikate (SSL oder Client) von dieser anfordern. Es muss ein Ersatzgerät sein, da es sich unter der Standard-Website einstellt und völlig durcheinander gerät, wenn Sie das bereits optimiert haben. Es veröffentlicht auch CRLs. Alles, was Sie tun müssen, ist, das Stammzertifikat für die CA auf Ihren Entwicklungsboxen zu installieren und Sie können loslegen.

    
blowdart 24.02.2009 16:42
quelle
1

Sie haben die Möglichkeit, entweder ein Zertifikat zur Verwendung in der Entwicklung zu generieren oder die Verwendung von Zertifikaten über die Konfigurationsdatei zu deaktivieren. Ich würde empfehlen, ein Zertifikat auch in der Entwicklung zu verwenden.

    
baretta 24.02.2009 16:45
quelle
1

Um Leon Breedts Antwort zu erweitern und das In-Memory-x509-Zertifikat zu generieren, können Sie den Quellcode von Keith Elders SelfCert .

%Vor%     
Paul Stovell 25.09.2010 01:29
quelle
0

Wie wäre es, die Konfiguration zwischen Entwicklung und Produktion zu ändern?

    
John Saunders 24.02.2009 16:24
quelle
0

Mein Vorschlag wäre, ein paar verschiedene Ansätze in Betracht zu ziehen:

Für die Entwicklung - & gt; Es gibt Möglichkeiten, ein SSL-Zertifikat lokal zu generieren, sodass Tests mit https in einer Umgebung ausgeführt werden können, die Sie vollständig kontrollieren können.

Für "Beta" -Testen - & gt; Ziehen Sie in Erwägung, ein zweites Zertifikat dafür zu erhalten, da zwischen den Releases immer wieder Beta-Tests durchgeführt werden müssen, so dass es wahrscheinlich immer wieder verwendet werden kann.

    
JB King 24.02.2009 16:30
quelle

Tags und Links