Sun Java System Messaging Server 6.3 관리 설명서

23.5 암호화 및 인증서 기반 인증 구성

이 절에는 다음과 같은 하위 절이 포함됩니다.

Messaging Server는 클라이언트 및 서버의 암호화된 통신과 인증서 기반 인증을 위해 TLS(Transport Layer Security) 프로토콜(또는 SSL(Secure Sockets Layer) 프로토콜로 알려져 있음)을 사용합니다. Messaging Server는 SSL 버전 3.0 및 3.1을 지원합니다. TLS는 SSL과 완전히 호환되며 필요한 모든 SSL 기능을 포함합니다.

SSL에 대한 배경 정보는 Managing Servers With iPlanet Console 5.0의 Introduction to SSL을 참조하십시오. SSL은 Managing Servers With iPlanet Console 5.0의 Introduction to Public-Key Cryptography에 설명되어 있는 공개 키 암호화의 개념에 기초합니다.

Messaging Server와 클라이언트 간의 메시지나 Messaging Server와 다른 서버 간의 메시지 전송이 암호화될 경우 통신에서 도청이 발생할 가능성이 거의 없습니다. 또한 연결하는 클라이언트가 인증될 경우 침입자가 클라이언트를 가장(스푸핑)할 가능성이 거의 없습니다.

SSL은 IMAP4, HTTP, POP3 및 SMTP의 응용 프로그램 계층 아래에 있는 프로토콜 계층의 기능을 수행합니다. SMTP 및 SMTP/SSL은 같은 포트를 사용하고 HTTP 및 HTTP/SSL에는 다른 포트가 필요하며 IMAP 및 IMAP/SSL과 POP 및 POP/SSL은 같은 포트나 다른 포트를 사용할 수 있습니다. 그림 23–1에 나온 것처럼 SSL은 보내는 메시지와 받는 메시지 모두에 대해 특정 메시지 통신 단계에서 작동합니다.

그림 23–1 Messaging Server와의 암호화된 통신

SSL은 홉 간의 암호화를 제공하지만 메시지는 각 중간 서버에서 암호화되지 않습니다.

주 –

보내는 메시지 대한 암호화를 사용하려면 maytls, musttls 등의 tls 채널 키워드를 포함하도록 채널 정의를 수정해야 합니다. 자세한 내용은 12.4.8 전송 계층 보안을 참조하십시오.

SSL 연결을 설정하는 과정에서 발생하는 추가 오버헤드가 서버의 성능에 부담을 줄 수 있다는 것에 주의합니다. 따라서 메시징 설치를 디자인하고 성능을 분석할 경우 서버 용량과 보안 요구 사항 간에 적절히 균형을 맞추는 것이 필요합니다.

23.5.1 인증서 얻기

SSL을 암호화에 사용하는지 아니면 인증에 사용하는지 여부에 상관 없이 Messaging Server에 대한 서버 인증서를 얻어야 합니다. 인증서는 해당 서버를 클라이언트와 다른 서버에 대해 식별합니다. 이 절의 뒷 부분에서 설명하는 대로 msgcert 명령을 사용하여 인증서를 얻는 방법이 가장 효과적입니다. 이전 certutil 명령을 계속 사용할 수는 있지만 훨씬 더 복잡하고 국제화되지 않았습니다. certutil에 대한 자세한 내용은 23.5 암호화 및 인증서 기반 인증 구성 및 http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html을 참조하십시오.

이 절은 다음과 같은 하위 절로 구성되어 있습니다.

23.5.1.1 내부 및 외부 모듈 관리

서버 인증서는 데이터를 암호화 및 해독하는 데 사용되는 숫자인 키 쌍의 소유권과 유효성을 설정합니다. 서버 인증서와 키 쌍은 서버의 신원을 나타내며 서버 내부이거나 외부의 이동식 하드웨어 카드(스마트 카드)가 될 수 있는 인증서 데이터베이스에 저장됩니다.

Sun Java System 서버는 PKCS(Public-Key Cryptography System) #11 API를 따르는 모듈을 사용하여 키 및 인증서 데이터베이스에 액세스합니다. 특정 하드웨어 장치의 PKCS #11 모듈은 일반적으로 해당 제공자로부터 얻을 수 있으며 Messaging Server에 설치한 후에만 Messaging Server에서 해당 장치를 사용할 수 있습니다. 미리 설치된 “Netscape Internal PKCS # 11 Module”은 서버 내부의 인증서 데이터베이스를 사용하는 단일 내부 소프트웨어 토큰을 지원합니다.

