2017-02-20 7 views
1

Ich versuche, eine Verbindung zu einem Remote-IBM MQ-Server (V.8.0) herzustellen und erhalte den folgenden Fehler. Ich verwende .Net 4.5.2 unter Windows 10. Ich habe das SimplePut.exe-Programm geändert, das mit der Client-Installation geliefert wird. Ich denke, dass ich etwas vermisse, was mit dem Client-Zertifikat zu tun ist, das ich ausgestellt habe, und habe es installiert, indem ich ihren Anweisungen folge. Möglicherweise die Einstellung CertificateLabel? Ich bin sehr neu in IBM MQ, daher wird jede Hilfe sehr geschätzt.IBM MQ.Net CertificateLabel, CipherSpec

-h <host> -p 1434 -s TLS_RSA_WITH_AES_256_CBC_SHA256 -q INS -l connection -k *SYSTEM 

der Fehler an den WS-Manager angezeigt, wenn ich das Programm laufen wie folgt:

Cause . . . . . : 
There is a mismatch between the CipherSpecs on the local and remote ends of 
channel ''. The channel will not run until this mismatch is resolved. 
The local CipherSpec is 'TLS_RSA_WITH_AES_256_CBC_SHA256' and the remote 
CipherSpec is 'TLS_RSA_WITH_AES_128_CBC_SHA256'. 
Recovery . . . : 
Change the channel definition for '' so that both ends have matching 
CipherSpecs and restart the channel. 
+0

nur eine kurze Notiz. Ich habe auch das oben mit * USER – renz

+0

probiert Hast du die '-s' Option hinzugefügt? Ich habe keine v8.0 SimplePut.cs zu überprüfen, aber die 7.5 Version hat diese Option nicht. – JoshMc

+0

Nein, es kam aus dem Beispiel - Verwendung: SimplePut -q Warteschlangenname -k SchlüsselRepository -s cipherSpec [-h Host -p Port -l Kanal -n NummerOfMsgs -dn sslPeerName-kr SchlüsselResetCount -cr sslCertRevocationCheck] von dem, was ich gelesen habe In den letzten Tagen denke ich, dass es sich um ein Feature im verwalteten Client von Version 8.0 handelt. Zuvor konnten Sie cipherSpec wegen einer Einschränkung im Framework nicht angeben. Oder so glaube ich :) – renz

Antwort

2

MQ v8.0 Knowledge Center Seite "Configuring SSL for managed IBM MQ .NET" besagt Folgendes:

c. Bearbeiten Sie bei Bedarf die Windows-Gruppenrichtlinie, um CipherSpec festzulegen, und starten Sie den Computer neu, damit die Windows-Gruppenrichtlinienaktualisierungen wirksam werden.

und

ein. Legen Sie den MQEnvironment- oder den SSLCipherSpec-Wert fest, um die Verbindung als sichere Verbindung zu kennzeichnen. Der von Ihnen angegebene Wert wird verwendet, um das verwendete SSL-Protokoll (SSL oder TLS) zu identifizieren, und muss mit allen Einstellungen übereinstimmen, die Sie in der Windows-Gruppenrichtlinie angegeben haben.

MQ v8.0 Knowledge Center Seite "CipherSpec support for the managed .NET client" in etwas mehr Detail geht:

Für die IBM MQ.NET Client verwaltet, sind die SSL-Einstellungen für die Microsoft.NET SslStream Klasse. Für SSLStream kann eine CipherSpec- oder eine Einstellungsliste von CipherSpecs nur in der Windows-Gruppenrichtlinie festgelegt werden. Dies ist eine computerweite Einstellung. SSLStream verwendet dann die angegebene CipherSpec- oder Präferenzliste während des Handshakes mit dem Server. Bei anderen IBM MQ-Clients kann die CipherSpec-Eigenschaft in der Anwendung in der IBM MQ-Kanaldefinition festgelegt werden, und die gleiche Einstellung wird für die SSL-Aushandlung verwendet. Aufgrund dieser Einschränkung kann der SSL/TLS-Handshake jedes unterstützte CipherSpec aushandeln, unabhängig davon, was in der IBM MQ-Kanalkonfiguration angegeben ist. Daher ist es wahrscheinlich, dass dies zu einem Fehler AMQ9631 im Warteschlangenmanager führt. Um diesen Fehler zu vermeiden, setzen Sie dieselbe CipherSpec wie die, die Sie in der Anwendung als SSL-Konfiguration in der Windows-Gruppenrichtlinie festgelegt haben.


