서버, 클라이언트, 사용자와 같은 네트워크 상의 개체들에 대한 확인하는 일. SSL의 경우 서버와 클라이언트의 증명서를 확인(verification)하는 과정을 의미한다.

네트워크 상의 접근(access)에 대한 제한(restriction). Apache에서는 보통 어떤 URL에 대한 접근 제한을 의미한다.

어떠한 문제를 해결하기 위해 사용하는 방법으로서, 유한개의 단계(step)로 이루어진 모호하지 않는 식(formula) 혹은 규칙의 집합. 암호화를 위해 사용되는 알고리즘은 보통 Cipher라고 불린다.

서버나 클라이언트와 같은 네트워크 상의 개체(entity)들을 인증(authentication)하기 위해 사용되는 특정한 데이터 레코드로서, 증명서에는 그 증명서의 소유자에 대한 X.509 information (subject)과 그 증명서에 서명한 Certificate Authority (issuer)에 대한 X.509 information 이 포함되어 있으며, 또한 소유자의 공개키, CA에 의해 만들어진 서명이 포함되어 있다. 네트워크 상의 개체들은 CA의 증명서를 이용하여 이 서명들을 확인하게(verify) 된다.

네트워크 상의 개체들에 대한 증명서에 서명하는 것을 목적으로 하는 믿을 수 있는 제 3자(trusted third party)로서 증명서를 인증하는 역할을 한다. 다른 네트워크 개체들은 서명을 체크함으로써 자신에게 온 증명서가 어떤 CA에 의해 인증되었음을 확인할 수 있다.

서명을 받기 위해 CA에게 제출되어질 아직 서명되지 않은 증명서로서 CA는 자신의 CA 증명서의 개인키로 CSR에 서명하게 된다. CSR이 서명되어지면 실제로 사용할 수 있는 증명서(real certificate)가 된다.

데이터 암호화를 위한 알고리즘이나 시스템으로서, DES, IDEA, RC4 등이 있다.

Plaintext가 cipher를 통하여 나온 암호화된 결과.

어떤 프로그램의 행동을 제어하는 설정 명령(configuration command ). Apache의 경우 설정 파일의 첫번째 열에 모든 명령어의 이름이 있다.

HTTP 상에서 raw data channel을 proxying하기 위한 HTTP 명령으로서 SSL 프로토콜과 같은 다른 프로토콜들을 포함하는데(encapsulate) 사용되어질 수 있다.

증명서나 어떤 파일에 대한 유효성(validity)을 검사하기 위한 암호화된 텍스트 블록. CA는 증명서에 들어있는 공개키의 hash를 생성하고, 생성된 hash를 CA 자신의 개인키로 암호화함으로써 서명을 생성하게 된다. 단지 서명을 생성한 CA의 공개키만이 서명을 복호화할 수 있으며, 서명을 복호화함으로써 그 CA가 그 증명서의 소유자를 인증하였음을 확인하게 된다.

미국의 수출관리규정(Export Administration Regulation ? EAR)에 따르기 위한 목적으로 암호화의 강도(cryptographic strength)를 낮추는 것으로서, 이 규정이 적용되는 암호화 소프트웨어는 작은 크기의 키만을 사용하도록 제한되어져 있으며, 이로 인하여 Brute Force 공격에 쉽게 깨어질 수 있는 암호문만을 생성할 수 있다.

네트워크 상의 개체에 대한 유일한 이름으로서, IP 주소로 변환(resolve)될 수 있는 호스트 명과 도메인 명으로 이루어진다. 예를 들어, www는 호스트 명이고, whatever.com은 도메인 명이며, www.whatever.com은 FQDN이 된다.

World Wide Web에서 사용되는 표준 전송 프로토콜.

안전한(secure) HTTP 프로토콜로서 World Wide Web에서 사용되는 표준 암호화 통신 프로토콜. 실제로 HTTPS는 SSL 상에서 HTTP를 구현한 것이다.

메시지로부터 얻어낸 hash로서 전송 중에 메시지의 내용이 변경되지 않았음을 확인하는데 사용된다.

개인키 파일을 보호하기 위한 단어(word)나 구문(phrase)으로서 허용되지 않은 사용자가 개인키 파일을 암호화하는 것을 막기 위해 사용된다. 이 때 보통 암호화를 위해서 비밀키 암호화/복호화를 사용한다.

암호화되지 않은 텍스트.

공개키 암호화 시스템에서 자신만이 알고 있는 비밀키로서 자신에게 온 메시지를 암호화하거나, 자신이 보내는 메시지에 서명하는데 사용된다.