인증서 사용을 위해 서버를 설정하는 작업에는 인증서와 해당 키를 위한 데이터베이스를 만들고 PKCS #11 모듈을 설치하는 것이 포함됩니다. 외부 하드웨어 토큰을 사용하지 않을 경우 서버에서 내부 데이터베이스를 만들고 Messaging Server의 일부인 내부 기본 모듈을 사용합니다. 외부 토큰을 사용할 경우 하드웨어 스마트 카드 판독기를 연결하고 해당 PKCS #11 모듈을 설치합니다.

주 –

다음 절에서는 콘솔 또는 Directory Server 콘솔에 대해 설명합니다. 이 명칭은 Directory Server 6 이전 버전에 사용되는 용어입니다. 6 이상 버전에서는 그래픽 사용자 인터페이스를 Directory Server Control Center라고 합니다. 자세한 내용은 최신 Directory Server 설명서(Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide)를 참조하십시오.

내부 및 외부 PKCS #11 모듈을 모두 콘솔을 통해 관리할 수 있습니다. PKCS #11 모듈을 설치하려면 다음을 수행합니다.

하드웨어 카드 판독기를 Messaging Server 호스트 시스템에 연결하고 드라이버를 설치합니다.
msg-svr-base/sbin에 있는 modutil을 사용하여 설치된 드라이버용 PKCS #11 모듈을 설치합니다.

하드웨어 암호화 가속기 설치. 암호화를 위해 SSL을 사용할 경우 하드웨어 암호화 가속기를 설치하여 메시지를 암호화 및 해독하는 서버의 성능을 향상시킬 수 있습니다. 일반적으로 암호화 가속기는 서버 시스템에 영구적으로 설치된 하드웨어 보드와 소프트웨어 드라이버로 구성됩니다. Messaging Server는 PKCS #11 API를 따르는 가속기 모듈을 지원합니다. (이러한 모듈은 기본적으로 고유한 키를 저장하지 않으며 이를 위한 내부 데이터베이스를 사용하는 하드웨어 토큰입니다.) 가속기를 설치하려면 우선 하드웨어와 드라이버를 제조업체에서 지정한 대로 설치한 다음 하드웨어 인증서 토큰과 마찬가지로 PKCS #11 모듈을 설치하여 설치를 완료합니다.

23.5.1.2 비밀번호 파일 만들기

SSL이 사용 가능하게 되는 대부분의 Sun Java System 서버에서는 키 쌍을 해독하는 데 필요한 비밀번호를 제공하라는 메시지가 시작 시에 관리자에게 표시됩니다. 그러나 Messaging Server에서는 비밀번호를 여러 번 입력(최소한 세 개의 서버 프로세스에 필요함)하는 불편함을 없애고 무인 서버의 다시 시작을 용이하게 만들기 위해 비밀번호를 비밀번호 파일에서 읽습니다. 비밀번호는 msgcert generate_certdb 명령을 사용하여 인증서 데이터베이스를 만들 때 생성됩니다.

비밀번호 파일의 이름은 sslpassword.conf이며 msg-svr-base/config/ 디렉토리에 위치합니다. 이 파일의 항목은 다음 형식을 갖는 개별 행입니다.

moduleName:password

여기에서 moduleName은 사용할 내부 또는 외부 PKCS #11 모듈의 이름이며 password는 모듈의 키 쌍을 해독하는 비밀번호입니다. 비밀번호는 일반(암호화되지 않은) 텍스트로 저장됩니다.

Messaging Server는 내부 모듈 및 기본 비밀번호를 위한 다음과 같은 단일 항목을 가지는 기본 버전의 비밀번호 파일을 제공합니다.

Internal (Software) Token:netscape!

내부 인증서를 설치할 때 기본값이 아닌 비밀번호를 지정할 경우 비밀번호 파일의 위 행을 편집하여 지정된 비밀번호를 반영해야 합니다. 외부 모듈을 설치할 경우 이에 대해 지정한 모듈 이름과 비밀번호를 포함하는 새 행을 파일에 추가해야 합니다.

주의 –

서버 시작 시에 모듈 비밀번호를 묻는 메시지가 관리자에게 표시되지 않으므로 서버에 대한 관리자 액세스 제어와 서버 호스트 시스템 및 해당 백업의 물리적 보안을 적절하게 하는 것이 특히 중요합니다.

23.5.1.3 인증서 얻기 및 관리

SSL을 암호화에 사용하는지 아니면 인증에 사용하는지 여부에 상관 없이 Messaging Server에 대한 서버 인증서를 얻어야 합니다. 인증서는 해당 서버를 클라이언트와 다른 서버에 대해 식별합니다. 인증서 얻기 및 관리를 위한 기본 기법은 msgcert를 사용하는 것입니다. Administration Server를 설치한 경우에는 관리 콘솔을 사용할 수도 있습니다.

이 절의 나머지 부분에서는 msgcert 사용 방법에 대해 설명합니다.

23.5.1.4 `msgcert` 정보

