Application Server를 설치하면 내부 검사에 적합한 JSSE(Java Secure Socket Extension) 또는 NSS(Network Security Services) 형식으로 디지털 인증서가 생성됩니다. 기본적으로 Application Server는 domain-dir/config 디렉토리의 인증서 데이터베이스에 인증서 정보를 저장합니다.
Keystore 파일, key3.db에는 개인 키를 비롯하여 Application Server의 인증서가 포함되어 있습니다. Keystore 파일은 비밀번호로 보호됩니다. 비밀번호는 asadmin change-master-password 명령을 사용하여 변경합니다. certutil에 대한 자세한 내용은 certutil 유틸리티 사용을 참조하십시오.
모든 keystore 항목에는 고유한 별칭이 있습니다. 설치 후 Application Server keystore는 별칭이 s1as인 단일 항목을 가집니다.
Truststore 파일, cert8.db에는 다른 엔티티에 대한 공개 키를 비롯하여 Application Server의 신뢰할 수 있는 인증서가 포함되어 있습니다. 신뢰할 수 있는 인증서의 경우 서버에서 인증서의 공개 키가 인증서 소유자에게 속하는지를 확인합니다. 일반적으로 신뢰할 수 있는 인증서에는 인증 기관의 인증서(CA)가 포함됩니다.
Platform Edition의 경우 Application Server는 서버측에서 keytool을 사용하여 인증서와 keystore를 관리하는 JSSE 형식을 사용합니다. Enterprise Edition의 경우 Application Server는 서버측에서 certutil을 사용하여 개인 키와 인증서를 저장하는 NSS 데이터베이스를 관리하는 NSS를 사용합니다. 두 경우 모두 클라이언트측(응용 프로그램 클라이언트 또는 독립 실행형)에서는 JSSE 형식을 사용합니다.
기본적으로 Application Server에는 예 응용 프로그램과 함께 작동하고 개발 용도로 사용되는 keystore 및 truststore가 구성되어 있습니다. 작업을 위해 인증서 별칭을 변경하거나 다른 인증서를 truststore에 추가하거나 keystore 및 truststore 파일의 이름 및/또는 위치를 변경할 수 있습니다.
개발용으로 제공된 keystore 및 truststore 파일은 domain-dir/config 디렉토리에 저장됩니다.
관리 콘솔에서 server-config 노드 > JVM 설정 > JVM 옵션 탭을 확장하여 인증서 파일의 새 위치 값을 추가하거나 수정합니다.
-Dcom.sun.appserv.nss.db=${com.sun.aas.instanceRoot}/NSS-database-directory |
여기서 NSS-database-directory는 NSS 데이터베이스의 위치입니다.
keytool을 사용하여 JSSE(Java Secure Socket Extension) 디지털 인증서를 설정하고 작업합니다. Platform Edition과 Enterprise Edition 모두의 경우 클라이언트측(응용 프로그램 클라이언트 또는 독립 실행형)에서는 JSSE 형식을 사용합니다.
J2SE SDK에는 keytool이 함께 제공되므로 관리자가 공개/개인 키 쌍 및 연관된 인증서를 관리할 수 있습니다. 사용자가 통신 피어의 공개 키를 인증서 양식으로 캐시할 수도 있습니다.
keytool을 실행하려면 J2SE /bin 디렉토리가 경로에 있도록 쉘 환경을 구성하거나 도구에 대한 전체 경로를 명령줄에서 제공해야 합니다. keytool에 대한 자세한 내용은 http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html에 있는 keytool 설명서를 참조하십시오.
다음 예는 JSSE 도구를 사용한 인증서 처리와 관련된 사용법을 보여줍니다.
자체 서명된 인증서를 RSA 키 알고리즘을 사용하여 JKS 유형의 keystore로 만듭니다. RSA는 RSA Data Security, Inc.에서 개발한 공개 키 암호화 기술입니다. RSA는 기술 발명자인 Rivest, Shamir, Adelman의 약자입니다.
keytool -genkey -noprompt -trustcacerts -keyalg RSA -alias ${cert.alias} -dname ${dn.name} -keypass ${key.pass} -keystore ${keystore.file} -storepass ${keystore.pass} |
인증서를 만드는 다른 예는 keytool 유틸리티를 사용하여 인증서 생성에 있습니다.
자체 서명된 인증서를 기본 키 알고리즘을 사용하여 JKS 유형의 keystore로 만듭니다.
keytool -genkey -noprompt -trustcacerts -alias ${cert.alias} -dname ${dn.name} -keypass ${key.pass} -keystore ${keystore.file} -storepass ${keystore.pass} |
인증서에 서명하는 예는 keytool 유틸리티를 사용하여 디지털 인증서 서명에 있습니다.
JKS 유형의 keystore에서 사용할 수 있는 인증서를 표시합니다.
keytool -list -v -keystore ${keystore.file} -storepass ${keystore.pass} |
JKS 유형의 keystore에서 인증서 정보를 표시합니다.
keytool -list -v -alias ${cert.alias} -keystore ${keystore.file} -storepass ${keystore.pass} |
RFC/텍스트 형식 인증서를 JKS 저장소로 가져옵니다. 인증서는 대체로 바이너리 인코딩 대신 인터넷 RFC(Request for Comments) 1421 표준으로 정의한 인쇄 가능한 인코딩 형식으로 저장됩니다. Base 64 인코딩이라고도 하는 이 인증서 형식은 인증서를 다른 응용 프로그램으로 전자 메일이나 몇 가지 다른 메커니즘을 통해 간편하게 내보낼 수 있게 해줍니다.
keytool -import -noprompt -trustcacerts -alias ${cert.alias} -file ${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass} |
JKS 유형의 keystore에서 PKCS7 형식으로 인증서를 내보냅니다. Public Key Cryptography Standards(공개 키 암호화 표준) #7과 Cryptographic Message Syntax Standard(암호화 메시지 구문 표준)로 정의한 응답 형식에는 발행된 인증서 외에 지원 인증서 체인이 포함됩니다.
keytool -export -noprompt -alias ${cert.alias} -file ${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass} |
JKS 유형의 keystore에서 PKCS7 형식으로 인증서를 내보냅니다.
keytool -export -noprompt -rfc -alias ${cert.alias} -file ${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass} |
JKS 유형의 keystore에서 인증서를 삭제합니다.
keytool -delete -noprompt -alias ${cert.alias} -keystore ${keystore.file} -storepass ${keystore.pass} |
keystore에서 인증서를 삭제하는 다른 예는 keytool 유틸리티를 사용하여 인증서를 삭제하는 방법에 있습니다.
keytool을 사용하여 인증서를 생성하고 가져오며 내보냅니다. 기본적으로 keytool은 실행될 디렉토리에 keystore 파일을 만듭니다.
인증서가 실행될 디렉토리로 변경합니다.
인증서는 반드시 keystore와 truststore 파일이 있는 디렉토리(기본은 domain-dir/config)에 생성하십시오. 이 파일의 위치를 변경하는 방법에 대한 자세한 내용은 인증서 파일 위치 변경을 참조하십시오.
다음의 keytool 명령을 입력하여 keystore 파일 keystore.jks에 인증서를 생성합니다.
keytool -genkey -alias keyAlias-keyalg RSA -keypass changeit -storepass changeit -keystore keystore.jks |
keyAlias와 같이 고유한 이름을 사용합니다. keystore 또는 개인 키 비밀번호의 기본값을 변경한 경우 위 명령의 changeit을 새 비밀번호로 대체합니다.
이름, 조직 및 keytool이 인증서를 생성하는 데 사용할 기타 정보를 묻는 메시지가 표시됩니다.
다음의 keytool 명령을 입력하여 생성된 인증서를 server.cer(아니면 client.cer) 파일로 내보냅니다.
keytool -export -alias keyAlias-storepass changeit -file server.cer -keystore keystore.jks |
인증 기관에서 서명한 인증서가 필요한 경우에는 keytool 유틸리티를 사용하여 디지털 인증서 서명을 참조하십시오.
cacerts.jks truststore 파일을 만들고 인증서를 truststore에 추가하려면 다음의 keytool 명령을 입력합니다.
keytool -import -v -trustcacerts -alias keyAlias -file server.cer -keystore cacerts.jks -keypass changeit |
keystore 또는 개인 키 비밀번호의 기본값을 변경한 경우 위 명령의 changeit을 새 비밀번호로 대체합니다.
도구는 인증서에 대한 정보를 표시하고 해당 인증서에 대한 신뢰 여부를 묻습니다.
yes를 입력하고 Enter 키를 누릅니다.
그러면 keytool은 다음과 같은 메시지를 표시합니다.
Certificate was added to keystore [Saving cacerts.jks] |
Application Server를 다시 시작합니다.
디지털 인증서를 만든 후 소유자는 위조를 막기 위해 인증서에 서명해야 합니다. 전자 상거래 사이트나 아이디 인증이 중요한 사이트는 잘 알려진 인증 기관(CA)에서 인증서를 구매할 수 있습니다. 인증이 중요하지 않은 경우, 예를 들어 개인적인 보안 통신만 필요한 경우에는 인증서를 얻는데 필요한 시간과 경비를 절약하고 자체 서명된 인증서를 사용합니다.
CA의 웹 사이트에서 지침을 수행하여 인증서 키 쌍을 생성합니다.
생성된 인증서 키 쌍을 다운로드합니다.
인증서는 반드시 keystore와 truststore 파일이 있는 디렉토리(기본은 domain-dir/config 디렉토리)에 저장하십시오. 인증서 파일 위치 변경을 참조하십시오.
쉘에서 인증서가 있는 디렉토리로 변경합니다.
keytool을 사용하여 인증서를 로컬 keystore로 가져오고, 필요한 경우 로컬 truststore로도 가져옵니다.
keytool -import -v -trustcacerts -alias keyAlias -file server.cer -keystore cacerts.jks -keypass changeit -storepass changeit |
keystore 또는 개인 키 비밀번호의 기본값을 변경한 경우 위 명령의 changeit을 새 비밀번호로 대체합니다.
Application Server를 다시 시작합니다.
기존의 인증서를 삭제하려면 다음 예와 같이 keytool -delete 명령을 사용합니다.
keytool -delete -alias keyAlias -keystore keystore-name -storepass password
Enterprise Edition의 경우 서버측에서 NSS(Network Security Services) 디지털 인증서를 사용하여 개인 키와 인증서를 저장하는 데이터베이스를 관리합니다. 클라이언트측(응용 프로그램 클라이언트 또는 독립 실행형)의 경우 JSSE(Java Secure Socket Extension) 도구 사용에서 설명한 대로 JSSE 형식을 사용합니다.
NSS(Network Security Services)를 사용하여 보안을 관리하는 도구는 다음 사항을 포함합니다.
certutil은 인증서 및 키 데이터베이스를 관리하기 위한 명령줄 유틸리티입니다. certutil 유틸리티를 사용한 몇 가지 예는 certutil 유틸리티 사용에 있습니다.
pk12util은 인증서/키 데이터베이스와 PKCS12 형식의 파일 간에 키와 인증서를 내보내고 가져오기 위해 사용하는 명령줄 유틸리티입니다. pk12util 유틸리티를 사용한 몇 가지 예는 pk12util 유틸리티를 사용하여 인증서 가져오기 및 내보내기에 있습니다.
modutil은 secmod.db 파일 또는 하드웨어 토큰 내에서 PKCS #11 모듈 정보를 관리하기 위해 사용하는 명령줄 유틸리티입니다. modutil 유틸리티를 사용한 몇 가지 예는 modutil을 사용하여 PKCS11 모듈 추가 및 삭제에 있습니다.
도구는 install-dir/lib/ 디렉토리에 있습니다. 다음 환경 변수는 NSS 보안 도구의 위치를 나타내는 데 사용됩니다.
LD_LIBRARY_PATH =${install-dir}/lib
${os.nss.path}
예에서 인증서 공통 이름(CN)은 클라이언트나 서버의 이름입니다. CN은 SSL 핸드셰이크 중에 인증서 이름과 인증서를 만든 호스트 이름을 비교하는 데도 사용됩니다. 인증서 이름과 호스트 이름이 일치하지 않으면 SSL 핸드셰이크 중에 경고나 예외가 생성됩니다. 몇 가지 예에서 편의상 인증서 공통 이름 CN=localhost가 사용되는데 모든 사용자는 실제 호스트 이름을 사용하여 새 인증서를 만드는 대신 이 인증서를 사용할 수 있습니다.
다음 예는 NSS 도구를 사용한 인증서 처리와 관련된 사용법을 보여줍니다.
certutil을 실행하기 전에 LD_LIBRARY_PATH가 이 유틸리티를 실행하는 데 필요한 라이브러리의 위치를 가리키도록 합니다. 이 위치는 asenv.conf(제품 차원의 구성 파일)의 AS_NSS_LIB 값에서 식별할 수 있습니다.
인증서 데이터베이스 도구인 certutil은 Netscape Communicator cert8.db 및 key3.db 데이터베이스 파일을 작성 및 수정할 수 있는 명령줄 유틸리티입니다. 또한 cert8.db 파일 내에 인증서를 나열, 생성, 수정 또는 삭제하거나, 비밀번호를 작성 또는 변경하거나 새로운 공개 및 개인 키 쌍을 생성하거나, 키 데이터베이스 내용을 표시하거나 key3.db 파일 내의 키 쌍을 삭제할 수도 있습니다.
키와 인증서 관리 프로세스는 대개 키 데이터베이스에 키를 만든 다음 인증서 데이터베이스에 인증서를 생성 및 관리하는 것으로 시작됩니다. 다음의 설명서에서는 certutil 유틸리티의 구문을 포함하여 NSS를 사용한 인증서 및 키 데이터베이스 관리에 대해 설명합니다. http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
아래 목록의 각 항목은 NSS 및 JSSE 보안 도구를 사용하여 인증서를 만들거나 관리하는 예를 보여줍니다.
자체 서명된 서버와 클라이언트 인증서를 생성합니다. 이 예에서 CN 형식은 hostname.domain.[com|org|net|...]입니다.
이 예의 경우 domain-dir/config입니다. serverseed.txt와 clientseed.txt 파일은 임의의 텍스트를 포함할 수 있습니다. 임의의 텍스트는 키 쌍을 생성하는 데 사용됩니다.
certutil -S -n $SERVER_CERT_NAME -x -t "u,u,u" -s "CN=$HOSTNAME.$HOSTDOMAIN, OU=Java Software, O=Sun Microsystems Inc., L=Santa Clara, ST=CA, C=US" -m 25001 -o $CERT_DB_DIR/Server.crt -d $CERT_DB_DIR -f passfile <$CERT_UTIL_DIR/serverseed.txt |
클라이언트 인증서를 생성합니다. 이 인증서도 자체 서명된 인증서입니다.
certutil -S -n $CLIENT_CERT_NAME -x -t "u,u,u" -s "CN=MyClient, OU=Java Software, O=Sun Microsystems Inc., L=Santa Clara, ST=CA, C=US" -m 25002 -o $CERT_DB_DIR/Client.crt -d $CERT_DB_DIR -f passfile <$CERT_UTIL_DIR/clientseed.txt |
이전의 글머리표 기호에서 인증서가 생성되었는지 확인합니다.
certutil -V -u V -n $SERVER_CERT_NAME -d $CERT_DB_DIR certutil -V -u C -n $CLIENT_CERT_NAME -d $CERT_DB_DIR |
사용할 수 있는 인증서를 표시합니다.
certutil -L -d $CERT_DB_DIR |
RFC 텍스트 형식 인증서를 NSS 인증서 데이터베이스로 가져옵니다.
certutil -A -a -n ${cert.nickname} -t ${cert.trust.options} -f ${pass.file} -i ${cert.rfc.file} -d ${admin.domain.dir}/${admin.domain}/config |
인증서를 NSS 인증서 데이터베이스에서 RFC 형식으로 내보냅니다.
certutil -L -a -n ${cert.nickname} -f ${pass.file} -d ${admin.domain.dir}/${admin.domain}/config > cert.rfc |
인증서를 NSS 인증서 데이터베이스에서 삭제합니다.
certutil -D -n ${cert.nickname} -f ${pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
인증서를 NSS 데이터베이스에서 JKS 형식으로 이동합니다.
certutil -L -a -n ${cert.nickname} -d ${admin.domain.dir}/${admin.domain}/config > cert.rfc keytool -import -noprompt -trustcacerts -keystore ${keystore.file} -storepass ${keystore.pass} -alias ${cert.alias} -file cert.rfc |
pk12util은 PKCS12 형식의 인증서/키 데이터베이스 및 파일 간에 키와 인증서를 가져오고 내보내는 데 사용하는 명령줄 유틸리티입니다. PKCS12는 Personal Information Exchange Syntax Standard(개인 정보 상호 교환 구문 표준)의 PKCS(Public-Key Cryptography Standards) #12입니다. pk12util 유틸리티에 대한 자세한 내용은 http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html을 참조하십시오.
PKCS12 형식의 인증서를 NSS 인증 데이터베이스로 가져옵니다.
pk12util -i ${cert.pkcs12.file} -k ${certdb.pass.file} -w ${cert.pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
PKCS12 형식의 인증서를 NSS 인증 데이터베이스 토큰 모듈로 가져옵니다.
pk12util -i ${cert.pkcs12.file} -h ${token.name} -k ${certdb.pass.file} -w ${cert.pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
인증서를 NSS 인증서 데이터베이스에서 PKCS12 형식으로 내보냅니다.
pk12util -o -n ${cert.nickname} -k ${pass.file} -w${cert.pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
인증서를 NSS 인증서 데이터베이스 토큰 모듈에서 PKCS12 형식(하드웨어 가속기 구성에 유용)으로 내보냅니다.
pk12util -o -n ${cert.nickname} -h ${token.name} -k ${pass.file} -w ${cert.pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
PKCS12 인증서를 Java 소스를 필요로 하는 JKS 형식으로 변환합니다.
<target name="convert-pkcs12-to-jks" depends="init-common"> <delete file="${jks.file}" failonerror="false"/> <java classname="com.sun.enterprise.security.KeyTool"> <arg line="-pkcs12"/> <arg line="-pkcsFile ${pkcs12.file}"/> <arg line="-pkcsKeyStorePass ${pkcs12.pass}"/> <arg line="-pkcsKeyPass ${pkcs12.pass}"/> <arg line="-jksFile ${jks.file}"/> <arg line="-jksKeyStorePass ${jks.pass}"/> <classpath> <pathelement path="${s1as.classpath}"/> <pathelement path="${env.JAVA_HOME}/jre/lib/jsse.jar"/> </classpath> </java> </target>
보안 모듈 데이터베이스 도구인 modutil은 secmod.db 파일이나 하드웨어 토큰 내에서 PKCS #11(Cryptographic Token Interface Standard, 암호화 토큰 인터페이스 표준) 모듈 정보를 관리하는 명령줄 유틸리티입니다. 이 도구를 사용하여 PKCS #11 모듈을 추가 및 삭제하고, 비밀번호를 변경하며 기본값을 설정하고, 모듈 내용을 나열하고 슬롯을 활성화하거나 비활성화하며, FIPS-140-1 호환을 활성화하거나 비활성화하고 기본 공급자를 암호화 작업에 할당할 수 있습니다. 이 도구는 key3.db, cert7.db 및 secmod.db 보안 데이터베이스 파일도 만들 수 있습니다. 이 도구에 대한 자세한 내용은 http://www.mozilla.org/projects/security/pki/nss/tools/modutil.html을 참조하십시오.
새 PKCS11 모듈이나 토큰을 추가합니다.
modutil -add ${token.module.name} -nocertdb -force -mechanisms RSA:DSA:RC4:DES -libfile ${SCA.lib.path} -dbdir ${admin.domain.dir}/${admin.domain}/config |
NSS 저장소에서 PKCS11 모듈을 삭제합니다.
modutil -delete ${token.module.name} -nocertdb -force -mechanisms RSA:DSA:RC4:DES -libfile ${SCA.lib.path} -dbdir ${admin.domain.dir}/${admin.domain}/config |
NSS 저장소의 사용 가능한 토큰 모듈을 나열합니다.
modutil -list -dbdir ${admin.domain.dir}/${admin.domain}/config |
하드웨어 가속기 토큰을 사용하면 암호화 성능을 향상시킬 수 있으며 보안 키 저장소 기능을 제공할 수 있습니다. 또한, 스마트 카드를 통해 최종 사용자에게 이동식 보안 키 저장소를 제공할 수도 있습니다.
Sun Java System Application Server 8.1 및 8.2 Standard Edition 또는 Enterprise Edition은 Java 2 Platform, Standard Edition(J2SE 플랫폼) 5.0에서 실행되는 경우, SSL 또는 TLS 통신에 대한 PKCS#11 토큰 사용 및 키와 PKCS#11 토큰을 관리하는 데 필요한 NSS(Network Security Services) 도구를 지원합니다. 이 절에서는 Application Server가 해당 지원을 제공하는 방법에 대해 설명하며 관련 구성에 대한 절차를 안내합니다.
J2SE 5.0 PKCS#11 공급자는 Application Server 런타임과 쉽게 통합할 수 있습니다. 이 공급자를 통해 Application Server에서 하드웨어 가속기 및 다른 PKCS#11 토큰을 사용함으로써 빠른 성능을 얻을 수 있으며 SSL 또는 TLS 통신의 고유 개인 키를 보호할 수 있습니다.
이 절은 다음 내용으로 구성되어 있습니다.
Sun Java System Application Server 8.1 및 8.2 Standard Edition 또는 Enterprise Edition은 Sun Crypto Accelerator 1000(SCA-1000) 및 SCA-4000 테스트를 거쳤습니다.
Application Server는 J2SE 5.0과 함께 사용하는 경우 PKCS#11 토큰과 통신할 수 있습니다. NSS PKCS#11 토큰 라이브러리(NSS 내부 PKCS#11 모듈의 경우 일반적으로 NSS 소프트 토큰으로 알려져 있음) 및 NSS 명령줄 관리 도구는 Application Server에 패키지화되어 있습니다. 자세한 내용은 NSS(Network Security Services) 도구 사용을 참조하십시오.
런타임 시 토큰 키와 인증서에 액세스할 수 있도록 NSS 도구를 사용하여 PKCS#11 토큰 및 J2SE PKCS#11 공급자에 키와 인증서를 만듭니다. PKCS#11 공급자는 원시 PKCS#11 라이브러리에 대한 래퍼 역할을 하는 암호화 서비스 공급자입니다. PKCS#11 토큰은 일반적으로 원시 PKCS#11 인터페이스를 가진 모든 하드웨어 및 소프트웨어 토큰을 나타냅니다. 하드웨어 토큰은 하드웨어 가속기 및 스마트 카드와 같은 물리적 장치에서 구현되는 PKCS#11 토큰입니다. 소프트웨어 토큰은 전적으로 소프트웨어에서 구현되는 PKCS#11 토큰입니다.
J2SE 1.4.x 플랫폼에서 Application Server를 실행하면 하나의 PKCS#11 토큰(NSS 소프트 토큰)만 지원됩니다.
Microsoft Windows 환경의 경우, NSS 라이브러리 AS_NSS의 위치와 NSS 도구 디렉토리 AS_NSS_BIN의 위치를 PATH 환경 변수에 추가합니다. 작업상 편의를 위해 이 절의 절차에서는 UNIX 명령만 사용합니다. 적절한 위치에서 UNIX 변수를 Windows 변수로 바꿔야 합니다.
하드웨어 암호화 가속기를 구성하려면 다음의 두 가지 주요 절차를 수행합니다.
이 절에서는 NSS 보안 도구 modutil을 사용하여 PKCS#11 토큰을 구성하는 방법에 대해 설명합니다. 다음 절차를 사용하여 PKCS#11 토큰을 구성합니다.
다음 명령을 모두 한 줄로 입력합니다.
modutil -dbdir AS_NSS_DB -nocertdb -force -add moduleName -libfile absolute_path_of_pkcs11_library -mechanisms list_of_security_mechanisms
여기서, AS_NSS_DB는 NSS 데이터베이스 디렉토리입니다(DAS(Domain Administration Server)를 사용하는 경우 AS_DOMAIN_CONFIG와 동일함).
예를 들어, 하드웨어 가속기 토큰을 구성하려면 다음을 모두 한 줄로 입력합니다.
modutil -dbdir AS_NSS_DB -nocertdb -force -add "Sun Crypto Accelerator" -libfile /opt/SUNWconn/crypto/lib/libpkcs11.so -mechanisms RSA:DSA:RC4:DES
이 예에서 하드웨어 가속기는 SCA–1000 암호화 가속기입니다. 해당 PKCS#11 라이브러리는 기본적으로 /opt/SUNWconn/crypto/lib/libpkcs11.so에 있습니다.
mechanisms는 해당 토큰에 사용할 수 있는 암호화 메커니즘에 대한 전체 목록이어야 합니다. 몇 개의 암호화 메커니즘만 사용하려면 J2SE 5.0 PKCS#11 공급자 구성을 참조하십시오. 지원되는 모든 메커니즘 목록을 보려면 NSS 보안 도구 사이트(http://www.mozilla.org/projects/security/pki/nss/tools)의 modutil 설명서를 참조하십시오.
다음 예에서는 토큰 설치 시 지정한 토큰 이름이 mytoken이라고 가정합니다.
하드웨어 가속기가 제대로 구성되었는지 확인하려면 다음 명령을 입력합니다.
modutil -list -dbdir AS_NSS_DB
표준 출력은 다음과 유사합니다.
Using database directory /var/opt/SUNWappserver/domains/domain1/config ... Listing of PKCS#11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS#11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. Sun Crypto Accelerator library name: /opt/SUNWconn/crypto/lib/libpkcs11.so slots: 1 slot attached status: loaded slot: Sun Crypto Accelerator:mytoken token: mytoken ----------------------------------------------------------- |
이 절에서는 certutil 및 pk12util을 사용하여 키 및 인증서를 만들고 관리하는 몇 가지 일반 절차에 대해 설명합니다. certutil 및 pk12util에 대한 자세한 내용은 NSS(Network Security Services) 도구 사용 및 NSS 보안 도구 사이트(http://www.mozilla.org/projects/security/pki/nss/tools)의 설명서를 참조하십시오.
또한 java.security 등록 정보 파일(Java 런타임의 JAVA_HOME/jre/lib/security 디렉토리에 있음)에 PKCS#11 공급자를 구성하면 J2SE keytool 유틸리티를 사용하여 키와 인증서를 관리할 수 있습니다. keytool 사용에 대한 자세한 내용은 http://java.sun.com/j2se/1.5.0/docs/guide/secuirty/p11guide.html의 Java PKCS#11 Reference Guide를 참조하십시오.
이 절은 다음 내용으로 구성되어 있습니다.
구성된 PKCS#11 토큰의 키와 인증서를 나열하려면 다음 명령을 실행합니다.
certutil -L -d AS_NSS_DB [-h tokenname]
예를 들어, 기본 NSS 소프트 토큰의 내용을 나열하려면 다음을 입력합니다.
certutil -L -d AS_NSS_DB
표준 출력은 다음과 유사합니다.
verisignc1g1 T,c,c verisignc1g2 T,c,c verisignc1g3 T,c,c verisignc2g3 T,c,c verisignsecureserver T,c,c verisignc2g1 T,c,c verisignc2g2 T,c,c verisignc3g1 T,c,c verisignc3g2 T,c,c verisignc3g3 T,c,c s1as u,u,u |
출력의 왼쪽 열에는 토큰의 이름이 표시되고 오른쪽 열에는 세 가지 트러스트 속성 집합이 표시됩니다. Application Server 인증서의 경우 대부분 T,c,c로 출력됩니다. 한 가지 수준의 트러스트만 포함된 J2SE java.security.KeyStore API와는 달리, NSS 기술에는 여러 수준의 트러스트가 포함되어 있습니다. Application Server는 기본적으로 이 토큰이 SSL을 사용하는 방법을 설명하는 첫 번째 트러스트 속성을 사용합니다. 이 속성에 대한 설명은 다음과 같습니다.
T는 클라이언트 인증서 발급을 위한 인증 기관(CA)이 트러스트되었음을 나타냅니다. |
u는 인증서(및 키)를 인증 또는 서명에 사용할 수 있음을 나타냅니다. |
u,u,u 속성 조합은 개인 키가 데이터베이스에 있음을 나타냅니다. |
하드웨어 토큰 mytoken의 내용을 나열하려면 다음 명령을 실행합니다.
certutil -L -d AS_NSS_DB -h mytoken
하드웨어 토큰의 비밀번호를 입력하라는 메시지가 표시됩니다. 표준 출력은 다음과 유사합니다.
Enter Password or Pin for "mytoken": mytoken:Server-Cert 	u,u,u |
certutil을 사용하여 자체 서명된 인증서를 만들고 인증서를 가져오거나 내보냅니다. 개인 키를 가져오거나 내보내려면 pk12util 유틸리티를 사용합니다. 자세한 내용은 NSS(Network Security Services) 도구 사용을 참조하십시오.
Application Server에서 NSS 도구 certutil 및 modutil을 사용하여 NSS 비밀번호를 직접 수정하지 마십시오. NSS 비밀번호를 직접 수정하면 Application Server의 보안 데이터가 손상될 수 있습니다.
Application Server는 J2SE PKCS#11 공급자를 사용하여 런타임 시 PKCS#11 토큰에 있는 키 및 인증서에 액세스합니다. 기본적으로 Application Server는 NSS 소프트 토큰에 J2SE PKCS#11 공급자를 구성합니다. 이 절에서는 J2SE PKCS#11 공급자의 기본 구성을 대체하는 방법에 대해 설명합니다.
Application Server에서 각 PKCS#11 토큰에 다음과 같은 기본 PKCS#11 구성 매개 변수가 생성됩니다.
기본 NSS 소프트 토큰에 대한 구성:
name=internal library=${com.sun.enterprise.nss.softokenLib} nssArgs="configdir='${com.sun.appserv.nss.db}' certPrefix='' keyPrefix='' secmod='secmod.db'" slot=2 omitInitialize = true |
SCA 1000 하드웨어 가속기에 대한 구성:
name=HW1000 library=/opt/SUNWconn/crypto/lib/libpkcs11.so slotListIndex=0 omitInitialize=true |
이 구성은 Java PKCS#11 Reference Guide에 설명된 구문을 준수합니다.
이름 매개 변수는 고유해야 하며, 이외의 다른 요구 사항은 없습니다. J2SE 5.0과 같은 이전의 특정 버전은 영숫자 문자만 지원합니다.
사용자 정의 구성 파일을 만들어 기본 구성 매개 변수를 대체할 수 있습니다. 예를 들어, SCA–1000의 RSA 암호화 및 RSA 키 쌍 생성기를 명시적으로 비활성화할 수 있습니다. RSA 암호화 및 RSA 키 쌍 생성기를 비활성화하는 방법에 대한 자세한 내용은 http://www.mozilla.org/projects/security/pki/nss/tools를 참조하십시오.
사용자 정의 구성 파일을 만들려면 다음을 수행합니다.
다음 코드를 사용하여 install-dir/mypkcs11.cfg라는 구성 파일을 만들고 저장합니다.
name=HW1000 library=/opt/SUNWconn/crypto/lib/libpkcs11.so slotListIndex=0 disabledMechanisms = { 	CKM_RSA_PKCS 	CKM_RSA_PKCS_KEY_PAIR_GEN } omitInitialize=true |
필요한 경우 NSS 데이터베이스를 업데이트합니다. 여기서는 RSA를 비활성화하기 위해 NSS 데이터베이스를 업데이트합니다.
다음 명령을 실행합니다.
modutil -undefault "Sun Crypto Accelerator" -dbdir AS_NSS_DB -mechanisms RSA |
mechanisms 목록의 알고리즘 이름은 기본 구성의 알고리즘 이름과 다릅니다. NSS의 유효한 mechanisms 목록을 보려면 NSS 보안 도구 사이트(http://www.mozilla.org/projects/security/pki/nss/tools)의 modutil 설명서를 참조하십시오.
다음과 같이 등록 정보를 해당 위치에 추가하여 서버에 이 변경 사항을 업데이트합니다.
<property name="mytoken" value="&InstallDir;/mypkcs11.cfg"/> |
등록 정보의 위치는 다음 중 하나일 수 있습니다.
공급자가 DAS 또는 서버 인스턴스용인 경우, 연관된 <security-service> 아래에 등록 정보를 추가합니다.
공급자가 노드 에이전트용인 경우, domain.xml 파일에서 연관된 <node-agent> 요소 아래에 등록 정보를 추가합니다.
Application Server를 다시 시작합니다.
사용자 정의한 구성을 적용하려면 서버를 다시 시작합니다.