공개키 암호화 시스템에서 공개하게 되는 공개키로서, 그 공개키의 소유자에게 보낼 메시지를 암호화하거나 그 공개키의 소유자가 생성한 서명을 복호화하는데 사용된다.

비대칭형 암호화 시스템을 구현한 암호화 방법으로서 하나의 키를 암호화에 사용하고 다른 하나의 키를 복호화에 사용하게 되며, 이 키들의 쌍을 key pair라고 부른다. 공개키 암호화는 비대칭형 암호화(Asymmetric Cryptography)라고도 불려진다.

TCP/IP 네트워크 상에서 일반적인 통신 인증과 암호화를 목적으로 Netscape사에 의해 만들어진 프로토콜. SSL을 사용하는 가장 일반적인 방법은 SSL 상에서 HTTP를 구현하는 HTTPS를 사용하는 것이다.

SSL 통신의 context information.

Eric A. Young eay@cryptsoft.com이 개발한 SSL/TLS 구현 라이브러리.

암호화와 복호화에 동일한 키를 사용하는 암호화.

TCP/IP 네트워크 상에서 일반적인 통신 인증과 암호화를 위해 IETF(Internet Engineering Task Force)에서 SSL의 후속으로 개발한 프로토콜. TLSv1은 SSLv3와 거의 동일하다.

World Wide Web 상에서 다양한 자원(resource)들의 위치를 표시하기 위한 방법. 가장 잘 알려진 URL scheme은 http이며, SSL은 https를 사용한다.

ITU(International Telecommunication Union)에 의해 권장되어진 authentication certificate scheme이며, SSL/TLS 인증에 사용된다.

이 FAQ는 뉴스그룹 comp.infosystems.www.servers.unix와 mod_ssl 지원을 위한 메일링 리스트인 sw-mod-ssl@engelschall.com에 올라왔던 질문들을 모은 것이다.

mod_ssl은 Apache-SSL에 비해 많은 변화가 있었으며, 자세한 내용은 mod_ssl 배포판의 CHANGES와 CHANGES.20 파일을 참조한다. 그 대부분은 내부적인 변경이나 소스 코드의 변경이며, 밖으로 보여지는 주요한 변화는 다음과 같다 :

mod_ssl은 Apache-SSL에서는 제공하지 않는 완전한 사용자 매뉴얼을 제공하며, 여기에는 모든 Configuration directives, 환경변수(environment variable) 그리고 그 외의 많은 것들에 대하여 기술하고 있다. 또한 mod_ssl은 Apache/SSL/SSLeay 에 대한 FAQ를 제공하며, FAQ에서는 CA를 설정하는 법, 서버 증명서(Server Certificate)를 생성하는 법 등등에 대한 자세한 설명을 제공한다.

Mod_ssl은 사용자들이 backdoore나 security hole 등을 찾아보는데 도움이 될 수 있도록 소스 코드에 자세한 설명을 덧붙이고 있으며, 이것은 보안에 관련된 소프트웨어에 있어서 매우 중요하게 고려되어야 할 사항이다. Mod_ssl 패키지의 소스 코드는 Apache의 코딩 스타일을 따르고 있으며, API의 단계를 논리적으로 따른다.

Mod_ssl은 SSL을 구현하기 위하여 Extended API를 사용하며, Apache kernel에 SSL 암호화에 관련된 코드를 직접 패치하는 것이 아니라 EAPI를 패치함으로써 커널과 mod_ssl이 서로 독립적이 될 수 있도록 하였다. 이로 인하여 SSL과 암호화에 관련된 코드는 단지 SSL 모듈 자체(src/modules/ssl/ 디렉토리)에만 존재하게 되며, Apache 커널에서 직접적으로 SSL을 참조하지 않는다.

Mod_ssl은 Dynamic Shared Object(DSO) 기능을 지원하며, DSO의 지원으로 run-time 시의 유연성(flexibility)을 최대한 높일 수 있게 된다. 즉, Apache를 컴파일할 때 SSL을 Apache 실행파일(httpd)에 넣을 것인가 넣지 않을 것인가를 결정할 필요가 없으며, 단지 필요하면 mod_so가 제공하는 LoadModule directive를 이용하여 mod_ssl을 로딩하면 된다. 이 기능은 두가지 면에서 매우 유용하다: Vendor package maintainer에게 유연성 있는 패키지를 만들 수 있는 방법을 제공하며, Apache 사용자에게 있어서는 하나의 Apache만을 설치하고서 하나 이상의 Apache(SSL을 사용하는 Apache와 SSL을 사용하지 않는 Apache)를 실행할 수 있게 해준다.