msgcert를 사용하면 인증서 요청 생성, 인증서 데이터베이스에 인증서 추가, 데이터베이스에 있는 인증서 나열 등과 같은 작업을 수행할 수 있습니다. 자세한 내용을 보려면 명령줄에 다음을 입력하십시오.

msg-svr-base/sbin/msgcert --help

그러면 아래와 같이 표시됩니다.

# ./msgcert --help

Usage: msgcert SUBCMD [GLOBAL_OPTS] [SUBCMD_OPTS] [SUBCMD_OPERANDS]
Manages the Messaging Servers Certificate Database
The accepted values for SUBCMD are:

add-cert              Adds a certificate to the certificate database
add-selfsign-cert     Creates and adds a selfsign certificate to the 
                      certificate database
export-cert           Exports a certificate and its keys from the database
generate-certDB       Creates Messaging Server Databases cert8.db key3.db 
                      secmod.db and sslPassword
import-cert           Adds a new certificate and its keys to the cert database
import-selfsign-cert  Adds a new selfsign certificate and its keys to the 
                      cert database
list-certs            Lists all certificates in the Certificate database
remove-cert           Removes a certificate from the database
renew-cert            Renews a certificate
renew-selfsign-cert   Renews a selfsign certificate
request-cert          Generates a certificate request
show-cert             Displays a certificate

The accepted value for GLOBAL_OPTS is:-?, --help
                Displays SUBCMD help

NOTE: You must stop all the TLS or SSL-enabled servers before making any 
changes to the Certificate Database.

위에 표시된 각 하위 명령은 특정 인증서 관리 기능을 수행합니다. 다음을 입력하면 이러한 하위 명령과 해당 기능에 대한 자세한 내용을 볼 수 있습니다.

msgcert SUBCMD –help

이 절의 나머지 부분에서는 일부 공통된 인증서 관리 절차에 대해 설명합니다.

23.5.1.5 인증서 관리

이 절에서는 Messaging Server에서 SSL 인증서를 관리하는 방법에 대해 설명합니다. Messaging Server에서 SSL을 실행하려면 외부 인증 기관(CA)을 포함하는 PKI(Public Key Infrastructure) 솔루션이나 자체 서명된 인증서를 사용해야 합니다. PKI 솔루션의 경우 공개 키와 개인 키를 모두 포함하는 CA 서명된 서버 인증서가 필요합니다. 이 인증서는 하나의 Messaging Server에만 한정됩니다. 또한 공개 키가 포함된 신뢰할 수 있는 CA 인증서가 필요합니다. 신뢰할 수 있는 CA 인증서가 있으면 해당 CA의 모든 서버 인증서가 신뢰됩니다. 이 인증서를 CA 루트 키 또는 루트 인증서라고도 합니다.

인증서 데이터베이스 비밀번호 구성

인증서를 관리할 때 인증서 비밀번호를 입력하거나 비밀번호 파일을 지정할 필요는 없습니다. 비밀번호를 -W 인수로 간단히 전달할 수 있습니다. 예:

echo "password22" > /tmp/certdbpwd
echo "password22" > /tmp/certdbpwd
# ./msgcert list-certs -W /tmp/certdbpwd

기본 자체 서명된 인증서를 사용하여 Messaging Server 인증서 데이터베이스 만들기

Messaging Server 인증서 데이터베이스를 만들려면 다음 명령을 실행합니다.
msgcert generate-certDB
이 명령은 CERT_PW_FILE에서 인증서 데이터베이스 비밀번호를 읽습니다(기본값: 비밀번호 요청).

다음 명령을 사용하여 이 인증서를 볼 수 있습니다.
msgcert show-cert Server-Cert

자체 서명된 인증서 관리

테스트를 위해 인증서를 사용할 경우 자체 서명된 인증서를 사용할 수 있습니다. 배포 구성에서는 신뢰할 수 있는 인증 기관(CA) 인증서를 사용할 수 있습니다. Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

인증서 데이터베이스를 만들 때 기본 자체 서명된 인증서가 자동으로 제공됩니다. 자체 서명된 인증서를 기본값이 아닌 설정으로 사용하려면 msgcert add-selfsign-cert 명령을 사용합니다. 예:
msgcert add-selfsign-cert --name siroe --org comms --org-unit Messaging --city SantaClara --state ca --country us MySelfSigned-Cert
자체 서명된 인증서는 3개월 동안 유효합니다.

자체 서명된 인증서가 만료되면 다음 명령을 사용하여 인증서를 갱신합니다.
msgcert renew-selfsign-cert cert_alias

23.5.1.6 신뢰할 수 있는 CA의 인증서 설치

./msgcert add-cert를 사용하여 인증 기관의 인증서를 설치합니다. CA 인증서는 CA 자체의 신원을 검증합니다. 서버는 클라이언트 및 다른 서버를 인증하는 과정에서 이러한 CA 인증서를 사용합니다.