Windows-Gruppenrichtlinie

Wenn ein CipherSpec auf der Windows-Gruppenrichtlinie festgelegt ist, muss die gleiche CipherSpec für den SSLCipherSpec Eigenschaftswert auf dem SVRCONN Kanal und in der Anwendung eingestellt wird . Wenn die Windows-Gruppenrichtlinie auf den Standardwert festgelegt ist, dh die Gruppenrichtlinie für die CipherSpec-Einstellung nicht aktiviert/bearbeitet wurde, müssen Anwendungen den gleichen Standardwert für CipherSpec aus der Windows-Gruppenrichtlinie SSL-Konfiguration in der MQEnvironment-Klasse oder in festlegen Die Hashtable-Eigenschaften des MQQueueManager-Konstruktors.


UPDATE auf cert-Label mit Managed .NET Angabe

MQ v8.0 Knowledge Center Seite "Using certificates for the managed .NET client" geht ins Detail der beiden Optionen MQ zu ermöglichen, das CERT zu finden:

Passende Zertifikate von Zertifikat-Label

Wenn Sie das Zertifikatlabel festlegen, durchsucht der IBM MQ Managed .NET-Client den Windows-Zertifikatspeicher mit dem angegebenen Labelnamen, um das Clientzertifikat zu identifizieren. Es lädt alle übereinstimmenden Zertifikate und verwendet das erste Zertifikat in der Liste. Es gibt zwei Optionen zum Festlegen des Zertifikatlabels:

  • Das Zertifikatlabel kann für die MQEnvironment-Klasse den Zugriff auf MQEnvironment.CertificateLabel festlegen.
  • Das Zertifikatsetikett kann auch in einer Hashtabellen-Eigenschaft festgelegt werden, die als Eingabeparameter mit dem MQQueueManager-Konstruktor bereitgestellt wird, wie im folgenden Beispiel gezeigt.
    Hashtable properties = new Hashtable();
    properties.Add("CertificateLabel", "mycert");
    der Name ("CertificateLabel"), und der Wert Groß- und Kleinschreibung.

Passende Zertifikate von String

Wenn Zertifikat Etikett nicht gesetzt ist, dann wird das Zertifikat, das die Zeichenfolge „ibmwebspheremq“ übereinstimmt und den aktuellen angemeldeten Benutzer (in Kleinbuchstaben) wird gesucht und benutzt.


UPDATE mit zusätzlichem hilfreich Blogeintrag

@renz die IBM developer MQdev Blog von Sudhanshu Pant " MQ v8: SSL connection in Managed MQ .NET", die auch gute Informationen mit Screenshots haben geschrieben gefunden.

+0

Hallo, Entschuldigung, ich hätte sagen sollen, dass der Fehler vom Remote-Host (Server-Seite) kommt. Wie Sie sehen können, gebe ich TLS_RSA_WITH_AES_256_CBC_SHA256 an. In ihren Protokollen versucht es jedoch, eine Verbindung mithilfe von TLS_RSA_WITH_AES_128_CBC_SHA256 herzustellen. Deshalb dachte ich, ich müsste etwas verpassen. Danke, dass du einen Blick auf den Weg geworfen hast. – renz

+0

Danke, die Gruppenrichtlinie SSL Cipher Suites auf die Verwendung von AES_256 beschränkt, hat entweder das Problem behoben oder es zumindest gezwungen, nur diese Chiffre zu verwenden. Das ist jetzt dem eigentlichen Problem entgangen, das ist - AMQ9637: Kanal fehlt ein Zertifikat. Ich habe einen Post zu folgen, der dieses Problem anspricht [link] (https://www.ibm.com/developerworks/community/blogs/belinky/entry/digital_certificate_labels_digital_certificate_label34?lang=en) also werde ich es später versuchen. Werde eine neue Frage stellen, wenn es nicht funktioniert :) Prost – renz

+0

@renz Hinzugefügt Details zum verwalteten .NET Cert Label Matching. Die zweite aufgelistete Option ist die Art und Weise, wie MQ in der Vergangenheit mit anderen Nicht-Java-Clients gearbeitet hat und die Übereinstimmung des Labels mit einem bestimmten Format erfordert, das den Benutzernamen enthält, der den Prozess ausführt. Mit der ersten Option können Sie ein beliebiges Label angeben, das mit Erweiterungen für MQ v8 und höher für alle Clients und Warteschlangenmanager übereinstimmt, damit Sie ein Label angeben können. – JoshMc