SSL Configuration HOW-TO

아래 문서에서 변수명으로 사용되는 $CATALINA_HOME는 Tomcat 4 가 설치된 디렉토리명을 가리킵니다. 그리고 이 기본 디렉토리는 대부분의 상대 경로들의 기준점이 됩니다. 그러나, Tomcat 4 설치할 때 CATALINA_BASE 디렉토리 세팅을 통해서 여러개를 설치했들 경우 이들 각각의 레퍼런스에 대해서 $CATALINA_HOME 대신에 $CATALINA_BASE를 사용해야 됩니다.

Tomcat 4 에서 지원되는 SSL 을 설치하고 환경설정하기 위해서는, 다음과 같은 간단한 단계를 밟아야 할 필요가 있습니다. 더 자세한 정보는 이 매뉴얼의 나머지 부분을 읽어보십시오.

1. JSSE 1.0.2 (또는 이후 버전)을 http://java.sun.com/products/jsse/ 에서 다운받아서 시스템에 확장설치 installed extension하거나, 또는 JSSE 를 설치한 디렉토리를 환경변수 JSSE_HOME 에 지정합니다.



2. 다음 명령을 사용해서 인증 키스토어certificate keystore 를 만듭니다:

   Windows:

   	%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA

   Unix:

   	$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA

   그리고 password 값을 "changeit" 으로 지정합니다.



3. $CATALINA_HOME/conf/server.xml 에 있는 "SSL HTTP/1.1 Connector" 항목의 주석을 없애고 필요하면 세부조정을 합니다.

SSL, 즉 보안 소켓 레이어 Secure Socket Layer, 는 웹브라우저들과 웹서버 간에 보안 연결로 통신할 수 있도록 하는 기술입니다. 이는 한쪽에서 암호화된 데이터가 전송이 되고, 다른쪽에서 처리하기 전에 암호를 해독한다는 것을 의미합니다. 이것은 양방향 처리이고, 서버와 브라우저 모두 데이터를 보내기 전에 모든 내용을 암호화 시켜야 한다는 것을 의미합니다.

SSL 프로토콜의 다른 중요한 측면은 인증입니다. 이것은 보안 연결을 통해 웹서버 와 최초 교신하려는 동안, 그 서버는 웹 브라우저에 "Certificate" 형태로 일련의 신용장을 보내고, 사이트에 누가 무엇을 요구될 것인지에 관한 증거로 삼습니다.( that server will present your web browser with a set of credentials, in the form of a "Certificate", as proof the site is who and what it claims to be.) 어떤 경우에는, 서버가 웹브라우저로부터 요구되어지는 자격을 갖춘 당신의 증거인 인증확인Certificate을 요청할 수도 있습니다. 비록 이것은 개인사용자보다는 B2B 트랜잭션에 더 많이 요구되지만 "클라이언트 인증"으로 알려져 있습니다. 대부분 SSL 가능한 웹서버들은 클라이언트 인증을 요구하지 않습니다.

중요한 것은, 보안 소켓의 장점을 이용하기 위해 Tomcat을 설정하는 것은 연동을 하지 않은 독립stand-alone 웹서버로 운영할 때에만 필요하다는 것입니다. 다른 웹서버-아파치나 마이크로소프트 IIS 같은-의 뒤에서 Servlet/JSP 컨테이너로 주로 사용할 때에는 주된 웹서버가 사용자로부터의 SSL 연결을 관리하도록 설정할 필요가 있습니다. 전형적으로, 이 서버는 모든 SSL관계된 기능을 다루게 되고, 그리고 Tomcat 컨테이너로 가는 요청들을 해독한 후에 보내줍니다. 유사하게, Tomcat은 일반 텍스트 응답을 반환하고, 사용자의 브라우저로 보내지기 전에 암호화됩니다. 이런 환경에서 Tomcat은 주된 웹서버와 클라이언트 사이의 통신이 보안 연결하에서 이루어진다는 것을 알고 있습니다(왜냐하면 애플리케이션에서 이것에 대해 물어볼 수 있을 필요가 있기 때문입니다.). 그러나 Tomcat 이 암호화와 암호해독에 직접 관여하지는 않습니다.