Mod_ssl은 Win32 플랫폼에서 동작하며, 이는 Apache와 SSLeay이 Wind32 플랫폼에서 동작함에 의해서 가능하다. mod_ssl은 이 패키지들의 발전을 따르고 있으며, 이 귀찮은 플랫폼에서도 항상 요구되는 지원 사항들을 제공한다. Unix/DSO의 경우와 같이 Win32에서도 mod_ssl은 mod_so의 LoadModule directive에 의해 로딩될 수 있는 표준 DLL을 통해 Apache에 적용되어진다.

Apache-SSL이 사용자로 하여금 직접 patch나 cp와 같은 명령어를 사용하게 만들었던 것에 비하여 mod_ssl은 자동화된 설정 환경을 제공함으로써 매우 쉽게 Apache 소스 트리에 적용되어진다. 이를 위하여 mod_ssl은 Apache 1.3이 제공하는 Autoconf-style Interface(APACI)를 지원한다. 또한 mod_ssl은 RSAref를 사용할 수 있으며, SSLeay가 어느 위치에 설치되었는가를 상관하지 않는다.

Apache-SSL은 mod_ssl과 같은 Apache 소스 트리에 적용하기 위한 손쉬운 방법을 제공하지 않으며 어느정도의 수작업 편집과 patch 작업이 필요하다. Configuration을 할 때와 Install을 할 때 Apache-SSL은 Apache 1.3의 Autoconf-style Interface(APACI)에 쉽게 통합되어질 수 없으며, 이미 설치되어 있는 SSLeay와 out-of-the-source-only SSLeay와의 차이점을 자동으로 인식하지 않는다. 또한 SSLVerifyClient의 인수로 이름 대신에 0에서 2까지의 숫자를 사용하는데, 그 이유는 내부적으로 enum이 사용되었고 또한 CustomLog의 %{version}c construct에 대한 결과값으로 SSLeay 0.9에서는 “SSL2”, “SSL3” 등을 사용하는 것에 비하여 SSLeay 0.8에서는 “2”, “3”을 사용되었기 때문이다.

Mod_ssl은 Apache-SSL에서 제공하지 않았던 몇가지 기능을 덧붙였다:

Mod_ssl은 log level에 따른 SSL 전용 로그 파일을 제공하며, ‘error’ level의 메시지는 자동으로 Apache 에러 로그 파일에 중복해서 기록한다. 또한 occuring system과 SSLeay 에러 메시지는 자동으로 mod_ssl 메시지에 덧붙여지며, 부가적으로 mod_ssl은 매우 자세한 힌트와 함께 SSLeay 메시지를 기록한다. Mod_ssl은 암호화된 개인키 파일들의 handling에 있어서 매우 새로운 기능을 제공한다. 먼저, 개인키를 permanent memory pool에 저장함으로써 Apache를 완전히 죽이지 않고서도 서버를 재시동할 수 있게 되었다. 두번째는 pass-phrase dialog가 훨씬 사용하기 편리하고 기능이 향상되었다: pass-phrase를 입력받는 횟수를 줄이기 위해 pass-phrase reuse algorithm을 사용하며, 틀린 pass-phrase를 인식하여 재시도할 수 있게 하며, pass-phrase를 일괄 입력하기 위하여 pass-phrase를 제공하는 외부 프로그램을 사용할 수 있는 interface를 제공한다. Mod_ssl이 제공하는 SSLCACertificateReqFile directive는 클라이언트가 서버 인증의 속도를 높이기 위해 서버로부터 CA Certificate를 로딩하는데 사용되는 SSLv3 feature를 위한 differect set of CA Certificates를 설정하는데 사용된다. Apache 내에서 외부 프로그램을 제어하는 것이 그다지 믿을 만하게 동작하지 않기 때문에, Mod_ssl은 Apache-SSL에서 SSL 세션을 저장하기 위해 사용하는 “gcache” 기능을 더욱 강력한 DBM 기반의 솔류션으로 대체하였다. 부가적으로 이 cache에 대한 inter-process access를 동기화하기 위하여 “mutex”를 사용한다. Mod_ssl은 SSLeay와 RSAref를 함께 조합하여 사용할 수 있는 기능, 즉 RSAref 패키지를 이용하여 Apache에서의 SSL Extension을 구현할 수 있는 기능을 제공한다. SSLRequire directive는 임의의 boolean expression의 조합을 접근 제어의 조건으로 사용할 수 있게 해준다. Apache Proxy Module(mod_proxy)에 대한 HTTPS 기능을 지원한다. Mod_ssl은 Win32 Apache에 대한 SSL Extension으로서는 처음으로 소스를 공개한 패키지이다.

