SSL(Secure Sockets Layer)을 사용하여 통신 보안

SSL(Secure Sockets Layer) 프로토콜은 WebSphere® Application Server를 사용하는 클라이언트와 서버 사이의 안전한 연결을 위해 인증, 데이터 서명, 데이터 암호화를 포함하여 전송 계층 보안을 제공합니다. SSL의 기반 기술은 공개 키 엔티티이며 이를 사용하면 엔티티가 해당 공개 키를 사용하여 데이터를 암호화하는 경우 해당 공개 키를 포함하는 엔티티만 해당 데이터를 복호화하도록 보장합니다.

WebSphere Application Server는 Java™ Secure Sockets Extension(JSSE)을 안전한 연결의 SSL 구현으로 사용합니다. JSSE는 Java 2 Standard Edition(J2SE) 스펙의 파트이며 Java Runtime Extension(JRE)의 IBM® 구현에 포함됩니다. JSSE는 SSL에서 안전한 연결이 대부분의 프로토콜에서 존재하도록 제공되는 핸드쉐이크 협상 및 보호 기능을 처리합니다. JSSE는 안전한 연결 보호 및 일부 데이터 암호화를 위해 X.509 인증서 기반의 비대칭 키 쌍을 사용합니다. 키 쌍은 더 큰 데이터 블록을 암호화하는 세션 기반의 비밀 키를 효율적으로 암호화합니다. SSL 구현은 X.509 인증서를 관리합니다.

WebSphere Application Server는 Java SE7을 제공합니다. 기본적으로 Java SE 7은 SNI(Server Name Indication)를 사용합니다. SNI는 TLS 프로토콜의 확장입니다. SNI를 사용하여 클라이언트는 연결하려는 호스트 이름을 지정할 수 있습니다. 리턴된 인증서가 예상 호스트 이름에 일치하지 않으면 예외가 처리됩니다.

일부 프록시 환경에서 이로 인해 오류가 발생할 수 있습니다. 클라이언트는 프록시 인증서 수신을 기대하지만 엔드포인트 종료점의 인증서를 대신 수신합니다.

X.509 인증서 관리

WebSphere Application Server의 안전 통신에는 디지털 서명의 X.509 인증서가 필요합니다. X.509 인증서 컨텐츠(예: 해당 식별 이름 및 만기)는 인증 기관(CA)으로 서명, NodeDefaultRootStore 또는 DmgrDefaultRootStore의 루트 인증서로 서명 또는 자체 서명됩니다. 신뢰 CA가 X.509 인증서를 서명하면 WebSphere Application Server는 인증서를 식별하고 자율적으로 분배합니다. 인증서는 일반 공개를 위해 엔티티 ID를 표시하기 때문에 CA에서 서명해야 합니다. 일반 공개에서의 연결을 허용하는 서버 측 포트는 CA에서 서명한 인증서를 사용해야 합니다. 대부분의 클라이언트와 브라우저는 이미 X.509 인증서의 유효성을 검증할 수 있는 서명자 인증서를 가지고 있기 때문에 서명자 교환이 연결 성공에 필요하지는 않습니다.

자체 서명 X.509 인증서의 ID는 제어 환경(예: 내부 네트워크 통신)내의 피어 내에서만 신뢰하고 서명자 인증서를 승인할 수 있습니다. 신뢰 핸드쉐이크를 완료하려면 우선 엔티티 인증서 사본을 엔티티에 연결하는 모든 피어에 전송해야 합니다.

CA, 체인됨 및 자체 서명 X.509 인증서는 Java 키 저장소에 있습니다. JSSE는 인증서가 있는 키 저장소의 참조를 제공합니다. Java Cryptographic Extension(JCE) 기반 및 하드웨어 기반 키 저장소를 포함하여 많은 유형의 키 저장소에서 선택 가능합니다. 일반적으로 각 JSSE 구성에는 두 개의 Java 키 저장소 참조가 있으며 이는 키 저장소와 신뢰 저장소입니다. 키 저장소 참조는 개인 인증서를 보유하는 Java 키 저장소 오브젝트를 나타냅니다. 신뢰 저장소 참조는 서명자 인증서를 보유하는 Java 키 저장소 오브젝트를 나타냅니다.

