test

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 관리 설명서

인증서 및 SSL 소개

이 절에서는 다음 항목에 대해 설명합니다.

디지털 인증서 정보

디지털 인증서(또는 인증서)는 인터넷의 사용자와 자원을 고유하게 식별하는 전자 파일입니다. 인증서는 두 엔티티 간에 안전하고 비밀을 유지하는 통신도 가능하게 해줍니다.

인증서의 종류는 여러 가지가 있는데 개인이 사용하는 개인 인증서와 SSL(Secure Sockets Layer) 기술을 통해 서버와 클라이언트 간에 안전한 세션을 설정하기 위해 사용하는 서버 인증서 등이 있습니다. SSL에 대한 자세한 내용은 SSL(Secure Sockets Layer) 정보를 참조하십시오.

인증서는 디지털 키 쌍(매우 긴 번호)을 사용하여 대상 수신자만 읽을 수 있도록 정보를 암호화 또는 인코딩하는 공개 키 암호화를 기반으로 합니다. 수신자는 정보의 비밀번호를 해독(디코드)하여 읽습니다.

키 쌍에는 공개 키와 개인 키가 포함됩니다. 소유자는 공개 키를 배포하여 모든 사용자가 사용할 수 있게 합니다. 그러나 소유자는 개인 키는 배포하지 않고 항상 비밀로 합니다. 키가 수학적으로 관련되어 있기 때문에 하나의 키로 암호화된 데이터는 키 쌍의 다른 키로만 해독할 수 있습니다.

인증서는 여권과 같습니다. 인증서는 소유자를 식별하고 기타 중요한 정보를 제공합니다. 인증 기관(CA)이라고 하는 신뢰할 수 있는 제 3자가 인증서를 발행합니다. CA는 여권 담당 부서와 유사합니다. CA는 인증서가 위조되거나 조작될 수 없도록 소유자의 아이디를 검증하고 인증서에 서명합니다. CA가 인증서에 서명하면 소유자는 신원 증명으로 인증서를 제공하고 암호화된 기밀 통신을 설정할 수 있습니다.

가장 중요한 점은 인증서가 소유자의 공개 키를 소유자의 아이디에 바인드한다는 점입니다. 여권이 소유자에 대한 개인 정보와 사진을 함께 제공하는 것과 같이 인증서는 소유자에 대한 정보에 공개 키를 바인드합니다.

공개 키 외에 인증서에는 대개 다음과 같은 정보가 포함되어 있습니다.

디지털 인증서는 X.509 형식의 기술 사양으로 관리됩니다. certificate 영역에서 사용자의 아이디를 확인하기 위해 인증 서비스는 X.509 인증서의 공통 이름 필드를 principal 이름으로 사용하여 X.509 인증서를 확인합니다.

인증서 체인 정보

웹 브라우저에는 브라우저가 자동으로 신뢰하는 루트 CA 인증서 집합이 사전 구성되어 있습니다. 모든 인증서에는 자신의 유효성을 검증하기 위한 인증서 체인이 함께 제공되어야 합니다. 인증서 체인은 최종적으로 루트 CA 인증서에서 종료되는 연속적인 CA 인증서로 발행된 일련의 인증서입니다.

처음 생성된 인증서는 자체 서명된 인증서입니다. 자체 서명된 인증서는 발급자(서명자)가 주제(공개 키를 인증서에서 인증하는 엔티티)와 동일한 인증서입니다. 소유자가 인증서 서명 요청(CSR)을 인증 기관에 전송한 다음 응답을 가져오면 자체 서명된 인증서는 인증서 체인으로 대체됩니다. 체인 맨 아래에는 주제의 공개 키를 인증하는 인증 기관에서 발행한 인증서(응답)가 있습니다. 체인의 다음 인증서는 CA의 공개 키를 인증하는 인증서입니다. 대개는 자체 서명된 인증서, 즉 해당 공개 키를 인증하는 인증 기관의 인증서이고 체인의 마지막 인증서입니다.

