2010-11-24 6 views
2

Ich habe eine seltsame Anforderung. Ich versuche, mit einem in C# geschriebenen Server zu kommunizieren. Es sieht grundsätzlich so aus:Verbinden mit .NET Sslstream x.509-Socket mit Python oder Ruby oder Perl

SslStream sslStream = new SslStream(client.GetStream(), true, 
            ValidateServerCertificate, 
            SelectLocalCertificate); 
sslStream.AuthenticateAsServer(_pushCert); 

Ich habe auch Beispielcode in C#, die ein X509-Zertifikat verwendet und eine Verbindung zum Server herstellt. Ich habe auch das Passwort für die Datei cert.pfx.

Was ich tun möchte, ist eine Art Shell-Skript einrichten, die mit dem Socket verbinden kann, ein paar Bytes übertragen und die Antwort erhalten. (jede Sprache wirklich, obwohl ich auf Python oder Ruby oder Perl schaute)

Ich versuchte mit dem SSL-Wrapper von Python, aber ich bekomme einen Fehler, der besagt, ist kein bekannter Algorithmus für den Server/Client zu sprechen.

Beispiel meines Python-Code:

ss = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
s = ssl.wrap_socket(ss, ca_certs=CERT, ssl_version=ssl.PROTOCOL_SSLv23) 
#Attempt connection to our server 
try: 
    s.connect((HOST, PORT)) 
    print s 
except: 
    print 'ERROR Connecting' 
    sys.exit(0) 

Für CERT versuchte ich ein paar verschiedenen filee: die PFX, und einige aus der PFX extrahierten OpenSSL.

Ich habe viele verschiedene Beispiele ausprobiert (Argumente für die ssl.wrap_socket). Ich kenne diese Zusammenhänge auch nicht wirklich.

Vielleicht könnte jemand hier eine Hand leihen?

Danke!

SslStream sslStream = new SslStream(client.GetStream()); 
sslStream.AuthenticateAsServer(_pushCert); 

Dieser Server sendet _pushCert und erwartet nicht, dass der Kunde zurück, ein Zertifikat zu senden:

+0

Der Server benötigt Zugriff auf den privaten Serverschlüssel, nicht auf den Client. –

+0

Das von mir verwendete Cert (.pfx) stammt von einem C# -Client, der eine Verbindung mit diesem Server herstellt.Der Fehler, den ich bekomme (Ausnahme) ist: "Der Client und der Server können nicht kommunizieren, da sie keinen gemeinsamen Algorithmus besitzen" – Chris

+0

AuthenticateAsServer verwendet standardmäßig SSL 3.0 oder TLS 1.0 und Ihr Python-Code scheint SSL 2 oder 3 zu verwenden. Also sollten sie * sich auf SSL 3.0 einigen (welches afaik eine Reihe von Algorithmen spezifiziert, die alle Implementierungen unterstützen müssen). Ich würde sagen, der einzige mögliche Fehlerpunkt hier ist das Zertifikat. Versuche es mit einem anderen. (Sie können ein selbstsigniertes Zertifikat mit [makecert.exe] (http: //msdn.microsoft.com/en-us/library/bfsktky3 \ (v = VS.100 \) .aspx) problemlos erstellen.) – dtb

Antwort

0

Sie können Ihre SslStream Konstruktoraufruf vereinfachen. Der Server benötigt den privaten Schlüssel für das Zertifikat, um die SSL-Verbindung herzustellen.

Der Client benötigt nur das CA-Stammzertifikat, das das Serverzertifikat signiert hat (oder eine Option zum Akzeptieren eines nicht vertrauenswürdigen Zertifikats). Dies muss im "vertrauenswürdigen Stammzertifikatspeicher" oder auf andere Weise als vertrauenswürdig für den Client-Wrapper angegeben sein .

Wenn das Serverzertifikat von einem Zwischenzertifizierungsstellenzertifikat signiert wird, das selbst vom Stammzertifizierungsstellenzertifikat signiert ist, benötigt der Client auch dieses Zwischenzertifikat. Das kann vom Server gesendet werden oder kann bereits beim Client sein. In jedem Fall muss die gesamte Kette der Signaturzertifikate beim Client vorhanden sein, um alle Signaturen entlang der Kette zu überprüfen. Das Zertifikat der Zwischenzertifizierungsstelle muss sich nicht im vertrauenswürdigen Stammspeicher befinden.

Keine Seite benötigt einen privaten Schlüssel für den CA-Stamm oder für ein Zwischensignaturzertifikat.

Wenn Ihr Server jedoch erwartet, dass der Client ein Clientzertifikat sendet, müssen Sie AuthenticateAsServer mit weiteren Argumenten aufrufen (clientCertificateRequired == true). In diesem Fall benötigt der Client sowohl sein eigenes Zertifikat als auch den privaten Schlüssel für sein Zertifikat. Der Server benötigt den CA-Stamm, der das Clientzertifikat in seinem vertrauenswürdigen Speicher signiert. Der Client-Wrapper übernimmt beispielsweise eine PFX-Datei, die das Client-Zertifikat und den privaten Schlüssel enthält. Der Server benötigt den privaten Schlüssel des Clients nicht.