SSL 을 구현하려면, 웹 서버는 보안연결을 허용하는 각각의 외부 인터페이스 (IP 주소)에 대한 관련 인증서를 갖고 있어야 합니다. 이 설계의 근본 이론은 서버가 어떠한 종류이든 특히 예민한 정보를 받기 전에 접속자가 합법적인 사용자일 것이라는 합리적인 보장을 제공해야 한다는 것입니다. 인증서의 더 상세한 설명은 이문서의 범위를 벗어납니다. 인증서를 인터넷 주소의 "운전면허증"정도로 생각해보십시오. 해당 사이트가 연관된 회사가 어떤 회사인지, 사이트 주인 또는 관리자에 대한 기본적인 연락정보를 말해줍니다.(It states what company the site is associated with, along with some basic contact information about the site owner or administrator.)

이 "운전면허증"은 소유자에 의해 암호화되어 사인되어있고, 다른 사람이 위조할 수 없도록 되어있습니다. 전자상거래 사이트와 사용자의 신원확인이 필요한 비지니스 트랜잭션을 다룰 경우 중요하기 때문에 인증서는 전형적으로 VeriSign이나 Thawte 같은 유명한 인증 기관 Certificate Authority (CA) 로부터 구매합니다. 그러한 인증서는 전자적으로 검증된 것일 수 있습니다-- 실제적으로, 인증 기관이 수여한 인증서의 진위를 보증하기 때문에, 그것을 제공한 인증 기관을 신뢰한다면 인증서를 믿을 수 있게됩니다.

그러나 많은 경우에 인증은 실제로 문제가 되지 않습니다. 관리자가 서버에서 송수신한 데이터가 개인적이고 연결을 엿보고있는 누군가에 의해서 스누핑당할 수 없는 것을 단지 확인하기만 하고 싶어할 것입니다. 다행히도 자바는 상대적으로 간단한 keytool 이라 불리는 커맨드라인 도구를 제공합니다. 이것은 쉽게 "자체서명된" 인증서를 만들어냅니다. 자체서명된 인증서는 단순한 사용자가 만든 어떤 유명한 CA 에도 공식적으로 등록된 적이 없는 인증서이다보니 진위를 절대적으로 보장하지는 못합니다. 다시말해서, 이것이 중요한 것인지 아닌지는 요구가 어떤 것이냐에 달려있습니다.

사이트의 보안영역 페이지에 처음으로 접근을 시도하려할 때, 사용자는 인증서의 상세정보(예를 들면 회사나 연락처)가 있는 대화상자를 보게 되고, 사용자에게 유효한 인증서로 받아들이길 원하는지 트랜잭션을 계속 진행할 지 묻게 됩니다. 어떤 브라우저는 주어진 인증서를 영구적으로 인정할지 묻는 옵션을 제공합니다. 그런 경우에 사용자는 사이트에 방문할 때마다 답을 해야하는 번거로움을 피할 수 있게됩니다. 다른 브라우저는 이 옵션을 지원하지 않습니다. 일단 사용자가 승인하면 인증서는 적어도 브라우저 세션 동안은 유효한 것으로 여겨집니다.

또한, SSL 프로토콜이 가능한한 보안면에서 효율적이게 설계된 것에 반해, 암호화/복호화 는 성능의 측변에서 보면 과도한 계산 프로세스를 요구합니다. 웹 애플리케이션 전반에 걸쳐서 SSL 를 적용해서 운영하는 것이 엄격하게 필요한 것은 아닙니다. 실은 개발자가 어떤 페이지가 보안 연결을 해야하는지 그럴 필요가 없는 페이지들은 어느 것인지 취사선택할 수 있습니다. 상당히 바쁘게 돌아가는 사이트에서 SSL 하에 돌아가는 페이지들을 직접 선택할 수 있습니다. 즉, 그러한 페이지들은 민감한 정보가 송수신 되는 페이지들입니다. 이에 해당하는 페이지들은 로그인 페이지, 개인정보페이지, 그리고 신용카드 정보가 전송되는 장바구니 결제 페이지 등 입니다. 애플리케이션 내의 어느 페이지든 간에 단순히 주소를 http: 대신에 https: 로 호출함으로써 보안 소켓을 통한 요청으로 바꿀수 있습니다. 절대적으로 보안연결을 요구하는 페이지는 요청과 관계된 프로토콜 타입을 검사해야 하고, https을 통하지 않았을 경우 적절한 행동을 취해야 합니다.