개인 키가 없는 개인 인증서는 핸드쉐이크 중에 이를 소유하는 엔티티를 나타내는 X.509 인증서입니다. 개인 인증서는 공개 및 개인 키 모두를 포함할 수 있습니다. 서명자 인증서는 피어 엔티티 또는 자체를 나타내는 X.509 인증서입니다. 서명자 인증서는 공개 키만 포함하고 피어 투 피어 핸드쉐이크 중에 수신되는 ID 서명을 확인합니다.

자세한 정보는 올바른 SSL 서명자 인증서를 플러그인 키 저장소에 추가의 내용을 참조하십시오.

키 저장소에 대한 자세한 정보는 SSL을 위한 키 저장소 구성의 내용을 참조하십시오.

서명자 교환

SSL 연결을 구성할 때 특정 엔티티에 대한 개인 인증서에서 신뢰를 설정하기 위해 서명자를 교환할 수 있습니다. 서명자 교환을 통해 피어 키 저장소에서 X.509 인증서를 추출하고 이를 다른 엔티티의 키 저장소에 추가하여 두 피어 엔티티가 연결할 수 있습니다. 서명자 인증서는 CA에서 루트 서명자 인증서로 시작 가능하거나 체인된 인증서의 루트 서명자 인증서 또는 중간 서명자 인증서로 시작될 수 있습니다. 서명자 인증서를 공개 키가 포함된 X.509 인증서인 자체 서명 인증서에서 직접 추출할 수도 있습니다.

그림 1은 가상의 키 저장소와 신뢰 저장소 구성을 설명합니다. SSL 구성은 다른 엔티티에 연결 가능한 엔티티를 판별하고 SSL 핸드쉐이크에서 신뢰되는 피어 연결을 판별합니다. 필수 서명자 인증서가 없는 경우, 피어를 신뢰할 수 없어서 핸드쉐이크가 실패합니다.
그림 1. 서명자 교환
그림 1은 가상의 키 저장소와 신뢰 저장소 구성을 설명합니다. SSL 구성은 다른 엔티티에 연결 가능한 엔티티를 판별하고 SSL 핸드쉐이크에서 신뢰되는 피어 연결을 판별합니다. 필수 서명자 인증서가 없는 경우, 피어를 신뢰할 수 없어서 핸드쉐이크가 실패합니다.

이 예에서 엔티티 A의 신뢰 저장소에는 세 개의 서명자가 포함됩니다. 엔티티 A는 세 서명자 중 하나가 해당 개인 인증서의 유효성을 검증하면 모든 피어에 연결 가능합니다. 예를 들어, 엔티티 A는 서명자가 두 서명된 개인 인증서를 모두 신뢰할 수 있기 때문에 엔티티 B 또는 엔티티 C에 연결할 수 있습니다. 엔티티 B의 신뢰 저장소에는 한 개의 서명자가 포함됩니다. 엔티티 B는 피어 엔드포인트가 인증서 엔티티 C 인증서 1을 해당 ID로 사용하는 경우에만 엔티티 C에만 연결할 수 있습니다. 엔티티 C에 대해 다른 개인 인증서를 사용하는 포트는 엔티티 B에서 신뢰되지 않습니다. 엔티티 C는 엔티티 A에만 연결할 수 있습니다.

예에서 자체 서명 구성은 서명자와 인증서 사이의 1대1 관계를 나타내는 것 같습니다. 그렇지만 CA가 인증서를 서명하면 일반적으로 한 번에 여러 개를 서명합니다. 단일 CA 서명자를 사용하는 장점은 피어에서 사용하기 위해 CA에서 생성되는 개인 인증서를 유효성 검증할 수 있다는 점입니다. 그렇지만 서명자가 공개 CA인 경우 서명된 인증서는 대상 엔티티 이외에 다른 회사용으로 생성되었을 수도 있다는 점에 주의해야 합니다. 내부 통신을 위해 개인 CA 및 자체 서명 인증서가 공개 CA를 선호합니다. 이를 사용하면 필요한 연결을 격리시켜서 원하지 않는 연결을 방지할 수 있기 때문입니다.

SSL 구성