다른 경우는 인증서 체인을 반환할 수 있습니다. 이 경우 인증서 체인의 맨 아래 인증서는 동일하지만(키 항목의 공개 키를 인증하는 CA에서 서명한 인증서), 체인의 두 번째 인증서는 CSR을 전송한 CA의 공개 키를 인증하는 다른 CA에서 서명한 인증서입니다. 체인의 다음 인증서는 두 번째 CA의 키를 인증하는 인증서입니다. 자체 서명된 루트 인증서에 도달할 때까지 이러한 방식으로 계속됩니다. 체인의 각 인증서(첫째 인증서 제외)는 체인의 이전 인증서의 서명자 공개 키를 인증합니다.

SSL(Secure Sockets Layer) 정보

SSL(Secure Sockets Layer)은 인터넷 통신 및 트랜잭션을 보안하기 위한 가장 일반적인 표준입니다. 웹 응용 프로그램은 서버와 클라이언트간 안전한 기밀 통신을 보장하기 위해 디지털 인증서를 사용하는 HTTPS(SSL 상의 HTTP)를 사용합니다. SSL 연결에서 클라이언트와 서버는 모두 데이터를 전송하기 전에 암호화한 다음 요청 시 해독합니다.

웹 브라우저(클라이언트)에서 보안 사이트에 연결할 경우 SSL 핸드셰이크가 발생합니다.

핸드셰이크 후, 클라이언트는 웹 사이트의 아이디를 검증했고 클라이언트와 웹 서버만 세션 키의 사본을 갖고 있습니다. 이 때부터 클라이언트와 서버는 세션 키를 사용하여 서로 간의 모든 통신을 암호화합니다. 따라서 이 통신은 보안이 안전합니다.

SSL 표준의 최신 버전을 TLS(Transport Layer Security)이라고 합니다. Application Server는 SSL(Secure Sockets Layer) 3.0 및 TLS(Transport Layer Security) 1.0 암호화 프로토콜을 지원합니다.

SSL을 사용하려면 Application Server에 외부 인터페이스에 대한 인증서나 보안 연결을 승인하는 IP 주소가 있어야 합니다. 디지털 인증서가 설치되지 않으면 대부분 웹 서버의 HTTPS 서비스가 실행되지 않습니다. keytool 유틸리티를 사용하여 인증서를 생성하는 방법에 설명된 절차를 사용하여 웹 서버가 SSL에 대해 사용할 수 있는 디지털 인증서를 설정합니다.

암호화 정보

암호화는 암호화나 해독에 사용되는 암호화 알고리즘입니다. SSL 및 TLS 프로토콜은 서버와 클라이언트가 서로 간에 인증하고 인증서를 전송하며 세션 키를 설정하기 위해 사용한 다양한 암호화를 지원합니다.

일부 비밀번호는 다른 비밀번호보다 더 강력하고 더 안전합니다. 클라이언트와 서버는 서로 다른 암호화 제품군을 지원할 수 있습니다. SSL3 및 TLS 프로토콜에서 암호화를 선택합니다. 세션 연결 중에 클라이언트와 서버는 서로가 통신을 위해 설정한 더 강력한 암호화 사용을 승인하므로 대개 모든 암호화를 충분히 사용할 수 있습니다.

이름 기반의 가상 호스트 사용

보안 응용 프로그램에 대해 이름 기반의 가상 호스트를 사용하는 것은 문제가 될 수 있습니다. 이는 SSL 프로토콜 자체의 설계 한계입니다. 클라이언트 브라우저가 서버 인증서를 승인하는 SSL 핸드셰이크는 HTTP 요청에 액세스하기 전에 발생해야 합니다. 따라서 가상 호스트 이름을 포함하는 요청 정보를 인증 전에 확인할 수 없습니다. 그러므로 단일 IP 주소에 복수 인증서를 지정할 수 없습니다.

단일 IP 주소의 모든 가상 호스트를 동일한 인증서에 대해 인증해야 할 경우 복수 가상 호스트를 추가해도 서버의 정상 SSL 작업을 방해하지 않습니다. 그러나 대부분의 브라우저는 (공식적인 CA 서명된 인증서에 우선적으로 적용할 수 있는 경우) 서버의 도메인 이름을 인증서에 나열된 도메인 이름과 비교합니다. 도메인 이름이 일치하지 않을 경우 이 브라우저에서 경고를 표시합니다. 일반적으로 주소 기반 가상 호스트만 작업 환경에서 SSL과 같이 사용됩니다.