mod_ssl에 대한 더 자세한 내용은 mod_ssl 배포판에 포함되어 있는 CHANGES 파일과 CHANGES.20 파일을 참조하기 바란다.

그렇지 않다. 단지 mod_ssl을 사용할 수 있음을 의미할 뿐이다. 잘 알려져 있는 SSL 솔류션인 Apache-SSL은 여전히 필요한 기능을 훌륭히 수행하며, Ben Laurie는 아직도 이 패키지의 관리를 위해 많은 일들을 하고 있다. 단지 중요한 차이점은 Ben Laurie의 목적과 Ralf S. Engelschall의 목적이 다르다는 것이다. 만약 두 패키지의 차이점에 대하여 별로 필요성을 느끼지 않는다면 굳이 mod_ssl로 업그레이드할 이유는 없다. 단지 Apache-SSL을 사용하는 것이 편하게 느껴진다면 Apache-SSL을 사용하는 것이고 그렇지 않다면 mod_ssl이나 더 나은 기능을 제공하는 다른 상용 SSL 솔류션을 사용하라는 것이다. 다시 말해서 어떤 솔류션이 다른 것들보다 낫다고 말할 수는 없으며, 어느 것을 사용하는가는 개인적인 요구사항에 달려있는 것이다.

Mod_ssl은 본래 1998년 4월 Apache-SSL 1.17 버전을 Apache 1.2.6에서 Apache 1.3b6로 포팅하는 작업에서 만들어졌다. Ben Laurie의 개발 사이클과 맞지 않음으로 인하여 mod_ssl은 기존의 mod_ssl과 새로운 Apache-SSL 1.18을 조합하여 Apache 1.3.0을 위한 버전으로 태어나게 되었다. 이 시점부터 mod_ssl은 독자적인 개발을 하게 되었으며, Apache-SSL에서 개선되는 부분들은 이후 mod_ssl이 받아들이는 방식으로 진행되어져 왔다. 다시 말하면, mod_ssl은 가장 최신의 Apache-SSL에 기반을 두고 있으며, Apache-SSL에서 개선되는 부분들을 항상 받아들이게 될 것이다.

Mod_ssl 프로젝트가 Apache-SSL 프로젝트의 일환으로 계획되어진 것이었으며, 원래는 mod_ssl을 Apache-SSL 2.0.0에 넣고자 하는 의도였으나, Ralf S. Engelschall과 Ben Laurie가 mod_ssl과 Apache-SSL을 합치지 않겠다고 결정함으로써 mod_ssl 프로젝트는 “mod_ssl”이란 이름으로 새로운 패키지로서 발표되었다. 그러나 mod_ssl이 “second generation” 이란 의미를 표시하기 위해 첫번째 mod_ssl의 버전은 2.0.0으로 결정되게 되었다.

그것은 간단하다. Mod_ssl은 <mod_ssl-version>-<apache-version>으로 구성된 버전 표기를 하며, 예를 들면 2.2.0-1.3.4는 mod_ssl 버전이 2.2.0이며 Apache 버전 1.3.4를 위한 것임을 의미한다. 또한 이는 이 mod_ssl 버전을 정확히 이 Apache 버전에만 적용할 수 있음을 의미한다.

Mod_ssl은 Y2K 문제를 해결하였다.

Mod_ssl은 내부적으로 년도를 2자리로 표시하지 않으며, 시간의 표시를 현대의 대부분의 유닉스 시스템들이 사용하고 있는 시간 표시 방식인 ANSI C & POSIX numeric data type인 time_t 형식을 사용한다. 이 형식은 1970년 1월 1일 00:00 UTC로부터 지금까지의 초(second) 단위 시간을 가지고 있는 signed long 정수(보통 32bit)로 시간을 표시한다. 이 수는 2000년이 아니라 2038년1월초에 overflow가 발생한다. 또한 날짜와 시간의 표기(예를 들어 “%{TIME_YEAR}” )는 2자리 숫자로 표기하지 않고 4개의 숫자로 표기한다.

부가적으로, Apache 그룹의 2000년 문제에 대한 발표에 따르면 Apache 웹 서버는 2000년 문제의 영향을 받지 않는다. 그러나 SSLeay나 OS ( Unix 혹은 Win32 platform)이 2000년 문제의 영향을 받지 않는가의 문제는 여기서 답변될 내용이 아니다.

“Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies”는 재래식 무기, dual-use good과 technology에 대한 무역을 통제하기 위해 1995년에 설립된 국제기구(international regime)로서 기존에 있던 기구인 “CoCom”을 대체한 기구이다. 다음의 33개 가맹국이 있다: Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom and United States. 자세한 내용은 “http://www.wassenaar.org” 사이트를 참조한다.