SSL 구성은 엔드포인트 또는 WebSphere Application Server 토폴로지의 엔드포인트 세트에 연관시킬 수 있는 구성 속성 세트로 구성됩니다. SSL 구성을 사용하여 서버가 SSL 소켓 팩토리 확보에 사용하는 기본 JSSE 오브젝트인 SSLContext 오브젝트를 작성할 수 있습니다. 다음 구성 속성을 관리할 수 있습니다.
  • SSLContext 오브젝트의 별명
  • 핸드쉐이크 프로토콜 버전
  • 키 저장소 참조
  • 신뢰 저장소 참조
  • 키 관리자
  • 하나 이상의 신뢰 관리자
  • 암호 스위트 그룹 또는 특정 암호 스위트 목록에 대한 보안 레벨 선택
  • 클라이언트 및 서버 연결에 대한 인증서 별명 선택
각 SSL 구성 속성의 고유 특성에 대해서는 SSL 구성의 내용을 참조하십시오.
참고: WebSphere는 기본적으로 서버를 더 안전하게 하기 위해 HIGH 암호 목록에 RC4 암호 스위트가 있는 것을 허용하지 않습니다. 이 변경 전에는 RC4 암호가 기본적으로 SSL 핸드쉐이크에서 사용되었습니다. RC4 암호를 제거하여 AES 암호가 대신 사용됩니다. 더 안전한 AES 암호를 사용하는 경우 성능 저하가 발생할 수 있습니다.

SSL 구성 선택

WebSphere Application Server의 이전 릴리스에서는 SSL 구성 별명을 직접 선택해서만 SSL 구성을 참조할 수 있었습니다. 각 안전 엔드포인트는 SSL 구성 레퍼토리 내에서 유효한 SSL 구성을 참조하는 별명 속성으로만 표기됩니다. 한 개의 구성 변경이 있으며 다양한 프로세스를 통해 많은 별명 참조를 다시 구성해야 했었습니다. 현재 릴리스도 여전히 직접 선택을 지원하지만 이 접근 방식은 더 이상 권장되지 않습니다.

현재 릴리스는 SSL 구성 관리에 대한 향상된 기능과 SSL 구성 선택 시 더 많은 융통성을 제공합니다. 이 릴리스에서는 다음과 같은 접근 방식 중 하나에서 선택할 수 있습니다.
프로그래밍 방식 선택
아웃바운드 연결 전에 실행 중인 스레드에서 SSL 구성을 설정할 수 있습니다. WebSphere Application Server는 IIOP(Internet Inter-ORB Protocol), Java Message Service(JMS), Hyper Text Transfer Protocol(HTTP), Lightweight Directory Access Protocol(LDAP)을 포함하여 대부분의 시스템 프로토콜이 구성을 허용하도록 합니다. JSSEHelper API를 사용하여 아웃바운드 SSL 구성을 프로그램으로 지정의 내용을 참조하십시오.
동적 선택
사전 정의된 선택 기준으로 SSL 구성을 동적으로 특정 대상 호스트, 포트 또는 아웃바운드 프로토콜과 연관시킬 수 있습니다. 연결이 설정되면 WebSphere Application Server는 대상 호스트와 포트가 호스트의 도메인 부분을 포함하는 사전 정의 기준과 일치하는지 확인하기 위해 검사합니다. 또한, 특정 아웃바운드 SSL 구성 및 인증서 별명 선택사항에 대한 프로토콜을 사전 정의할 수도 있습니다. 자세한 정보는 SSL(Secure Sockets Layer) 구성의 동적 아웃바운드 선택사항의 내용을 참조하십시오.

SSL(Secure Sockets Layer) 구성의 동적 아웃바운드 선택사항은 서버에서 사용할 수 있는 연결 정보를 기반으로 하기 때문에 클라이언트 소켓 작성이 com.ibm.websphere.ssl.protocol.SSLSocketFactory에서 수행되도록 서버가 아웃바운드 프로토콜, 호스트 또는 포트와 일치시킬 수 있습니다. SOAP 및 RMI(Remote Method Invocation)와 같은 WebSphere 관리 커넥터 연결 정보는 스레드에 배치되며 수행하려는 동적 아웃바운드 선택사항에 사용할 수 있습니다. 동적 아웃바운드 선택사항 프로세스는 SSL 특성이 JSSEHelper API를 사용하여 아웃바운드 SSL 구성을 프로그램으로 지정에서 설명하는 것과 유사하게 검색될 때 설정되는 연결 정보를 기반으로 합니다.