예를 들어, 비밀번호 기반 인증 외에 인증서 기반 클라이언트 인증이 가능하도록 설정한 경우(157페이지의 “인증서 기반 로그인 설정” 참조) 클라이언트가 제공할 수 있는 인증서를 발급하는 신뢰할 수 있는 모든 CA의 CA 인증서를 설치해야 합니다. 이러한 CA는 조직 내부에 대한 것이거나 민간 또는 정부 기관이나 다른 회사 등 외부에 대한 것일 수 있습니다. 인증을 위한 CA 인증서 사용에 대한 자세한 내용은 Managing Servers With iPlanet Console 5.0에서 Introduction to Public-Key Cryptography를 참조하십시오.

Messaging Server를 설치하면 여러 상용 CA에 대한 CA 인증서가 기본적으로 포함되어 있습니다. 다른 상용 CA를 추가해야 하거나 회사에서 내부 용도의 고유한 CA를 개발(Sun Java System Certificate Server 사용)하는 중이면 추가 CA 인증서를 얻어 설치해야 합니다.

주 –

Messaging Server에서 자동으로 제공되는 CA 인증서는 처음에 클라이언트 인증서에 대해 신뢰할 수 있는 것으로 표시되지 않습니다. 따라서 이러한 CA에 의해 발급된 클라이언트 인증서를 신뢰하려면 트러스트 설정을 편집해야 합니다. 자세한 내용은 23.5.1 인증서 얻기를 참조하십시오.

다음 절차에서는 Messaging Server에서 사용할 CA 서명된 서버 및 신뢰할 수 있는 CA 인증서를 요청하고 설치하는 과정에 대해 설명합니다.

CA 서명된 서버 인증서 요청

Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

CA 서명된 서버 인증서 요청을 생성합니다.

msgcert request-cert [-W CERT_PW_FILE] {-S DN|--name NAME [--org ORG] [--org-unit ORG-UNIT]
   [--city CITY] [--state STATE] [--country COUNTRY] } [-F FORMAT] [-o OUTPUT_FILE]

다음은 CA 서명된 서버 인증서 요청의 예입니다. 이 예에서는 이진 형식의 인증서를 반환합니다.

./msgcert request-cert --name aqua --org siroe --org-unit Messaging -o my_ca_signed_request_cert

ASCII 형식의 인증서를 반환하려면 명령을 다음과 같이 사용합니다.

./msgcert request-cert --name aqua --org siroe --org-unit Messaging -F ascii -o my_casigned_request_cert

인증 기관에서는 서버를 완벽하게 식별하기 위해 일반적으로 이 예에 표시된 모든 속성을 요구합니다. 각 속성에 대한 설명을 보려면 ./msgcert request-cert --help를 입력합니다. msgcert request-cert를 사용하여 인증서를 요청하는 경우 ASCII를 출력 형식으로 지정하지 않는 한 결과 인증서 요청은 이진 인증서 요청입니다. ASCII를 지정한 경우 결과 인증서 요청은 PEM 형식의 PKCS #10 인증서 요청입니다. PEM은 RFC 1421-1424에 지정되고 base64 인코딩된 인증서 요청을 ASCII 문자로 표시하는 데 사용되는 Privacy Enhanced Mail 형식입니다. 요청 내용은 다음 예와 비슷합니다.

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBdTCB3wIBADA2MRIwEAYDVQQLEwlNZXNzYWdpbmcxDjAMBgNVBAoTBXNpcm9l
MRAwDgYDVQQDEwdhcXVhdGljMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDt
KEh5Fnj/h9GEu18Da6DkJpcNShkwxanjnKs2883ZoUV5Sp4pN7U6Vfbh0414WXZh
D26m3t81q9b9h47Klkf0pW1X3BB6LOjGOHSt2VoNBI8n3hJ6XiN2zYbrlLTgdKuo
y0YrSG/kHFnqKghikag9O/Ox+cwD+mpjl2QnsPZgswIDAQABoAAwDQYJKoZIhvcN
AQEEBQADgYEArqgWQIwNZDC2d3EZawI23Wj9o6Pyvu9J1rkb+NYgIEnNp9jugxqX
F326N0ABLdHXXNX/2ZvC5TKOgS4RidTBM89N9xJvokmvRGfc+1x80uxy474YdNlZ
s+nP8AYo9dW9mrLOammozx9HLPSVYNFp4FxekgV2n8QG7WC5rkN5bCE=
-----END NEW CERTIFICATE REQUEST-----

절차에 따라 인증서 요청을 인증 기관에 전송합니다.

인증 기관 인증서를 얻는 프로세스는 사용하는 인증 기관에 따라 다릅니다. 일부 상업용 CA는 인증서를 자동으로 다운로드할 수 있는 웹 사이트를 제공합니다. 그 외의 CA는 요청 시 인증서를 전자 메일로 전송합니다.