간단히 말해서 “Wassenaar Arrangement”의 목적은 국제적 혹은 지역적인 안보와 평안을 위협하는 군사적 능력(military capability)을 제어하는데 있다. “Wassenaar Arrangement”는 암호학 (Cryptography)을 하나의 dual-use good으로서 제한하고 있으나 mass-market software와 free software에 대해서는 수출 제한에서 면제하고 있다.

현재 Wassenaar의 “GENERAL SOFTWARE NOTE(GSN)”에 대한 “List of Dual Use Goods and Technologies And Munitions”에 따르면, public domain에 속하는 소프트웨어는 제한하지 않는다고 되어 있다. 또한 “DEFINITIONS OF TERMS USED IN THESE LISTS”에는 다음과 같은 정의가 있다. “in the public domain : This means "technology" or "software" which has been made available without restrictions upon its further dissemination. N.B. Copyright restrictions do not remove "technology" or "software" from being "in the public domain".”

“Wassenaar Agreement”에 따르면 mod_ssl과 SSLeay는 public domain에 속하게 되며, 따라서, mod_ssl과 SSLeay는 Wassenaar Agreement에 영향을 받지 않는다..

두가지 방법이 있다: 두개의 서버를 따로 실행하거나 하나의 서버에 두개의 서비스를 실행한다. 두개의 서버를 실행해야 할 특별한 이유가 없는 한, 하나의 instance에서 SSL을 필요로 하는 virtual host에 대해서만 SSL을 적용하는 방법을 사용하는 것이 간단하다. 만약 두개의 서버를 따로 실행하는 경우에는 그 두개의 서버가 각각 허용된 포트(보통 HTTP는 80, HTTPS는 443)에만 bind를 시도하도록 되어 있는가를 확인해야 한다.

어느 포트에서든지 HTTPS를 실행할 수는 있지만 표준 HTTPS 포트는 443번이며, 브라우져는 기본적으로 이 포트를 찾도록 되어 있다. 브라우져가 443번이 아닌 다른 포트를 찾도록 하기 위해서는 다음과 같은 URL을 사용한다(포트가 666인 경우):

보통 Apache의 HTTP 프로토콜을 간단하게 테스트할 때 다음을 이용한다.

그러나 HTTPS의 경우에는 SSL 프로토콜이 TCP와 HTTP 사이에 위치하기 때문에 HTTP와 같이 쉽지 않다. 하지만 SSLeay가 제공하는 s_client 프로그램을 이용하여 HTTPS에 대해서도 HTTP와 비슷한 테스트를 할 수 있다:

실질적인 HTTP 응답(response) 이전에 SSL handshake에 대한 자세한 정보가 보여지게 된다. Apache가 80번과 443번 포트에서 제대로 동작하고 있는가를 체크하기 위해서는 다음과 같은 cURL tool을 사용할 수 있다.

$ curl http://localhost/ (80번 포트)

$ curl https://localhost/ (443번 포트)

“https://” 형태의 URL이 아닌 “http://” 형태의 URL을 사용하였을 수 있다. 이 경우 Apache 에러 로그파일에 “SSL_Accept failed error: 140760EB: SSL routines: SSL23_GET_CLIENT_HELLO: unknown protocol” 이라는 메시지가 나타나게 된다. 또한 이러한 현상은 SSL을 지원하지 않는 서버에 “https://” 접속을 시도하는 경우에도 나타난다. 이러한 경우에는 해당 가상 서버(virtual server)가 SSL을 지원하고 있나를 확인해 본다.

URL을 변경하기 위해선 보통 Fully-qualified 하이퍼링크를 사용해야 하지만 mod_rewrite의 URL manipulation 기능을 이용하여 상대 경로(relative URL)를 사용하면서도 동일한 효과를 얻을 수 있다:

이 rewrite 규칙은 다음과 같은 형태의 하이퍼링크를 사용할 수 있게 해준다:

RSA 개인키는 암호화되어있는 메시지를 복호화 하는데 사용하는 디지털 파일이다. RSA 개인키는 그에 대응되는 공개키가 존재하며, 이 공개키는 증명서를 통하여 공개적으로 배포되어서 다른 사람들이 그 공개키를 가지고 메시지를 암호화하여 공개키의 주인에게 전송하게 된다. Certificate Signing Request(CSR)은 증명서를 발급받기 위한 요청서로서 그 사람의 공개키와 이름을 포함한다. 이 CSR을 CA에게 보내면 CA가 CSR을 실재로 사용할 수 있는 증명서(real Certificate)로 만들어 주게 되는데, 이 증명서에는 CSR을 보낸 사람의 공개키, 이름, 증명서를 발급한 CA의 이름이 들어 있으며, 그 CA에 의해서 서명 된다. 이 CA를 알고 있는 브라우져는 증명서의 서명을 확인할 수 있으며, 서명이 확인되면 증명서에 들어있는 RSA 공개키를 얻게 된다. 브라우져는 이렇게 얻은 공개키를 이용해서 그 공개키의 주인만이 복호화할 수 있는 메시지를 전송한다.