아웃바운드 연결이 고객 작성 애플리케이션에서 수행되면 연결 정보 파트를 사용할 수 없을 수도 있습니다. 이 애플리케이션 일부는 연결 설정을 위해 프로토콜에 대해 API 호출을 수행합니다. API는 결국 com.ibm.websphere.ssl.protocol.SSLSocketFactory에서 createSocket() 메소드 중 하나를 호출하여 프로세스를 완료합니다. 핵심 정보: 동적 아웃바운드 선택사항에 대한 모든 연결 정보를 사용할 수는 없을 수도 있으며 동적 아웃바운드 선택사항 연결 필터를 조정하고 연결 정보에 누락된 부분에 별표(*)로 채워야 할 수도 있습니다. 예를 들어, URL 오브젝트의 openConnection() 호출은 결국 createSocket(java.net.Socket socket, String host, int port, boolean autoClose)를 호출합니다. 연결 정보는 제공된 포트 및 호스트를 사용하여 빌드될 수 있지만 제공된 프로토콜은 없습니다. 이 경우, 와일드카드, 별표(*)는 동적 선택사항 연결 정보 프로토콜 파트에 대해 사용해야 합니다.

대부분의 createSocket() 메소드는 호스트 또는 IP 주소 및 포트를 매개변수로 사용합니다. 동적 아웃바운드 선택사항 연결 필터는 호스트 및 포트와 빌드 가능합니다. 아무 매개변수도 지정되지 않은 기본 메소드 createSocket()은 소켓 팩토리가 연결 정보로 인스턴스화된 경우를 제외하고는 아웃바운드 선택사항 연결 빌드에 대한 아무 정보도 포함하지 않으며 사용 가능한 연결 정보가 없는 경우 SSL 구성 선택에 대한 다른 메소드 중 하나를 사용하여 이 주제 "프로그램화된 선택사항"을 설명하는 것이 좋습니다.

직접 선택
이전 릴리스의 특정 별명을 사용하여 SSL 구성을 선택할 수 있습니다. 이 선택사항 메소드는 많은 애플리케이션 및 프로세스가 별명 참조를 기반으로 하기 때문에 역호환성을 위해 유지됩니다.
범위 선택
WebSphere Application Server 관리 범위와 SSL 구성 및 해당 SSL 구성에 연관된 키 저장소에 있는 해당 인증서 별명을 연관시킬 수 있습니다. 이 접근 방식은 SSL 구성을 중앙 집중식으로 관리하는 데 권장됩니다. 엔드포인트는 셀의 한 토폴로지 보기에 있기 때문에 더 효율적으로 관리할 수 있습니다. 범위 사이의 상속 관계를 사용하면 설정해야 하는 SSL 구성 지정 수를 줄입니다.
SSL 구성을 셀 범위와 연관시킬 때마다 셀 내의 노드 범위는 자동으로 구성 특성을 상속합니다. 그렇지만 SSL 구성을 노드에 지정할 때 노드 구성은 노드가 셀에서 상속한 구성을 대체합니다. 유사하게 노드의 모든 애플리케이션 서버는 자동으로 해당 노드에 대한 SSL 구성을 상속하며 이 지정을 대체한 경우는 제외됩니다. 특정 구성을 대체한 경우를 제외하고는 토폴로지는 각 애플리케이션 서버에 대해 셀 레벨에서 엔드포인트 레벨로의 상속 규칙을 사용합니다.
참고: 애플리케이션이 토폴로지에서 각 SSL 구성에 대해 개별적으로 설정된 SSL 구성을 사용하지만 애플리케이션 서버는 셀 레벨에서 엔드포인트 레벨로 배치되는 SSL 구성을 상속한 경우 서버 사이에서 통신 오류가 발생할 수 있습니다(예: 핸드쉐이크 오류). 애플리케이션이 SSL 구성의 중앙 관리와 일관성있개 운영되도록 해야 합니다.
토폴로지 보기는 인바운드 트리 및 아웃바운드 트리를 표시합니다. 서버의 아웃바운드 연결 및 서버의 인바운드 연결을 바탕으로 SSL 연결의 양쪽에 대해 다른 SSL 구성을 선택할 수 있습니다. 자세한 정보는 SSL 구성의 중앙 관리의 내용을 참조하십시오.
런타임은 SSL 구성을 선택하는 방법이 다양하기 때문에 선택해야 하는 SSL 구성 판별에 대해 우선 순서를 사용합니다. 구성 접근 방식을 선택할 때 다음 우선 순서를 고려하십시오.
  1. 프로그램화된 선택. 애플리케이션이 실행 중인 스레드에 com.ibm.websphere.ssl.JSSEHelper API(Application Programming Interface)를 사용하여 SSL 구성을 설정하는 경우 SSL 구성은 가장 높은 우선순위로 보장됩니다.
  2. 아웃바운드 호스트 및 포트 또는 프로토콜에 대한 동적 선택 기준.
  3. 직접 선택.
  4. 범위 선택. 범위 상속은 선택하는 엔드포인트가 SSL 구성과 연관되고 이 선택을 대체하지 않는 그 밑의 모든 범위까지 상속되도록 보장합니다.

