이 절에서는 클라이언트와 브로커 간에 암호화된 메시지를 보내는 SSL(Secure Socket Layer) 표준을 기반으로 연결 서비스를 설정하는 방법에 대해 설명합니다. Message Queue는 다음과 같은 SSL 기반 연결 서비스를 지원합니다.
ssljms 서비스는 TCP/IP 전송 프로토콜을 사용하여 클라이언트와 브로커 간에 암호화된 보안 메시지를 전달합니다.
ssladmin 서비스는 TCP/IP 전송 프로토콜을 사용하여 Message Queue 명령 유틸리티(imqcmd)와 브로커 간에 암호화된 보안 연결을 생성합니다. 관리 콘솔(imqadmin)에서는 암호화된 연결이 지원되지 않습니다.
cluster 서비스는 TCP/IP 전송 프로토콜을 사용하여 클러스터의 브로커 간에 암호화된 보안 통신을 제공합니다.
httpsjms 서비스는 HTTP 전송 프로토콜과 HTTPS 터널 서블릿을 사용하여 클라이언트와 브로커 간에 암호화된 보안 메시지를 전달합니다.
이 절의 나머지 부분에서는 ssljms, ssladmin 및 cluster 연결 서비스를 사용하여 TCP/IP를 통해 보안 연결을 설정하는 방법에 대해 설명합니다. httpsjms 서비스를 사용하여 HTTP를 통해 보안 연결을 설정하는 방법은 부록 C, HTTP/HTTPS 지원을 참조하십시오.
TCP/IP를 통해 SSL 기반 연결 서비스를 사용하려면 키 도구 유틸리티(imqkeytool)를 사용하여 공개/개인 키 쌍을 생성합니다. 이 유틸리티는 브로커에 대해 연결을 요청하는 모든 클라이언트로 전달되는 자체 서명된 인증서에 공용 키를 포함합니다. 그러면 클라이언트에서 이 인증서를 사용하여 암호화된 연결을 설정합니다. 이 절에서는 그런 자체 서명된 인증서를 사용하여 SSL 기반 서비스를 설정하는 방법에 대해 설명합니다.
인증 수준을 강화하려면 인증 기관이 확인한 서명된 인증서를 사용할 수 있습니다. 서명된 인증서를 사용하려면 자체 서명된 인증서에 필요한 단계 이외에 몇 가지 추가 단계를 수행해야 합니다. 이 절에서 설명하는 단계를 수행한 다음 서명된 인증서 사용 에 설명된 추가 단계를 수행해야 합니다.
자체 서명된 인증서를 사용한 Message Queue의 SSL 지원은 클라이언트가 알려지고 신뢰할 수 있는 서버와 통신한다는 가정 하에 전송 데이터를 보호하기 위한 것입니다. 다음 절차에서는 자체 서명된 인증서를 사용하도록 SSL 기반 연결 서비스를 설정하는 데 필요한 단계를 보여 줍니다. 다음에 오는 하위 절에서는 각 단계에 대해 자세히 설명합니다.
자체 서명된 인증서를 생성합니다.
브로커에서 ssljms, ssladmin 또는 cluster 연결 서비스를 활성화합니다.
브로커를 시작합니다.
클라이언트를 구성하고 실행합니다.
이 단계는 ssljms 연결 서비스에만 적용되고 ssladmin 또는 cluster에는 적용되지 않습니다.
키 도구 유틸리티(imqkeytool)를 실행하여 브로커에 대한 자체 서명된 인증서를 생성합니다. (UNIX® 시스템에서 키 저장소를 만들 권한을 가지려면 유틸리티를 수퍼유저(root)로 실행해야 할 수도 있음). ssljms, ssladmin 또는 cluster 연결 서비스에 동일한 인증서를 사용할 수 있습니다.
imqkeytool -broker
키 도구 유틸리티가 키 저장소 비밀번호를 묻습니다.
Generating keystore for the broker ... Enter keystore password:
그런 다음 이 인증서가 속하는 브로커를 식별하는 정보를 묻습니다. 입력한 정보를 기반으로 X.500 고유 이름이 생성됩니다. 표 7–5에서는 프롬프트와 각 프롬프트에 대해 제공할 값을 보여 줍니다. 값은 대소문자가 구분되고 공백을 포함할 수 있습니다.
표 7–5 자체 서명된 인증서에 필요한 고유 이름 정보
프롬프트 |
X.500 속성 |
설명 |
예 |
---|---|---|---|
What is your first and last name? |
commonName (CN) |
브로커를 실행하는 서버의 정규화된 이름 |
mqserver.sun.com |
What is the name of your organizational unit? |
organizationalUnit (OU) |
부서 이름 |
purchasing |
What is the name of your organization? |
organizationName (ON) |
회사, 정부 기관 등과 같이 더 큰 조직의 이름 |
My Company, Inc. |
What is the name of your city or locality? |
localityName (L) |
구/군/시 이름 |
San Francisco |
What is the name of your state or province? |
stateName (ST) |
약어를 사용하지 않은 시/도의 전체 이름 |
California |
What is the two-letter country code for this unit? |
country (C) |
표준 2자 국가 코드 |
US |
정보 입력이 끝나면 키 도구 유틸리티에서 확인을 위해 해당 정보를 표시합니다. 예를 들면 다음과 같습니다.
Is CN=mqserver.sun.com, OU=purchasing, ON=My Company, Inc., L=San Francisco, ST=California, C=US correct?
현재 값을 적용하고 계속하려면 yes를 입력하고, 값을 다시 입력하려면 기본값을 적용하거나 no를 입력합니다. 확인이 끝난 후 키 쌍이 생성되는 동안 유틸리티가 일시 중지됩니다.
그런 다음 키 쌍을 잠글 비밀번호(키 비밀번호)를 묻습니다. 키 비밀번호 및 키 저장소 비밀번호와 동일한 비밀번호를 사용하려면 이 프롬프트에서 Return 키를 누릅니다.
지정한 비밀번호를 기억해 두십시오. 브로커를 시작할 때 이 비밀번호를 입력해야 브로커가 키 저장소를 열 수 있습니다. 비밀번호 파일에 키 저장소 비밀번호를 저장할 수 있습니다( 비밀번호 파일 참조).
키 도구 유틸리티는 자체 서명된 인증서를 생성한 다음 Message Queue의 키 저장소에 넣습니다. 부록 A, 플랫폼별 Message QueueTM 데이터 위치에 표시된 것처럼 키 저장소는 운영 체제에 따라 다른 디렉토리에 있습니다.
SSL 기반 연결 서비스의 Message Queue 키 저장소에 대해 구성 가능한 등록 정보는 다음과 같습니다.
imq.keystore.file.dirpath: 키 저장소 파일을 포함하는 디렉토리 경로입니다. 기본값은 부록 A, 플랫폼별 Message QueueTM 데이터 위치를 참조하십시오.
특정 문제를 해결하기 위해 키 쌍을 재생성해야 하는 경우도 있습니다. 예를 들어, 키 저장소 비밀번호를 잊은 경우나 브로커를 시작할 때 SSL 기반 서비스가 초기화되지 않고 예외가 발생되는 경우가 있습니다.
java.security.UnrecoverableKeyException:Cannot recover key
이 예외는 자체 서명된 인증서를 생성할 때의 키 저장소 비밀번호가 지정한 키 비밀번호와 다른 경우 발생할 수 있습니다.
부록 A, 플랫폼별 Message QueueTM 데이터 위치에 나와 있는 위치에 있는 브로커의 키 저장소를 제거합니다.
위에서 설명한 것처럼 imqkeytool을 다시 실행하여 새 키 쌍을 생성합니다.
브로커에서 SSL 기반 연결 서비스를 활성화하려면 ssljms 또는 ssladmin을 imq.service.activelist 등록 정보에 추가해야 합니다.
브로커의 인스턴스 구성 파일을 엽니다.
인스턴스 구성 파일은 구성 파일이 연결되어 있는 브로커 인스턴스의 이름(instanceName)으로 식별되는 디렉토리에 있습니다(부록 A, 플랫폼별 Message QueueTM 데이터 위치 참조).
.../instances/instanceName/props/config.properties
imq.service.activelist 등록 정보에 항목을 추가하고(항목이 아직 없는 경우) 목록에 원하는 SSL 기반 서비스를 포함시킵니다.
기본적으로 이 등록 정보에는jms 및 admin 연결 서비스가 포함됩니다. 활성화할 SSL 기반 서비스(ssljms, ssladmin 또는 둘 다)를 추가합니다.
imq.service.activelist=jms,admin,ssljms,ssladmin
SSL 기반 cluster 연결 서비스는 imq.cluster.transport 등록 정보를 imq.service.activelist 등록 정보 대신 사용하여 활성화합니다. 자세한 내용은 브로커 연결을 참조하십시오.
인스턴스 구성 파일을 저장하고 닫습니다.
브로커를 시작하고 키 저장소 비밀번호를 제공합니다. 다음과 같은 두 가지 방법으로 비밀번호를 제공할 수 있습니다.
브로커를 시작할 때 비밀번호를 묻는 프롬프트가 표시되게 합니다.
imqbrokerd Please enter Keystore password:
비밀번호 파일에서 설명한 대로 비밀번호 파일에 비밀번호를 입력합니다. 그런 다음 imq.passfile.enabled 등록 정보를 true로 설정하고 다음 중 하나를 수행합니다.
비밀번호 파일의 위치를 imqbrokerd 명령에 전달합니다.
imqbrokerd -passfile /passfileDirectory/passfileName
-passfile 옵션 없이 브로커를 시작하되, 다음의 두 브로커 구성 등록 정보를 사용하여 비밀번호 파일의 위치를 지정합니다.
imq.passfile.dirpath=/passfileDirectory imq.passfile.name=passfileName
SSL을 사용하는 브로커나 클라이언트를 시작할 때 몇 초간 CPU 사용량이 갑자기 증가하는 경우가 있을 수 있습니다. 이것은 Message Queue에서 난수를 생성하는 데 사용하는 JSSE(Java Secure Socket Extension) 메서드 java.security.SecureRandom이 초기 난수 시드를 생성하는 데 많은 시간이 소요되기 때문입니다. 시드를 만들고 나면 CPU 사용 수준이 정상으로 돌아갑니다.
SSL 기반 연결 서비스를 사용하도록 클라이언트를 구성하는 절차는 ssljms 연결 서비스를 사용하는 응용 프로그램 클라이언트인지 ssladmin 연결 서비스를 사용하는 Message Queue 관리 클라이언트(예: imqcmd)인지 여부에 따라 다릅니다.
응용 프로그램 클라이언트의 경우 다음과 같은 .jar 파일이 CLASSPATH 변수에 지정되어 있어야 합니다.
imq.jar
jms.jar
Java 2 Software Development Kit(J2SDK) 1.4 이전 버전을 사용할 경우 다음과 같은 JSSE(Java Secure Socket Extension) 및 JNDI(Java Naming and Directory Interface) .jar 파일을 포함시켜야 합니다.
jsse.jar
jnet.jar
jcert.jar
jndi.jar
J2SDK 1.4 이상에서는 JSSE 및 JNDI를 기본적으로 지원하므로 이러한 파일을 포함시킬 필요가 없습니다.
CLASSPATH 파일을 제대로 지정한 경우 다음과 같은 명령을 입력하여 클라이언트를 시작하고 브로커의 ssljms 연결 서비스에 연결할 수 있습니다.
java -DimqConnectionType=TLS clientAppName
그러면 연결에서 SSL 기반 연결 서비스를 사용하게 됩니다.
관리 클라이언트의 경우 imqcmd 명령을 호출할 때 -secure 옵션을 포함시켜 보안 연결을 설정할 수 있습니다. 예를 들면 다음과 같습니다.
imqcmd list svc -b hostName:portNumber -u adminName -secure
여기서 adminName은 Message Queue 사용자 저장소에 유효한 항목입니다. 이 명령은 비밀번호를 묻는 프롬프트를 표시합니다(플랫 파일 저장소를 사용하는 경우 기본 관리자 비밀번호 변경 참조).
연결 서비스를 나열하는 것은 ssladmin 서비스가 실행 중이며 다음 출력과 같이 보안 관리 연결을 성공적으로 설정할 수 있다는 것을 확인하는 방법입니다.
Listing all the services on the broker specified by: Host Primary Port localhost 7676 Service Name Port Number Service State admin 33984 (dynamic) RUNNING httpjms - UNKNOWN httpsjms - UNKNOWN jms 33983 (dynamic) RUNNING ssladmin 35988 (dynamic) RUNNING ssljms dynamic UNKNOWN Successfully listed services. |
서명된 인증서는 자체 서명된 인증서보다 더 높은 수준의 서버 인증을 제공합니다. 서명된 인증서는 클라이언트와 브로커 간에만 구현 가능하고 동일 클러스터 내의 브로커 간에는 구현할 수 없습니다. 그럴 경우 위에서 설명한 자체 서명된 인증서 구성 단계 이외에 다음과 같은 추가 단계를 수행해야 합니다. 이러한 단계에 대해서는 다음에 나오는 하위 절에 자세히 설명되어 있습니다.
다음 절차에서는 서명된 인증서를 가져와서 설치하는 방법에 대해 설명합니다.
J2SE keytool 명령을 사용하여 이전 절에서 생성한 자체 서명된 인증서에 대한 CSR(Certificate Signing Request)을 생성합니다.
keytool 명령에 대한 자세한 내용은 을 참조하십시오.
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html
예를 들면 다음과 같습니다.
keytool -certreq -keyalg RSA -alias imq -file certreq.csr -keystore /etc/imq/keystore -storepass myStorePassword |
이 명령은 지정된 파일(이 예의 경우 certreq.csr)에서 인증서를 캡슐화하는 CSR을 생성합니다.
CSR을 사용하여 서명된 인증서를 생성하거나 요청합니다.
이 작업은 다음 중 한 가지 방법으로 수행할 수 있습니다.
Thawte 또는 Verisign과 같이 공신력 있는 인증 기관(CA)에서 서명한 인증서를 가져옵니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 CA의 설명서를 참조하십시오.
SSL 서명 소프트웨어 패키지를 사용하여 인증서에 직접 서명합니다.
결과적으로 만들어지는 서명된 인증서는 ASCII 문자 시퀀스입니다. CA로부터 서명된 인증서를 받을 때 해당 인증서는 전자 메일 첨부 파일이나 메시지 텍스트로 전달될 수 있습니다.
서명된 인증서를 파일에 저장합니다.
아래 지침에서는 broker.cer이라는 이름 예를 사용하여 브로커 인증서를 나타냅니다.
J2SE가 기본적으로 인증 기관을 지원하는지 여부를 확인합니다.
다음 명령은 시스템 키 저장소에 있는 루트 CA를 나열합니다.
keytool -v -list -keystore $JAVA_HOME/lib/security/cacerts
해당 CA가 목록에 있는 경우 다음 단계를 건너뜁니다.
인증 기관이 J2SE에서 지원되지 않는 경우 CA의 루트 인증서를 Message Queue 키 저장소로 가져옵니다.
예를 들면 다음과 같습니다.
keytool -import -alias ca -file ca.cer -noprompt -trustcacerts -keystore /etc/imq/keystore -storepass myStorePassword
여기서 ca.cer은 CA에서 가져온 루트 인증서가 들어 있는 파일입니다.
CA 테스트 인증서를 사용하는 경우 테스트 CA 루트 인증서를 가져와야 할 수 있습니다. CA에는 복사본을 가져오는 방법에 대한 지침이 있어야 합니다.
서명된 인증서를 키 저장소로 가져와서 자체 서명된 원본 인증서를 대체합니다.
예를 들면 다음과 같습니다.
keytool -import -alias imq -file broker.cer -noprompt -trustcacerts -keystore /etc/imq/keystore -storepass myStorePassword
여기서 broker.cer은 CA로부터 받은 서명된 인증서가 들어 있는 파일입니다.
Message Queue 키 저장소에는 이제 SSL 연결에 사용할 서명된 인증서가 포함되어 있습니다.
서명된 인증서를 요구하도록 Message Queue 클라이언트 런타임을 구성하고 인증서에 서명한 인증 기관을 신뢰하는지를 확인해야 합니다.
연결 팩토리의 imqSSLIsHostTrusted 속성을 false로 설정합니다.
기본적으로 클라이언트가 브로커 연결을 설정하는 데 사용할 연결 팩토리 객체의 imqSSLIsHostTrusted 속성은 true로 설정되어 있습니다. 즉, 클라이언트 런타임에서 제공된 인증서를 수용합니다. 클라이언트 런타임이 제공되는 모든 인증서를 검증하도록 이 값을 false로 변경해야 합니다. 인증서 서명자가 클라이언트의 트러스트 저장소에 없는 경우 검증이 실패합니다.
서명 기관이 클라이언트의 트러스트 저장소에 등록되어 있는지 여부를 확인합니다.
클라이언트가 인증 기관에서 서명한 인증서를 수용하는지 여부를 테스트하려면 SSL 기반 클라이언트 구성 및 실행에서 설명한 것처럼 SSL 연결 설정을 시도합니다. CA가 클라이언트의 트러스트 저장소에 있으면 성공적으로 연결되고 다음 단계를 건너뛸 수 있습니다. 연결이 실패하고 인증서 검증 오류가 발생하면 다음 단계로 이동합니다.
서명 CA의 루트 인증서를 클라이언트의 트러스트 저장소에 설치합니다.
클라이언트는 기본적으로 키 저장소 파일 cacerts 및 jssecacerts를 검색하므로 인증서를 이러한 파일에 설치할 때 추가 구성이 필요하지 않습니다. 다음 예에서는 Verisign 인증 기관의 테스트 루트 인증서를 testrootca.cer 파일에서 기본 시스템 인증서 파일 cacerts에 설치합니다.이 예제에서는 J2SE가 $JAVA_HOME/usr/j2se 디렉토리에 설치된다고 가정합니다.
keytool -import -keystore /usr/j2se/jre/lib/security/cacerts -alias VerisignTestCA -file testrootca.cer -noprompt -trustcacerts -storepass myStorePassword
대체(권장) 옵션으로 루트 인증서를 대체 시스템 인증서 파일 jssecacerts에 설치할 수 있습니다.
keytool -import -keystore /usr/j2se/jre/lib/security/jssecacerts -alias VerisignTestCA -file testrootca.cer -noprompt -trustcacerts -storepass myStorePassword
세 번째 방법으로 루트 인증서를 다른 키 저장소 파일에 설치하고 해당 저장소 파일을 트러스트 저장소로 사용하도록 클라이언트를 구성할 수 있습니다. 다음 예에서는 /home/smith/.keystore 파일에 설치합니다.
keytool -import -keystore /home/smith/.keystore -alias VerisignTestCA -file testrootca.cer -noprompt -trustcacerts -storepass myStorePassword
클라이언트는 기본적으로 이 키 저장소를 검색하지 않기 때문에 클라이언트에서 트러스트 저장소로 사용하도록 해당 위치를 명시적으로 지정해야 합니다. 이 작업은 클라이언트가 다음을 실행 중일 때 Java 시스템 등록 정보 javax.net.ssl.trustStore를 설정하여 수행합니다.
javax.net.ssl.trustStore=/home/smith/.keystore