마지막으로, 도메인 이름 기반의 가상 호스트에서 보안 연결을 사용하려할 경우 문제가 많아집니다. SSL 프로토콜 자체의 설계적 한계입니다. 클라이언트 브라우저가 서버 인증서를 받아들이는 SSL 연결은 HTTP 요청이 도달하기 전에 이루어져야 합니다. 결과적으로, 가상 호스트 이름을 포함하는 요청 정보는 인증에 앞서 해석되지 못하고, 하나의 IP 주소에 대해 다중 인승서를 할당할 수 없게 됩니다. 만일 하나의 IP 주소를 사용하는 모든 가상호스트들이 같은 인증서에 대해 인증할 필요가 있다면, 다중 가상호스트의 추가가 서버에 대한 정상적인 SSL 동작에 간섭해서는 안됩니다. 그러나 알아둘 것은 대부분의 클라이언트 브라우저는 인증서에 있는 도메인명에 대해서 서버의 도메인 이름으로 비교합니다, (만일 주로 공식적인 CA-사인된 인증서들에 적용되는 경우라면) if any (applicable primarily to official, CA-signed certificates). 만일 도메인 이름이 맞지 않는다면, 이들 브라우저는 클라이언트 사용자에게 경고를 나타냅니다. 일반적으로, 실무에서는 오직 주소 기반 가상호스트들이 SSL을 다루는데 보통 사용됩니다.

다운로드 와 JSSE 설치 Download and Install JSSE

Java Secure Socket Extensions (JSSE) 패키지 1.0.2 또는 이후 버전을 다운받습니다. http://java.sun.com/products/jsse/. 소스로부터 Tomcat 을 만든 경우 아마도 이미 이 패키지를 다운받았을 겁니다. JDK 1.4 를 사용한다면, 이 클래스들은 JDK에 직접 통합되어있고, 이 전과정을 넘어가면 됩니다. 패키지 압축을 풀고, Tomcat 에서 사용하는 법이 두 가지 있습니다(둘 중에 하나를 선택하세요): JSSE 확장 설치 installed extension는 세 개의 JAR 파일들( jcert.jar, jnet.jar, and jsse.jar)을 모두 $JAVA_HOME/jre/lib/ext 에 복사하면 됩니다. 풀어놓은 JSSE 바이너리 파일들이 있는 디렉토리의 절대 경로를 표시하는 JSSE_HOME 라는 새로운 환경변수를 만듭니다.

인증서 키스토어 준비 Prepare the Certificate Keystore

현재 Tomcat은 오직 JKS 형식의 키스토어에서만 동작합니다. 이것은 Java 표준 "Java KeyStore" 형식이고, keytool 커맨드라인 도구 에 의해서 만들어진 형식입니다. 이 도구는 JDK 에 포함되어 있습니다. 기존 인증서를 JKS 키스토어에 가져오려면 JDK 문서 패키지에 있는 keytool 에 관한 문서를 읽어보십시오. 단순 자기서명한 인증서를 포함하는 스크래치로부터 새로운 키스토어를 만들기 위해서는 다음 커맨드 라인 명령을 실행하십시오: Windows: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA Unix: $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (RSA 알고리즘은 보안 알고리즘 중에 선호되는 것이고, 다른 서버나 컴포넌트들과 보편적인 호호나성을 보장합니다.) 이 명령은 사용자가 돌리고 있는 디렉토리에 ".keystore" 라는 새로운 파일을 만듭니다. 다른 위치나 파일명을 지정하려면 -keystore 파라미터를 위에 보이는 keytool 커맨드에서 키스토어 파일의 완전한 경로명 앞에 붙여주십시오. 한가지 더 필요한 게 있는데, 다음과 같이 새로운 위치를 server.xml 환경설정 파일에 반영해줘야 합니다. 예를 들면: Windows: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA \ -keystore \path\to\my\keystore Unix: $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA \ -keystore /path/to/my/keystore 이 명령을 실행한 후에, 처음으로 키스토어 비밀번호를 입력하게 됩니다. Tomcat 에서 사용되는 초기 비밀번호는 "changeit"(모두 소문자) 이고, 원한다면 다른 비밀번호를 지정할 수도 있습니다. 아래 설명한 대로 server.xml 환경설정 파일에 사용자 비밀번호를 지정할 필요도 있습니다. 다음으로, 인증서에 대한 일반적인 정보를 입력해야 됩니다. 회사명, 연락담당자 등등 입니다. 이 정보는 애플리케이션에서 보안 페이지에 접근하는 사용자들에게 보여지게 됩니다. 때문에 여기에 적는 정보가 제대로 된 것인지 확실히 해야 됩니다. 끝으로, 특별히 이 인증서를 위한 (같은 키스토어 파일에 저장된 다른 인증서들에 반하는) key password를 입력해야 됩니다. 여기에서는 키스토어 비밀번호 자체에 사용된 것과 반드시 같은 비밀번호를 사용해야 됩니다. (현재, keytool 프롬프트에는 엔터키를 치면 자동적으로 된다는 것을 알려줄 것입니다.) 모두 잘되었다면, 서버에서 사용할 수 있는 인증서와함께 키스토어 파일을 갖게 된 것입니다.