기본 체인된 인증서 구성

기본적으로 WebSphere Application Server는 각 노드에 대해 고유한 체인된 인증서를 작성합니다. 체인된 인증서는 DmgrDefaultRootStore 또는 NodeDefaultRootStore에 저장되는 루트 자체 서명 인증서로 서명됩니다. WebSphere Application Server는 더 이상 제품에서 제공되는 자체 서명 인증서 또는 기본 또는 더미 인증서를 사용하지 않습니다. key.p12 기본 키 저장소와 trust.p12 신뢰 저장소는 노드 디렉토리 내의 구성 저장소에 저장됩니다. 기본 루트 인증서는 노드 디렉토리 밑의 구성 저장소에서 root-key.p12에 저장됩니다.

모든 노드는 이 공통 신뢰 저장소(trust.p12)의 기본 루트 인증서에서 해당 서명자 인증서를 넣습니다. 또한, 노드를 연합한 후 기본 SSL 구성은 자동으로 셀 디렉토리에 있는 공통 신뢰 저장소를 지시하도록 수정됩니다. 노드는 이제 셀의 다른 모든 서버와 통신할 수 있습니다.

모든 기본 SSL 구성에는 이름 접미부가 DefaultKeyStore인 키 저장소와 이름 접미부가 DefaultTrustStore인 신뢰 저장소, 이름 접미부가 DefaultRootStore인 루트 저장소가 포함됩니다. 이 기본 접미부는 WebSphere Application Server 런타임이 개인 인증서의 루트 서명자를 공통 신뢰 저장소에 추가하도록 지시합니다. 신뢰 저장소 이름이 DefaultKeyStore로 끝나지 않으면 키 저장소 루트 서명자 인증서는 서버 연합 시 공통 신뢰 저장소에 추가되지 않습니다. 기본 SSL 구성을 변경할 수는 있지만 올바른 신뢰가 서로의 관리 연결에 대해 설정되도록 해야 합니다.

자세한 정보는 SSL에 기본 체인된 인증서 구성 [AIX Solaris HP-UX Linux Windows][AIX Solaris HP-UX Linux Windows]SSL에서 웹 서버 플러그인 기본 구성의 내용을 참조하십시오.

인증서 만기 모니터링

인증서 모니터링은 각 노드에 대한 기본 체인된 인증서의 만기가 허용되지 않도록 합니다. 인증서 만기 모니터링 기능은 인증서 및 서명자가 만기 설정된 경우 경고를 발행합니다. WebSphere Application Server 구성으로 관리되는 키 저장소의 해당 인증서 및 서명자는 모니터 가능합니다. 만기 모니터를 구성하여 자동으로 인증서를 대체할 수 있습니다. 체인된 인증서는 초기 작성에 사용된 동일 데이터를 기반으로 다시 작성되며 원래 인증서를 서명한 동일한 루트 인증서로 서명됩니다. 자체 서명 인증서 또는 체인된 인증서도 초기 작성에 사용되는 동일 데이터를 기반으로 다시 작성됩니다.

모니터는 자동으로 이전 서명자를 WebSphere Application Server로 관리하는 키 저장소의 새 체인된 또는 자체 서명 인증서로 대체합니다. 연합 중에 또는 관리를 통해 런타임에서 발생한 기존 서명자 교환은 보존됩니다. 자세한 정보는 SSL에서 인증서 만기 모니터링의 내용을 참조하십시오.

