2017-09-22 1 views
1

IBM WebSphere MQ 8.0 버전을 사용 중입니다.SSL 채널 연결 용 MQ에서 2538 오류

"TLS_RSA_WITH_AES_256_CBC_SHA256"Cipher Spec 암호화와 유효한 인증서가 설치되고 키 저장소 경로에 올바르게 매핑 된 채널 중 하나를 구성했습니다.

.NET 클라이언트 코드가이 보안 채널에 연결할 수 없습니다. 그것은 2538 오류를 지속적으로 제공합니다. 암호화되지 않은 채 다른 채널이 구성되었습니다 (보안되지 않음). 클라이언트 코드는 오류없이이 채널에 연결할 수 있습니다.

이 내 .NET 클라이언트 코드입니다 : 나는 또한 필요한 모든 액세스 권한이있는 유효한 사용자에게 MCA 사용자를 설정 한

 Hashtable queueProperties = new Hashtable(); 
     queueProperties[MQC.HOST_NAME_PROPERTY] = host; // IP address 
     queueProperties[MQC.PORT_PROPERTY] = 1541 
     queueProperties[MQC.CHANNEL_PROPERTY] = channel; // channel name 
     queueProperties[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_MANAGED; 
     queueProperties[MQC.SSL_CERT_STORE_PROPERTY] = "*USER"; 
     queueProperties[MQC.SSL_CIPHER_SPEC_PROPERTY] = "TLS_RSA_WITH_AES_256_CBC_SHA256"; 
     queueProperties[MQC.SSL_PEER_NAME_PROPERTY] = "CN=FXCMTST1,O=IBM,C=US"; 
     queueProperties["CertificateLabel"] = "ibmwebspheremqfxcmtst1"; 
     queueProperties[MQC.KEY_RESET_COUNT] = 0; 
     MQEnvironment.SSLCertRevocationCheck = true; 
     queueProperties[MQC.USER_ID_PROPERTY] = user; // variable 
     queueProperties[MQC.PASSWORD_PROPERTY] = pwd; // variable 
     try 
     { 
      // Attempt the connection 
      queueManager = new MQQueueManager(qmgr, queueProperties); 
      strReturn = "Connected Successfully"; 
     } 

.

위 코드는이 줄을 제거하고 채널 이름을 보안되지 않은 채널 이름으로 바꿀 때 보안되지 않은 채널에서 잘 작동합니다.

queueProperties[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_MANAGED; 
    queueProperties[MQC.SSL_CERT_STORE_PROPERTY] = "*USER"; 
    queueProperties[MQC.SSL_CIPHER_SPEC_PROPERTY] = "TLS_RSA_WITH_AES_256_CBC_SHA256"; 
    queueProperties[MQC.SSL_PEER_NAME_PROPERTY] = "CN=FXCMTST1,O=IBM,C=US"; 
    queueProperties["CertificateLabel"] = "ibmwebspheremqfxcmtst1"; 
    queueProperties[MQC.KEY_RESET_COUNT] = 0; 
    MQEnvironment.SSLCertRevocationCheck = true; 

코드 또는 MQ 구성에 아무 것도 없습니다.

업데이트 1 : 키 데이터베이스에 대한 잘못된 경로로 인해 오류가 발견되었습니다. 나는 인증서가 있던 폴더 이름까지 경로를 언급했다. 그러나 폴더 이름 다음에 확장자가없는 kdb 파일 이름이 오는 것으로 예상됩니다.

이 변경을 수행 한 후 2538 오류가 사라졌습니다. 하지만 지금 로그에서 아래의 오류 메시지와 함께 2059 오류가 나타납니다.

내 채널 I는 MQ 탐색기에서 설정 한대로 "TLS_RSA_WITH_AES_256_CBC_SHA256"가 구성되어는 "CipherSpec은 ... 채널에 필요한 CipherSpec과 일치하지 않습니다 SSL 핸드 셰이크 중에 협상". 클라이언트 코드도 동일한 암호 스펙을 보냄니다. 그래도 2059 오류가 발생합니다.

업데이트 2 : @JoshMc에서 제안한대로 그룹 정책을 설정하고 오류를 해결했습니다. 그런 다음 "채널에 인증서가 없습니다"라는 오류가 표시되기 시작했습니다.

업데이트 3 : SSLCAUTH를 OPTIONAL (으)로 변경하면이 오류가 사라집니다. 이전에는 REQUIRED로 설정되었습니다. 지적한 @ JoshMc에게 감사드립니다.

queueProperties[MQC.SSL_PEER_NAME_PROPERTY] = "ibmwebspheremqtestqueue"; 

내가 조언 :

+0

전체 클라이언트가 설치되어 있지 않습니다. 난 그냥 코드를 사용하여 닷넷 MQ 서버에 연결할 수 있습니다. 또한, 당신이 제안한 것처럼 동료 이름을 바꿀 것입니다. –

+0

그렇다면 TLS를 수행 할 때도 클라이언트가 설치되어 있지 않으면 dll은 기본적으로 관리 모드로 설정되기 때문에'MQC.TRANSPORT_PROPERTY'를 설정할 필요가 없습니다. 로그가 표시되는 내용을 알려주고, 클라이언트 쪽을 수행하십시오. Net 추적은 올바른 방향으로 사용자를 안내 할 것입니다. – JoshMc

+0

@JoshMc MQC.TRANSPORT_PROPERTY – Roger

답변

2

원래 질문에 당신은 다음 코드 줄 가지고 있었다 SSL_PEER_NAME_PROPERTY가 일부 또는 큐 관리자 인증서의 DN 값을 모두 확인하는 의미를, 그래서 것 CN=x.domain.com,OU=Y,O=Company Inc과 같은 형식으로 인증서 레이블과 비슷한 모양을 가지고 있습니다.

대기열 관리자 AMQERR01.LOG에 어떤 오류가 생성되었는지 볼 수 있습니까? 로컬 클라이언트 AMQERR01.LOG는 어떻습니까?

당신은 큐 관리자에서 오류로 응답 :

AMQ9660: SSL key repository: password stash file absent or unusable. 

그리고 당신은 당신의 갱신 당 발견 한 오류 :

:

UPDATE: I found that the error was due to incorrect path to key database. I had mentioned the path till folder name where the certificates were placed. However it was expected to be the folder name followed by the name of kdb file without extention.

는 이제 다음과 같은 오류가로 이동을

The CipherSpec negotiated during the SSL handshake does not match the required CipherSpec for channel... 

내가 권고 한 바 : Managed .net은 지정한 암호를 사용하지 않습니다. Win에서 가져온 암호입니다. 정책. 이 질문과 답변은 "IBM MQ.Net CertificateLabel, CipherSpec"에 도움이됩니다.

channel is lacking a certificate 

SSLCAUTH(REQUIRED) 큐 관리자를 알려줍니다 당신이를 위해 클라이언트를 요구하고 있습니다 :

당신은 당신이 그룹 정책을 고정하고 당신이 SVRCONN 채널 SSLCAUTH(REQUIRED)을 설정할 때 다음과 같은 오류가로 이동 조언 증명서. 클라이언트는 SSLCAUTH이 설정된 경우에도 항상 큐 관리자가 인증서를 가져야합니다.

큐 관리자는 보내는 사용자와 패스워드를 검증 CONNAUTH을 수행하도록 구성되고 그 다음에 SSLCAUTH(OPTIONAL)을 갖는이 같은 합리적인 설정되면, CONNAUTHAUTHINFO 개체 ADOPTCTX(YES)를 설정해야한다고 가정 사이의 모든 데이터를 의미 클라이언트와 큐 관리자는 암호화되고 id/pw에 의해 연결이 인증됩니다. SSLCAUTH(REQUIRED)이 있더라도 채널의 SSLPEER 속성 또는 CHLAUTH TYPE(SSLPEERMAP) 규칙 SSLPEER 속성을 통해 특정 DN 값과 일치하도록 SVRCONN을 구성하지 않는 한 인증 양식을 제공하지 않습니다.

+0

마침내 SSLCAUTH를 OPTIONAL로 유지했습니다. 괜찮 았어. 저는 우리가 두 가지 방법 대신 단방향 암호화 방식을 사용하기를 원했기 때문에이 작업을 수행했습니다. 그리고 지금 연결이 작동 중입니다. 도움과 지식 공유에 감사드립니다 @ JoshMc –