Tomcat 환경설정 파일 편집 Edit the Tomcat Configuration File

마지막 단계는 $CATALINA_HOME/conf/server.xml 파일에 있는 보안 소켓 설정을 하는 것입니다. $CATALINA_HOME 은 Tomcat 4 가 설치 된 디렉토리를 나타냅니다. 설치된 Tomcat의 기본 server.xml 파일에 SSL 커넥터에 대해 예제 <Connector> 요소가 포함되어 있습니다. 이런 식으로 되어있습니다: <-- Define an SSL HTTP/1.1 Connector on port 8443 --> <!-- <Connector className="org.apache.catalina.connector.http.HttpConnector" port="8443" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="10" debug="0" scheme="https" secure="true"> <Factory className="org.apache.catalina.net.SSLServerSocketFactory" clientAuth="false" protocol="TLS"/> </Connector> --> 보는 바와 같이 커넥터 요소 자체는 기본적으로 주석처리 되어있습니다. 따라서 사용하기 위해서는 주석태그를 제거해야됩니다. 그리고, 필요한대로 속성값을 바꾸면 됩니다. 여러 옵션에 대한 자세한 정보는 Server Configuration Reference 파일을 참조하십시오. 아래의 내용은 SSL 통신을 설정할 때 가장 많이 사용되는 속성들에 대해서 다룹니다. port 속성 (기본값 8443)은 Tomcat 이 보안연결에 사용하는 TCP/IP 포트번호입니다. 원하는 번호로 바꿀 수 있습니다. (https 의 기본 포트번호는 443 입니다.) 그러나, 많은 운영체제의 1024 이하의 포트에서 Tomcat을 돌리려면 특별한 셋업(이문서의 범위를 벗어나는) 이 필요합니다. 여기의 포트번호를 바꾸면 비SSL 커넥터에 있는 redirectPort 속성값도 바꿔야 됩니다. 이렇게 되면 서블릿 2.3 명세에 의해 요구된 것처럼 Tomcat은 자동적으로 SSL이 필요한 제한구역에 있는 페이지에 접근하는 사용자들을 재지정redirect 해줍니다. Connector 요소 내에 중첩된 Factory 요소가 있습니다. 해당 포트번호에서 소켓이 필요할 때마다 Tomcat 이 "소켓 팩토리"를 사용하는 곳이고, 여기에서 설정됩니다. 전에 키스토어를 어떻게 설정했느냐에 따라서 다음 속성값을 변경 또는 추가할 필요가 있을지도 모릅니다: 속성 설명 className 이 소켓 팩토리를 구현하는 Java 클래스의 전체경로명. 기본 값을 바꾸지 마십시오. clientAuth true 값일 경우 이 소켓을 사용하려면 모든 클라이언트가 클라이언트 인증서를 제시하도록 Tomcat으로부터 요청받게 됩니다. keystoreFile 생성된 키스토어파일이 Tomcat이 예상한(Tomcat 이 운영중인 사용자 홈 디렉토리에 있는 .keystore 라고 명명된 파일) 기본 위치에 있지 않을 경우 이 속성을 덧붙입니다. 절대 경로를 써도 되고, $CATALINA_BASE 환경변수에 대해서 상대경로를 사용해도 됩니다. keystorePass Tomcat에서 예상한 것(changeit) 말고, 다른 키스토어 (그리고 인증서) 암호를 사용하려면 이 요소를 덧붙입니다. protocol 이 소켓에 사용되는 암호/복호 프로토콜. 기본값을 바꾸지 마십시오. 이 환경설정이 끝나면, 여느때처럼 정상적으로 Tomcat 을 재시작해야됩니다, 그후엔 아직 끝난게 아닙니다. (and you should be in business). SSL을 통해 Tomcat 의 웹애플리케이션에 접근할 수 있어야 됩니다. 예를 들어 다음 주소를 쳐보면: https://localhost:8443 보통 Tomcat 첫페이지가 보여야 됩니다(ROOT 웹애플리케이션을 변경하지 않았다면). 만일 동작하지 않는다면, 아래의 문제해결 팁 몇 개를 참고해보십시오.