만기 모니터는 DmgrDefaultRootStore 또는 NodeDefaultRootStore의 루트 인증서로 서명된 체인된 개인 인증서를 대체하도록 구성됩니다. 인증서는 원래 인증서 서명에 사용된 동일한 루트 인증서를 사용하여 업데이트됩니다.

모니터는 자동으로 이전 서명자를 WebSphere Application Server로 관리하는 키 저장소의 새 자체 서명 인증서로 대체합니다. 연합 중에 또는 관리를 통해 런타임에서 발생한 기존 서명자 교환은 보존됩니다. 자세한 정보는 SSL에서 인증서 만기 모니터링의 내용을 참조하십시오.

WebSphere Application Server 클라이언트: 서명자 교환 요구사항

새 체인된 인증서는 해당 초기 시작 시에 각 노드에 대해 생성됩니다. 신뢰를 보장하기 위해 클라이언트는 연결 설정을 위한 루트 서명자로 지정되어야 합니다. 현재 릴리스의 체인된 인증서 소개를 통해 이 프로세스가 간단해집니다. 단기 자체 서명 인증서의 서명자를 교환하기 보다는 개인 인증서 업데이트에서 신뢰 보존을 허용하는 장기의 루트 서명자를 교환할 수 있습니다. 또한, 클라이언트가 다음 옵션 중 하나로 연결해야 하는 다양한 노드의 서명자 인증서에 대한 액세스를 확보할 수 있습니다(자세한 정보 SSL의 클라이언트 서명자 검색을 위한 보안 설치의 내용을 참조).
  • 서명자 교환 프롬프트를 사용하여 서버 연결 중에 신뢰 저장소에 없던 서명자 인증서를 가져올 수 있습니다. 기본적으로 이 프롬프트는 관리 연결용으로 사용되며 모든 클라이언트 SSL 구성에 사용할 수 있습니다. 이 프롬프트가 사용되면 서명자가 아직 없는 서버에 대한 모든 연결은 확인을 위해 서버의 서명자와 인증서 정보 및 인증서의 SHA(Secure Hash Algorithm) 다이제스트를 제공합니다. 사용자에게는 이 신임 정보 허용 여부에 대한 선택이 주어집니다. 신임이 승인되면 서명자가 명시적으로 제거될 때까지 클라이언트의 truststore에 서명자가 추가됩니다. 서명자 교환 프롬프트는 개인 인증서가 변경되지 않았다면 동일 서버 연결에 대해 다시 발생하지는 않습니다.
    주의: SHA 다이제스트를 확인하지 않는 서명자 교환 프롬프트를 신뢰하는 것은 안전하지 않습니다. 확인되지 않은 프롬프트는 인증서가 신뢰되지 않은 경우 브라우저에서 시작됩니다.
  • 서버에 연결하기 전에 retrieveSigners 관리 스크립트를 클라이언트에서 실행할 수 있습니다. 서명자를 다운로드하기 위해 관리 권한이 필요하지 않습니다. 서명자를 업로드하려면 관리자 역할 권한이 필요합니다. 스크립트는 지정한 서버 신뢰 저장소에서 지정한 클라이언트 신뢰 저장소로 모든 서명자를 다운로드하고 신뢰 저장소에서 특정 별명만 다운로드하도록 호출 가능합니다. 스크립트를 호출하여 서명자를 서버 신뢰 저장소로 업로드할 수도 있습니다. CellDefaultTrustStore 신뢰 저장소를 지정한 서버의 신뢰 저장소 및 모든 셀의 공통 신뢰 저장소로 선택한 경우, 해당 셀의 모든 서명자는 일반적으로 ClientDefaultTrustStore인 지정한 클라이언트 신뢰 저장소로 다운로드됩니다. 자세한 정보는 retrieveSigners 명령의 내용을 참조하십시오.
  • 구성 저장소의 셀 디렉토리에 있는 trust.p12 공통 신뢰 저장소에 클라이언트를 실제로 분배할 수 있습니다. 그렇지만 이 분배 시에는 올바른 비밀번호를 ssl.client.props 클라이언트 SSL 구성 파일에 지정해야 합니다. 이 신뢰 저장소의 기본 비밀번호는 WebAS입니다. 분배 전에 기본 비밀번호를 변경하십시오. 실제 분배는 이전 옵션만큼 효율적이지 않습니다. 서버에서 개인 인증서를 변경하는 경우 자동 교환이 실패할 수 있습니다.