요청을 보낸 후 CA에서 인증서로 응답할 때까지 기다려야 합니다. 요청에 대한 응답 시간은 각각 다릅니다. 예를 들어, CA가 회사 내부에 있는 경우 CA가 요청에 응답하는 데 1-2일이 걸릴 수 있습니다. 선택한 CA가 회사 외부에 있는 경우 CA가 요청에 응답하는 데 몇 주일이 걸릴 수도 있습니다.

인증 기관으로부터 수신한 인증서를 저장합니다.

인증서를 안전한 위치에 백업해 두어야 합니다. 인증서가 손실될 경우 백업 파일을 사용하여 인증서를 다시 설치할 수 있습니다. 인증서를 텍스트 파일로 저장할 수 있습니다. PEM 형식의 PKCS #11 인증서는 다음 예와 비슷합니다.

CA 서명된 서버 인증서 및 신뢰할 수 있는 CA 인증서 추가

Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

다음 명령을 사용하여 CA 서명된 서버 인증서를 추가합니다.
msgcert add-cert cert_alias cert_file
여기서 cert_alias는 인증서를 식별하기 위해 제공하는 이름이고, cert_file은 PEM 형식의 PKCS #11 인증서를 포함하는 텍스트 파일입니다.

예를 들어, CA 서명된 서버 인증서를 설치하려면 다음과 비슷한 명령을 사용할 수 있습니다.
msgcert add-cert /my_cert/server-cert-file
이제 인증서가 설치되었지만 아직 신뢰되지는 않습니다. CA 서명된 서버 인증서를 신뢰하려면 인증 기관 인증서를 설치해야 합니다.

다음 명령을 사용하여 신뢰할 수 있는 인증 기관 인증서를 추가합니다.
msgcert add-cert -C cert_alias cert_file
-C 옵션은 인증서가 신뢰할 수 있는 인증 기관 인증서임을 나타냅니다.

예를 들어, 인증 기관의 신뢰할 수 있는 인증서를 설치하려면 다음 명령을 사용할 수 있습니다.
msgcert add-cert -C CA-cert /my_cert/ca-cert-file

선택적으로 다음 명령을 사용하여 설치한 인증서를 확인합니다.

모든 서버 인증서를 나열하여 별칭 및 유효 날짜와 같은 정보를 표시하려면 다음 명령을 사용합니다.

msgcert list-certs

Messaging Server에는 ./msgcert generate-CertDB를 통해 생성된 경우 Server-Cert라는 기본 인증서가 있습니다. 텍스트 Same as issuer는 기본 인증서가 자체 서명된 서버 인증서임을 나타냅니다. 예를 들면 다음과 같습니다.

# ./msgcert list-certs
Enter the certificate database password:
Alias          Valid from       Expires on       Self-   Issued by             Issued to
                                                 signed
------------   ----------------  --------------- ------  --------------------- -------------------------  --------------
SelfSignedCrt 2006/07/28 12:58  2006/10/28 12:58   y     CN=SFO,L=SC,ST=ca,C=us  Same as issuer
Server-Cert   2006/07/28 07:47  2006/10/28 07:47   y     CN=perseids             Same as issuer
2 certificates found

신뢰할 수 있는 CA 인증서를 나열하려면 다음 명령을 사용합니다.

msgcert list-certs -C

인증서 만료 날짜를 포함하여 인증서 세부 정보를 보려면 다음 명령을 사용합니다.

msgcert show-cert cert_alias

예를 들어, 자체 서명된 인증서를 표시하려면 다음 명령을 사용합니다.