인증 기관(verisign.com, thawte.com, trustcenter.de 같은)의 인증서를 취득하고 설치하려면, 위에 있는 섹션을 읽고 다음 지시를 따라야 됩니다:

로컬 인증서 사인 요청 생성하기 Create a local Certificate Signing Request (CSR)

선택한 인증 기관의 인증서를 취득하기 위해서는 이른바 인증서 사인 요청 (CSR)을 만들어야 됩니다. 이 CSR은 웹사이트가 "보안"을 사용한다고 증명하는 인증서를 생성하기 위해 인증기관에서 사용하게 됩니다. CSR 생성은 다음과 같습니다: 로컬 인증서를 생성합니다 (이전 섹션에서 설명한대로): keytool -genkey -alias tomcat -keyalg RSA \ -keystore <your_keystore_filename> Note: 어떤 경우에 동작하는 인증서를 만들기 위해 "first- and lastname" 필드에 웹사이트의 도메인을 입력해야됩니다.(예 www.myside.org) 그 후에, CSR 을 다음과 같이 생성합니다: keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr \ -keystore <your_keystore_filename> 이제 인증기관에 보낼 certreq.csr 파일이 생기게 됩니다. (이 파일을 어떻게 사용하는지에 관해서는 인증 기관의 웹사이트에 있는 문서를 보십시오.) 그 후에 응답으로 인증서를 갖게 됩니다.

인증서 가져오기 Importing the Certificate

인증서를 갖고 있다면 로컬 키스토어에서 그것을 가져올 수 있습니다. 우선 이른바 체인 인증서 또는 루트 인증서를 키스토어에 가져와야 됩니다. 그 후에 인증서 가져오기를 진행할 수 있게 됩니다. 인증서를 취득한 인증 기관에서 체인 인증서를 다운받습니다. Verisign.com 위치: http://www.verisign.com/support/install/intermediate.html Trustcenter.de 위치: http://www.trustcenter.de/certservices/cacerts/en/en.htm#server Thawte.com 위치: http://www.thawte.com/certs/trustmap.html 키스토어에 체인 인증서를 가져오기 keytool -import -alias root -keystore <your_keystore_filename> \ -trustcacerts -file <filename_of_the_chain_certificate> 마지막으로 새로운 인증서 가져오기 keytool -import -alias tomcat -keystore <your_keystore_filename> \ -trustcacerts -file <your_certificate_filename>

SSL 통신을 세팅하면서 만나게 될 수 있는 공통적인 문제들을 어떻게 대처할 지에 대해 나열해 보았습니다.

• 로그 파일에 "java.security.NoSuchAlgorithmException" 에러가 납니다.

  JVM이 JSSE JAR 파일을 찾지 못했습니다. JSSE 다운받고 설치하기 의 지시대로 따라하십시오.

• Tomcat 시작시에, 다음과 같은 예외가 발생합니다. "java.io.FileNotFoundException: {some-directory}/{some-file} not found".

  쉽게 설명하자면, Tomcat 이 찾으려는 keystore 파일을 발견하지 못했습니다. 기본값으로, Tomcat은 운영되는 곳 아래의 사용자 홈 디렉토리(사용자의 설정에 따라 달라질 수 있습니다.)에서 .keystore 라고 명명된 키스토어 파일을 찾습니다. 만일 다른 곳에 키스토어 파일이 있다면, Tomcat 환경 설정 파일에 있는 <Factory> 요소에 keystoreFile 속성을 추가해줘야 됩니다.

• Tomcat 시작시에, 다음과 같은 예외가 발생합니다. "java.io.FileNotFoundException: Keystore was tampered with, or password was incorrect".

  누군가 키스토어 파일을 실제로 건드리지 않았다고 가정하면, 가장 빈번한 원인은 Tomcat 이 사용하는 암호가 키스토어 파일을 생성할 때 썼던 암호와 다를 경우입니다. 이를 수정하려면, 돌아가서 다시 키스토어 파일 재생성하거나, Tomcat 환경 설정 파일에 있는 <Factory> 요소에 keystorePass 속성을 추가 또는 갱신해야 됩니다. 주의 - 암호는 대소문자 구분합니다!

여전히 문제가 발생한다면, 좋은 정보가 TOMCAT-USER 메일링 리스트에 있습니다. 이 리스트에서 이전의 메시지들의 저장고를 검색할 수 있고, 정보 가입신청과 해지도 가능합니다. 주소는 http://jakarta.apache.org/site/mail.html" 입니다.

원본:http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html