동적 SSL 구성 변경

WebSphere Application Server에 대한 SSL 런타임은 대부분의 SSL 연결에 대한 리스너를 유지보수합니다. SSL 구성을 변경하면 인바운드 연결 리스너가 새 SSLContext 오브젝트를 작성합니다. 기존 연결은 계속 현재 SSLContext를 사용합니다. 아웃바운드 연결은 시도 시에 자동으로 새 구성 특성을 사용합니다.

최고 사용 이외의 시간 중에 SSL 구성을 동적으로 변경하여 시간 관련 문제 가능성을 줄이고 서버가 다시 시작되는 가능성을 방지하십시오. 동적 변경을 승인하도록 런타임을 사용하는 경우, SSL 구성을 변경하고 security.xml 파일을 저장하십시오. 새 security.xml 파일이 각 노드에 도달할 때 변경사항이 적용됩니다.

참고: 구성 변경으로 인해 SSL 핸드쉐이크가 실패하면 관련 연결도 실패하여 가동 중단이 발생할 수 있습니다. 이런 경우 SSL 연결을 다시 구성하고 수동으로 노드 동기화를 수행하여 문제를 해결해야 합니다. 모든 동적 변경은 주의해서 수행해야 합니다. 동일한 변경을 프로덕션 시스템에서 수행하기 전에 테스트 환경에서 SSL 구성 변경을 수행하도록 권장됩니다. 자세한 정보는 SSL의 동적 구성 업데이트의 내용을 참조하십시오.

기본 제공 인증서 관리

iKeyMan 기능과 호환되는 인증서 관리는 이제 관리 콘솔의 키 저장소 관리 패널에 통합되었습니다. 기본 제공 인증서 관리를 사용하여 키 저장소에 있는 개인 인증서, 인증서 요청, 서명자 인증서를 관리하십시오. 또한, 키 저장소를 원격으로 관리할 수 있습니다. 예를 들어, 배치 관리자의 임의 노드에서 구성 저장소 밖에 있는 파일 기반 키 저장소를 관리할 수 있습니다. 또한, 배치 관리자에서 원격으로 하드웨어 암호화 키 저장소를 관리할 수도 있습니다.

기본 제공 인증서 관리를 사용하여 체인된 또는 자체 서명 인증서와 같이 많은 신뢰 저장소에 흩어져 있는 서명자 인증서 전체를 대체하고 원격 SSL 호스트 및 포트에 연결하고 핸드쉐이크 중에 서명자를 인터셉트하여 서명자를 원격 포트에서 검색할 수 있습니다. 인증서는 우선 인증서 SHA 다이제스트에 따라 유효성 검증되고 관리자는 이를 신뢰 저장소에 배치하기 전에 유효성 검증된 인증서를 승인해야 합니다.

인증서 요청을 작성하는 경우, 이를 인증 기관(CA)에 전송할 수 있습니다. 인증서가 리턴되면 관리 콘솔 내에서 이를 승인할 수 있습니다. 자세한 정보는 SSL의 인증서 관리의 내용을 참조하십시오.
팁: iKeyMan이 여전히 WebSphere Application Server에서 제공되지만 기본 제공 인증서 관리 기능을 사용하여 관리 콘솔에서 키 저장소를 구성하십시오. iKeyMan은 여전히 관리 콘솔을 사용하기 불편한 경우에 사용할 수 있는 옵션입니다. 자세한 정보는 SSL 이전에 iKeyMan을 사용하여 인증서 관리를 참조하십시오.

AdminTask 구성 관리

관리 콘솔의 SSL 구성 관리 패널은 기본적으로 관리 태스크를 기반으로 하며 이는 관리 콘솔 기능을 지원하기 위해 유지보수 및 향상됩니다. Java 콘솔 프롬프트에서 wsadmin 명령을 사용하여 키 저장소, SSL 구성, 인증서 등에 대한 관리를 자동화하십시오.

주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_sslsecurecom
파일 이름:csec_sslsecurecom.html