Mod_ssl을 적용한 Apache를 시동하는 것은 SSL 개인키가 pass phrase를 필요로 하는 경우 pass phrase를 요구하는 dialog가 먼저 실행되는 것을 제외하고는 일반적인 Apache를 시동하는 것과 거의 유사하다.

Pass phrase를 수동으로 입력하는 것은 서버 시스템의 부팅 시에 Apache를 시동하는 경우 문제가 될 수 있는데, “How can I get rid of the pass-phrase dialog at Apache startup time?”에 설명된 단계를 따름으로써 이를 해결할 수 있다.

서버 증명서가 반드시 잘 알려져 있는 public CA에 의해 서명될 필요는 없으며, 자신의 공개키가 포함된 증명서를 서명하는데 자신의 개인키를 사용할 수 있다. 이렇게 생성된 증명서를 자신의 서버에 설치하게 되면, 이 서버에 접속한 브라우져에는 이 증명서를 받아들일 것인가를 묻는 경고 메시지가 보여지게 되며, OK 버튼을 누르면 서버에 접속할 수 있다.

Apache를 설치할 때 “make install” 명령으로 Apache를 install하기 전에 먼저 Apache 소스 트리의 가장 상위 디렉토리에서 “make certificate” 명령을 이용하여 self-signed SSL Certificate를 생성할 수 있다. 이 증명서는 30일간 사용할 수 있으며, 또한 암호화되어지지 않는다(즉, Apache를 시동할 때 pass phrase를 묻지 않는다).

Real SSL Server Certificate를 생성하기 위한 과정은 다음과 같다:

1. SSLeay를 시스템에 설치하고 PATH 환경변수에 SSLeay의 경로를 설정한다.

2. 다음의 명령으로 Apache 서버에 대한 RSA 개인키를 생성한다(이 개인키는 3중DES로 암호화되어 PEM 포맷으로 변환되어진다):

생성하는 과정에서 PEM Pass Phrase를 입력하게 되는데, 이 pass phrase는 잃어버리지 않도록 잘 기록해 두어야 하며, 이 결과로 얻어지는 server.key파일은 이후의 복구를 위하여 안전한 곳에 백업해 둔다. 다음의 명령어로 이 RSA 개인키의 자세한 내용을 볼 수 있다:

다음의 명령으로 decrypted PEM 버전의 RSA 개인키를 생성할 수도 있다(권장되지 않는다):

3. RSA 개인키에 대한 Certificate Signing Request (CSR)을 생성한다(PEM 포맷으로 생성된다):

다음의 명령으로 이 CSR의 자세한 내용을 볼 수 있다.

4. 생성된 CSR을 CA에게 보내어 CA의 서명을 받음으로써 Apache에 실재로 사용할 수 있는 증명서를 받는다. 이 때 CSR에 서명할 CA의 선택에는 두가지의 옵션이 있다:

첫번째는 Verisign이나 Thawte와 같은 상용 CA에게 CSR 서명을 받는 것으로서, 이경우에는 보통 해당 CA의 홈페이지에서 CSR을 입력한 후 요금을 지불하고 서명된 증명서를 받아서 server.crt 파일에 저장하면 된다. 각 상용 CA들의 자세한 정보는 다음의 사이트들을 참조한다:

두번째 방법은 self-signed CA를 사용하는 것이며, 이 경우 CSR을 자신이 만든 CA로 서명하게 된다. 다음 질문에서 자신의 CA로 CSR을 서명하는 방법에 대하여 설명할 것이다.

다음의 명령으로 발급된 증명서의 자세한 내용을 볼 수 있다:

5. 위의 과정을 통하여 얻은 두개의 파일 server.key와 server.crt의 위치를 httpd.conf 파일에서 각각 다음과 같이 지정해 준다:

server.csr 파일은 더 이상 필요하지 않다.

SSLeay가 제공하는 CA.sh 스크립트를 가지고 Self-signed CA를 생성하고 사용할 수 있으며, 이 스크립트를 이용하는 방법은 다음과 같다:

1. 다음의 명령으로 자신의 CA에 대한 RSA 개인키를 생성한다(이 개인키는 3중DES로 암호화되어 PEM 포맷으로 변환되어진다):

생성하는 과정에서 PEM Pass Phrase를 입력하게 되는데, 이 pass phrase는 잃어버리지 않도록 잘 기록해 두어야 하며, 이 결과로 얻어지는 server.key파일은 이후의 복구를 위하여 안전한 곳에 백업해 둔다. 다음의 명령어로 이 RSA 개인키의 자세한 내용을 볼 수 있다:

다음의 명령으로 decrypted PEM 버전의 RSA 개인키를 생성할 수도 있다(권장되지 않는다):

2. 이 CA의 RSA 키에 대한 self-signed CA 증명서(X.509 structure)를 생성한다(PEM 포맷으로 생성된다):

다음의 명령으로 생성된 증명서의 자세한 내용을 볼 수 있다:

3. 서명 작업을 위한 스크립트를 준비한다. “ssleay ca”라는 명령어는 몇몇 까다로운 요구사항을 필요로 하며, 또한 SSLeay의 기본 설정에서는 사용자가 직접 “ssleay ca” 명령을 실행하는 것을 허용하지 않기 때문에 서명을 위한 스크립트가 필요하다. Mod_ssl은 sign.sh라는 이름의 서명을 위한 스크립트를 제공하며(pkg.contrib 디렉토리에 위치) 이 스크립트를 사용하기를 권장한다.

4. 다음의 명령으로 Apache 서버의 SSL 증명서를 생성하기 위한 CSR에 서명한다:

CSR에 서명함으로써 server.crt 파일을 얻게 되며, 이 server.crt를 Apache의 증명서로 사용하게 된다.

다음의 명령어를 이용하여 개인키를 이전 pass-phrase를 가지고 읽은 후 새로운 pass-phrase로 다시 덮어쓴다:

이 과정에서 두번의 PEM pass-phrase를 요구하게 되는데, 첫번째에는 이전의 pass-phrase를 입력하고 두번째는 새로운 pass-phrase를 입력한다.

Server.key 파일에 저장되어 있는 RSA 개인키는 보안 상의 이유로 암호화되어져 저장되어져 있기 때문에 Apache를 시작하거나 재시동할 때마다 pass-phrase를 입력 받기 위한 dialog가 실행되게 된다. 만약 이 서버가 충분히 안전하다고 확신할 수 있는 경우 dialog를 없앨 수 있다. 과정은 다음과 같다.

1. RSA 개인키로부터 암호화를 제거한다(원본 파일은 남겨둔다):

2. server.key 파일을 루트만이 읽을 수 있도록 해준다.:

이 과정을 거쳐 server.key는 암호화되지 않은 키를 가지게 되며, 이 key 파일을 Apache에 설치해 준 경우 더 이상 pass-phrase를 요구하지 않게 된다. 그러나 이것은 보안상 상당한 위험을 가진다. 따라서 항상 파일의 접근 권한을 루트나 웹 서버 사용자만이 그 파일에 접근할 수 있도록 설정해야 한다.

개인키는 일련의 숫자들을 가지는데, 이 수들 중 2개는 공개키에 포함되며, 나머지는 개인키의 일부분이 된다. 공개키에 사용된 bit들은 증명서에 포함되며 이 숫자들은 CSR로부터 얻을 수 있다. 증명서의 공개키가 개인키의 public portin과 일치하는가를 확인하기 위해서 증명서 파일과 개인키 파일을 다음의 명령으로 비교한다:

이 때 키와 증명서 안의 ‘modulus’와 ‘public exponent’ 부분이 서로 일치해야 한다. 그러나 public exponent는 보통 65537이며 긴 modulus를 비교하는 것이 힘들기 때문에 다음과 같은 명령을 사용할 수 있다:

이 명령은 매우 짧은 숫자들을 보여주며, 이 숫자들을 비교하면 된다. 만약 공개키와 개인키가 다르다면 이 숫자들이 다를 것이다. 특정 CSR이 어느 키나 증명서에 대한 것인가를 알고자 할 때는 다음과 같은 명령을 사용한다:

SSL은 웹 브라우져들과의 호환성을 위하여 기본 키 길이로 512 bit와 1024 bit를 사용한다. 1024 bit 이상의 키 길이는 일부 버전의 Netscape Navigator와 MSIE, 그리고 RSA사의 BSAFE 암호화 ToolKit을 사용하는 일부 브라우져들과 호환되지 않기 때문에 1024 bit의 길이를 가지는 키를 사용하는 것이 권장된다.