# ./msgcert show-cert MySelfSigned-Cert
Enter the certificate database password:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            00:83:35:37:94
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer:
            "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us"
        Validity:
            Not Before: Fri Jul 28 19:58:31 2006
            Not After : Sat Oct 28 19:58:31 2006
        Subject:
            "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    aa:9d:3d:23:b2:59:39:f3:77:c8:69:7f:b0:d1:ac:d2:
                    4e:81:c8:51:0f:27:6f:a1:21:4b:a9:27:46:d7:0f:b4:
                    c8:44:86:32:5e:4f:2f:1c:2f:a9:b8:a3:49:b5:b8:ab:
                    51:a8:a5:ba:1c:e8:90:7d:46:67:f9:a7:44:c5:1d:24:
                    e6:bd:e8:8f:07:b4:5a:68:41:b1:19:f2:ea:98:ba:25:
                    55:b8:ba:9c:af:bb:43:c3:c0:8f:14:a7:4c:2b:50:b4:
                    ac:df:b5:cd:68:de:a6:14:9d:68:77:d3:8b:7f:de:c0:
                    5d:35:d7:55:8d:b5:c3:14:2a:60:a9:bf:de:96:90:a9
                Exponent: 65537 (0x10001)
    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        15:86:f1:cc:85:c9:08:0f:ff:d3:56:d8:e2:c8:ea:3c:
        8e:45:36:be:8b:b0:7d:2f:e9:cd:e3:b4:ad:8c:70:59:
        c8:a5:14:da:9c:fa:7f:70:86:64:34:0b:21:ae:c4:28:
        d2:f5:94:5c:a6:78:0f:d9:fd:fc:c5:5e:37:49:25:a9:
        bc:12:59:cb:fb:4e:e9:d4:8a:8d:3d:41:12:ae:f1:7f:
        8d:d3:10:ac:fb:33:51:5d:0c:1b:dc:23:5f:95:d5:6d:
        c6:1d:e5:ed:13:8b:16:41:89:5b:4d:de:c0:c7:56:a2:
        48:82:38:32:5a:99:d5:21:20:c5:0d:5c:ea:0c:84:aa
    Fingerprint (MD5):
        EF:76:A3:6C:09:4E:BC:6B:87:76:A3:35:70:1F:B2:C4
    Fingerprint (SHA1):
        BB:1C:20:4B:79:3A:F1:49:F0:83:FB:CC:9C:56:10:D3:06:97:AA:07

    Certificate Trust Flags:
        SSL Flags:
            Valid CA
            Trusted CA
            User
            Trusted Client CA
        Email Flags:
            User
        Object Signing Flags:
            User

만료된 CA 서명된 서버 인증서 갱신

CA 서명된 서버 인증서(공개 및 개인 키)가 만료된 경우 다음 절차에 따라 인증서를 갱신할 수 있습니다. Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

인증 기관으로부터 업데이트된 CA 서명된 서버 인증서를 얻습니다.

업데이트된 인증서를 받은 다음 인증서를 설치합니다.
msgcert renew-cert cert_alias cert_file

CA 서명된 서버 인증서 내보내기 및 가져오기

경우에 따라 나중에 인증서를 다른 시스템(예: 다른 호스트)으로 가져올 수 있도록 인증서를 내보낼 수도 있습니다. Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

인증서를 내보냅니다.

msgcert export-cert [-o OUTPUT_FILE] CERT_ALIAS

예를 들면 다음과 같습니다.

$ ./msgcert export-cert -o /tmp/first-certificate "First Certificate"
$./msgcert export-cert -o /tmp/first-server-certificate Server-Cert
Choose the PKCS#12 file password:
Confirm the PKCS#12 file password:
$ls /tmp
first-server-certificate
/tmp/first-certificate

인증서를 가져옵니다.

$ msgcert import-cert  CERT_FILE

예를 들어, 인증서를 가져오려면 다음 명령을 사용합니다.

$ msgcert import-cert /tmp/first-server-certificate
Enter the PKCS#12 file password:
$

23.5.2 SSL 사용 및 암호문 선택

콘솔을 사용하여 SSL을 사용 가능하게 하고 Messaging Server가 클라이언트와의 암호화된 통신에 사용할 수 있는 암호화 암호문 집합을 선택할 수 있습니다. msgcert 유틸리티를 사용하여 SSL 인증서를 설치하고 해당 configutil을 실행하거나 해당 서비스에 대해 SSL을 활성화하는 데 필요한 구성 파일을 편집할 수도 있습니다.

23.5.2.1 암호문 정보

암호문은 암호화 프로세스에서 데이터를 암호화 및 해독하는 데 사용되는 알고리즘입니다. 일부 암호문은 다른 암호문보다 강력한데 이는 이러한 암호문으로 스크램블된 메시지를 권한 없는 사용자가 해독하는 것이 더 어렵다는 것을 의미합니다.

암호문은 키(긴 번호)를 데이터에 적용하는 방법으로 데이터에서 작동합니다. 일반적으로 암호문이 암호화 도중에 사용하는 키가 더 길수록 적절한 암호화 키 없이 데이터를 해독하는 것이 어려워집니다.

클라이언트는 Messaging Server와의 SSL 연결을 시작할 때 암호화에 사용할 선호되는 암호문과 키 길이를 서버에 알려줍니다. 모든 암호화된 통신에서 클라이언트와 서버는 동일한 암호문을 사용해야 합니다. 일반적으로 다양한 암호문 및 키 조합이 사용되기 때문에 서버는 암호화를 유연하게 지원해야 합니다. Messaging Server는 암호문 및 키 길이 조합을 최대 6개까지 지원할 수 있습니다.

표 23–2에는 SSL 3.0과 함께 사용하는 Messaging Server에서 지원하는 암호문이 나열되어 있습니다. 이 표에 요약된 정보의 자세한 내용은 Managing Servers with iPlanet Console의 Introduction to SSL 절에서 확인할 수 있습니다.