SSLCACertificatePath directive에 지정한 경로에서 CA 증명서를 찾을 때 SSLeay는 hash symlink를 통해서 증명서를 찾게 되며, 이 hash 값은 “ssleay x509 ?noout ?hash” 명령으로 생성된다. 그런데 SSLeay 0.8에서 0.9로 오면서 증명서에 대한 hash를 계산하는데 사용되는 알고리즘이 변경되었다. 따라서 SSLeay를 업그레이드한 후 먼저 모든 예전 hash symlink를 삭제하고 새로운 hash symlink를 생성해야 한다.

SSL은 강력한 암호화를 사용하며, 또한 HTTPS를 통하여 어떤 웹 페이지를 요청하는 경우 심지어 그 페이지 내의 이미지들까지 암호화된 채로 전송되기 때문에 HTTPS 전송량이 많은 경우 일반적인 Apache 서버에 비해 더 많은 서버 로드가 증가한다.

설치된 SSLeay가 지원하는 거의 대부분의 SSL cipher를 지원하며, 특히 최소한 다음과 같은 cipher들을 지원한다:

다음의 명령으로 실제로 지원하는 cipher들의 목록을 볼 수 있다:

이 문제는 닭과 달걀의 문제와 같다. SSL 프로토콜 레이어는 HTTP 프로토콜 레이어의 아래에 위치하여 HTTP를 encapsulate한다. SSL 연결(HTTPS)이 이루어질 때 Apache/mod_ssl은 클라이언트와 SSL 프로토콜 파라미터들을 협상해야 하며, 이를 위해 mod_ssl은 그 가상서버(virtual server)의 설정(예를 들어 cipher suite나 server certificate 등)을 참조해야 한다. 그러나 올바른 virtual server를 찾기 위해 Apache는 Host HTTP heaer field를 알아야 하며, 이를 위해 HTTP request header가 읽혀져야 한다. 이 과정은 SSL handshake가 끝나기 전에는 수행되지 않는데 이 과정이 수행되어야 얻어지는 정보를 이미 SSL handshake 단계가 요구하였기 때문에 이러한 문제가 발생하게 된다.

아니다, username과 passwd는 이미 암호화되어 전송되어진 것이다. Netscape 브라우져의 자물쇠 아이콘은 SSL/TLS 레이어와 정확히 동기화되지 않으며, 즉 해당 웹 페이지의 첫번째 데이터가 전송되는 시점에서야 잠김 표시로 전환되는 것이다. Basic Authentication은 HTTP 레이어의 기능이며 HTTP 레이어는 SSL/TLS 레이어 위에 위치한다. 따라서 HTTPS 프로토콜에서 어떠한 HTTP 데이터의 통신이 이루어지기 위해서는 반드시 그 이전에 SSL/TLS 레이어가 handshake 단계를 수행하고 암호화된 통신으로 전환되어야만 한다. 따라서 인증 단계에서 자물쇠 아이콘이 잠김 상태가 아니더라도 username과 passwd는 이미 암호화된 상태로 전송되게 된다.

이 장에서는 다른 SSL 솔류션들과의 backward compatibility에 대하여 기술한다. Mod_ssl만이 Apache에서 SSL을 구현한 유일한 솔류션은 아니며, 실질적으로 4개의 솔류션이 더 존재한다: Ben Laurie가 구현한 freeware인 Apache-SSL(mod_ssl의 기반이 됨), RedHat의 상용 서버인 Secure Web Server(mod_ssl에 기반을 둠), Covalent의 상용 소프트웨어인 Raven SSL Module(Apache-SSL에 기반을 둠), 마지막으로 C2Net의 상용 제품인 Stronghold(Sioux라는 다른 개발 branch에 기반을 둠)가 있다.

mod_ssl은 다른 4가지 솔류션의 기능을 대부분 지원할 수 있으며, 대부분의 경우에 있어서 쉽게 backward compatibility를 제공할 수 있다. 실질적으로 주안점을 두고 있는 compatibility 영역은 다음의 세가지이다:

configuration directive, environment variable, custom log function.

다른 SSL 솔류션의 configuration directive들에 대한 backward compatibility를 위하여 mod_ssl은 on-the-fly mapping을 사용한다: directives which have a direct counterpart in mod_ssl are mapped silently while other directives lead to a warning message in the logfiles. 현재 구현되어 있는 directive mapping은 Table 1에 있다. 현재 완전한 backward compatibility는 단지 Apache-SSL 1.x와 mod_ssl 2.0.x 간에만 이루어져 있으며, Sioux 1.x와 Stronghold 2.x는 mod_ssl이 아직 제공하지 않는 몇가지 기능상의 차이로 인하여 부분적으로만 mapping이 가능하다.