표 23–2 Messaging Server의 SSL 암호문


암호문	설명
128비트 암호화 및 MD5 메시지 인증을 사용하는 RC4	가장 빠른 암호화 암호문(RSA에 의한)이며 강도가 매우 높은 암호문 및 암호화 키의 조합입니다.
168비트 암호화 및 SHA 메시지 인증을 사용하는 Triple DES	더 느린 암호화 암호문(미국 정보 표준)이지만 강도가 가장 높은 암호문 및 암호화 키의 조합입니다.
56비트 암호화 및 SHA 메시지 인증을 사용하는 DES	더 느린 암호화 암호문(미국 정보 표준)이며 강도가 보통인 암호문 및 암호화 키의 조합입니다.
40비트 암호화 및 MD5 메시지 인증을 사용하는 RC4	가장 빠른 암호화 암호문(RSA에 의한)이며 강도가 낮은 암호문 및 암호화 키의 조합입니다.
40비트 암호화 및 MD5 메시지 인증을 사용하는 RC2	더 느린 암호화 암호문(RSA에 의한)이며 강도가 낮은 암호문 및 암호화 키의 조합입니다.
암호화 없음, MD5 메시지 인증만 사용	암호화가 없으며 메시지 다이제스트만 인증에 사용됩니다.

특정 암호문을 사용하지 않을 중요한 이유가 없을 경우 모든 암호문을 지원해야 합니다. 그러나 일부 국가에서는 수출법에 따라 특정 암호화 암호문의 사용이 제한된다는 것에 주의합니다. 또한 미국 수출 제한법이 완화되기 전에 만들어진 일부 클라이언트 소프트웨어는 더 높은 강도의 암호화를 사용할 수 없습니다. 40비트 암호문이 우발적인 도청을 방지할 수 있지만 보안되지는 않으므로 적극적인 공격을 차단하지 않는다는 것에 주의합니다.

SSL을 사용 가능하게 하고 암호화 암호문을 선택하려면 다음 명령줄 단계를 따릅니다.

인증서를 지정하려면 다음을 수행합니다.

configutil -o encryption.rsa.nssslpersonalityssl -v certname

또한 SSL 서버 인증서 별명에 대한 서비스별 구성 설정이 있습니다. 새 configutil 설정은 다음과 같습니다.

local.imta.sslnicknames(SMTP 및 Submit 서버용), local.imap.sslnicknames(IMAP 서버용), local.pop.sslnicknames(POP 서버용), local.http.sslnicknames(웹 메일 서버용)

이러한 설정은 의미가 동일하며 encryption.rsa.nssslpersonalityssl 설정을 대체합니다. 특히, 이 설정은 쉼표로 분리된 NSS 인증서 별명 목록입니다. 목록에 허용되는 별명이 여러 개 있더라도 각 별명은 서로 다른 유형의 인증서(예: RSA 인증서 및 DSS 인증서)를 참조해야 하므로 설정은 거의 항상 한 개의 별명입니다. NSS 소프트웨어 토큰 또는 기본 토큰을 검색하는 경우 별명이 비정규화될 수 있습니다. 또는 지정된 보안 모듈에서 해당 별명을 검색하는 경우 security-module: nickname" 형식을 사용할 수 있습니다. 이는 기본 NSS 데이터베이스 이외의 위치나 하드웨어 토큰에 저장된 인증서에 필요합니다.

또한 제품에서 여러 NSS 소프트웨어 토큰을 사용할 수 없습니다. 특히 IMAP, POP, SMTP 및 HTTP용으로는 cert8.db, key3.db 및 secmod.db가 하나만 제공됩니다. NSS에서는 그렇지 않습니다.

주 –

보내는 메시지에 대해 SSL 암호화를 사용하려면 채널 정의를 수정하여 maytls, musttls 등의 tls 채널 키워드를 포함해야 합니다. 자세한 내용은 12.4.8 전송 계층 보안을 참조하십시오.

23.5.3 인증서 기반 로그인 설정

비밀번호 기반 인증 외에도 Sun Java System 서버는 디지털 인증서 검사를 통한 사용자 인증을 지원합니다. 인증서 기반 인증에서 클라이언트는 서버와의 SSL 세션을 설정하고 사용자의 인증서를 서버로 제출합니다. 그런 다음 서버는 제출된 인증서가 진짜인지 여부를 평가합니다. 인증서가 검증될 경우 사용자는 인증된 것으로 간주됩니다.

인증서 기반 로그인을 사용하도록 Messaging Server를 설정하려면 다음을 수행합니다.

인증서 기반 로그인 설정

서버의 서버 인증서를 얻습니다. 자세한 내용은 23.5.1 인증서 얻기를 참조하십시오.

인증서 설정 마법사를 실행하여 서버가 인증할 사용자에게 인증서를 발급하는 신뢰할 수 있는 모든 인증 기관의 인증서를 설치합니다. 자세한 내용은 23.5.1.6 신뢰할 수 있는 CA의 인증서 설치를 참조하십시오.

서버의 데이터베이스에 최소한 하나 이상의 신뢰할 수 있는 CA가 있을 경우 서버는 각 연결 클라이언트로부터 클라이언트 인증서를 요청한다는 것에 주의합니다.

SSL을 설정합니다. 자세한 내용은 23.5.2 SSL 사용 및 암호문 선택을 참조하십시오.

(선택 사항) 제출된 인증서의 정보에 기초하여 서버가 LDAP 사용자 디렉토리를 적절하게 검색하도록 서버의 certmap.conf 파일을 편집합니다.

사용자의 인증서에 있는 전자 메일 주소가 사용자의 디렉토리 항목에 있는 전자 메일 주소와 일치하며 검색을 최적화하거나 사용자 항목의 인증서에 대해 제출된 인증서를 검증할 필요가 없을 경우에는 certmap.conf 파일을 편집할 필요가 없습니다.

certmap.conf의 형식과 변경할 수 있는 사항에 대한 자세한 내용은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

이러한 단계를 수행하고 나면 사용자가 IMAP 또는 HTTP에 로그인할 수 있도록 클라이언트가 SSL 세션을 설정할 때 Messaging Server는 클라이언트로부터 사용자의 인증서를 요청합니다. 클라이언트에 의해 제출된 인증서가 서버에서 신뢰할 수 있는 것으로 설정한 CA가 발급했으며 인증서의 아이디가 사용자 디렉토리의 항목과 일치할 경우 사용자가 인증되며 액세스가 허가됩니다(해당 사용자를 제어하는 액세스 제어 규칙에 따라).

인증서 기반 로그인을 사용 가능하게 하기 위해 비밀번호 기반 로그인을 허용하지 않을 필요는 없습니다. 비밀번호 기반 로그인이 허용되는 기본 상태에서 이 절에 설명된 작업을 수행할 경우 비밀번호 기반 및 인증서 기반 로그인이 모두 지원됩니다. 이 경우 클라이언트가 SSL 세션을 설정하고 인증서를 제공할 경우 인증서 기반 로그인이 사용됩니다. 클라이언트가 SSL을 사용하지 않거나 인증서를 제공하지 않을 경우 서버는 비밀번호를 요청합니다.

23.5.4 SMTP 프록시를 사용하여 SSL 성능을 최적화하는 방법

SMTP 프록시는 SMTP 프로토콜에 추가 대기 시간을 야기하므로 대부분의 사이트는 SMTP 프록시를 사용해서는 안 됩니다. 그러나 SMTP 연결을 보호하기 위해 SSL에 많이 의존하는 대규모 사이트는 SSL 및 프록시 외에는 일체 수행하지 않는 서버에서 모든 프로토콜에 대해 모든 SSL 작업을 수행하여 SSL 가속기 하드웨어에 대한 투자를 극대화하길 원할 수 있습니다. SMTP 프록시를 사용하면 메시지 대기열을 별개의 MTA 시스템에 두면서 SSL을 프런트엔드 프록시 서버에서 처리할 수 있습니다. 이러한 방법으로 각 작업에 대해 최적화된 하드웨어를 별도로 구성 및 구입할 수 있습니다.

SMTP 프록시를 설치하는 방법은 Sun Java Communications Suite 5 Deployment Planning Guide의 Using the MMP SMTP Proxy 및 23.8 POP before SMTP 사용을 참조하십시오.

23.5 암호화 및 인증서 기반 인증 구성

그림 23–1 Messaging Server와의 암호화된 통신

23.5.1 인증서 얻기

23.5.1.1 내부 및 외부 모듈 관리

23.5.1.2 비밀번호 파일 만들기

23.5.1.3 인증서 얻기 및 관리

23.5.1.4 msgcert 정보

23.5.1.5 인증서 관리

인증서 데이터베이스 비밀번호 구성

기본 자체 서명된 인증서를 사용하여 Messaging Server 인증서 데이터베이스 만들기

자체 서명된 인증서 관리

23.5.1.6 신뢰할 수 있는 CA의 인증서 설치

CA 서명된 서버 인증서 요청

CA 서명된 서버 인증서 및 신뢰할 수 있는 CA 인증서 추가

만료된 CA 서명된 서버 인증서 갱신

CA 서명된 서버 인증서 내보내기 및 가져오기

23.5.2 SSL 사용 및 암호문 선택

23.5.2.1 암호문 정보

23.5.3 인증서 기반 로그인 설정

인증서 기반 로그인 설정

23.5.4 SMTP 프록시를 사용하여 SSL 성능을 최적화하는 방법

23.5.1.4 `msgcert` 정보