|
항목 바로가기: |
|
*SSL은 무엇이며 어떻게 작동합니까? |
|
*PKC는 무엇이며 어떻게 작동합니까? 공개 키 암호화는 대칭 키 암호화의 일부 단점들을 보완합니다. 공개 키 암호화에서 개인 또는 조직은 공개 키와 개인 키라는 두 개의 상호보완적인 키를 사용합니다. 개인 키를 사용하여 암호화된 모든 정보는 공개 키를 사용해야만 암호를 해독할 수 있습니다. 마찬가지로 공개 키를 사용하여 암호화된 모든 정보는 개인 키를 사용해야만 암호를 해독할 수 있습니다. 예를 들면 다음과 같습니다. 1. Bob에게 두 개의 보완 키가 있습니다. 공개 키 암호화에서 Alice가 비밀 메시지를 Bob에게 보내려면 Bob의 공개 키 사본이 있어야 합니다. 그러나, 이렇게 하려면 우선 Alice는 공개 키가 Bob의 것인지 확인해야 합니다. |
|
*인증서란 무엇입니까? SSL 인증서는 인증 기관(CA)이라는 신뢰할 수 있는 외부 업체에서 발급합니다. CA는 여권 발급 기관과 같은 역할을 수행합니다. CA는 일련의 절차를 통해 ID 발급 대상의 신원을 분명히 해야 합니다. 조직의 신원을 분명히 한 후에 CA는 해당 조직의 공개 키가 들어 있는 인증서를 발급하고 CA의 개인 키로 인증서에 서명합니다. SSL 인증서를 사용하면 여러분의 사이트에서 인증되고 암호화된 온라인 상거래를 수행할 수 있습니다. 여러분의 사이트를 방문하는 사람들은 자신들이 여러분과 직접 상거래를 하고 있으며 자신들이 보내는 정보를 정해진 사람 이외의 다른 사람들이 가로채거나 암호를 해독할 수 없다는 확신을 갖고 신용 카드 번호나 기타 개인 정보를 보낼 수 있게 됩니다. SSL 인증서에는 다음과 같은 정보가 포함됩니다.
|
|
*인증 기관이란 무엇입니까? *VeriSign, Inc. About Digital IDs FAQ's. n.d. <https://digitalid.s-trust.de/secure/server/about/aboutFAQ.htm> (2004년 5월 19일). |
|
*SSL 핸드셰이크란 무엇입니까? 클라이언트에서 ClientHello 메시지를 서버로 보내면 서버는 ServerHello 메시지로 응답해야 합니다. 그외의 경우에는 심각한 오류가 발생하여 연결이 끊어질 수 있습니다. client hello 및 server hello를 사용하여 클라이언트와 서버간에 향상된 보안 기능을 설정합니다. client hello 및 server hello를 통해 프로토콜 버전, 세션 ID, 암호 그룹 및 압축 방법과 같은 특성이 설정됩니다. 서버는 hello 메시지를 보낸 후 인증이 필요한 경우 인증서를 보냅니다. 서버가 인증되면 선택한 암호 그룹에 해당되는 경우 클라이언트 인증을 위해 클라이언트로부터 인증서(CertificateRequest)를 요청합니다(선택적 양방향). 이제 서버는 핸드셰이크의 hello 메시지 단계가 완료되었음을 알리는 ServerHelloDone 메시지를 보냅니다. 그런 다음 서버는 클라이언트로부터의 응답을 기다립니다. 서버에서 CertificateRequest 메시지를 보낸 경우 클라이언트는 인증서 메시지를 인증서 없음 경고를 보냅니다(선택적 양방향). 이제 ClientKeyExchange 메시지가 전송됩니다. 이 메시지의 내용은 ClientHello 및 ServerHello간에 선택된 공개 키 알고리즘에 따라 달라집니다. 클라이언트에서 서명 기능이 포함된 인증서를 보낸 경우 디지털 방식으로 서명된 CertificateVerify 메시지가 전달되어 인증서가 명시적으로 검증됩니다. 이 시점에서 클라이언트는 ChangeCipherSpec 메시지를 보내며 보류 중인 암호 사양의 사본을 현재 암호 사양으로 복사합니다. 클라이언트는 새 알고리즘, 키 및 보안 상태에서 즉시 Finished 메시지를 보냅니다. 이에 대한 응답으로 서버는 자신의 ChangeCipherSpec 메시지를 보내고 보류 중인 암호 사양을 현재 사양으로 전송하고 새 암호 사양에서 자신의 Finished 메시지를 보냅니다. 이 시점에서 핸드셰이크가 완료되고 클라이언트와 서버는 응용 프로그램 계층 데이터를 교환하기 시작합니다. (아래 순서도 참조) |
|
인증서 형식
PEM -----BEGIN CERTIFICATE-----
|
|
데모 인증서 생성
1단계 - 데모 개인 키 만들기
keytool(jdk에서 사용) Usage; keytool -genkey [-v] [-alias <alias>] [-keyalg <keyalg>] keytool -genkey -keyalg RSA -alias mykey -keystore mykeystore.jks Enter key password for <mykey> 이 결과 mykeystore.jks 파일이 생성됩니다. 이 파일에는 개인 키 및 자체 서명된 공개 키가 있습니다. keytool 사용에 관한 자세한 내용은 Keytool 설명서를 참조하십시오. WebLogic의 인증서 서블릿(7.0까지만 지원됨) http://hostname:port/certificate
2단계 - 신뢰할 수 있는 CA에서 공개 키 서명 다음 단계는 인증된 CA로부터 공개 키 서명을 받는 것입니다. CSR(Cert Signature Request)을 검색한 후 이를 인증 기관에 보냄으로써 서명을 받을 수 있습니다. keytool -certreq -keystore demokeystore -----BEGIN NEW CERTIFICATE REQUEST----- 위 코드를 모두(BEGIN NEW CERTIFICATE REQUEST 및 END NEW CERTIFICATE REQUEST 포함) 인증 기관에 복사하여 붙여넣습니다. 다음 예제는 theVerisign CA를 사용합니다.
CA 루트를 keystore에 저장합니다. 중간 CA가 있는 경우 이 중간 CA를 CA 루트 뒤에 입력해야 합니다. keytool -import -alias verisignCA -file CA.pem -keystore mykeystore -trustcacerts
keytool -import -alias verisignIntermediateCA -file IntermediateCA.pem -keystore mykeystore -trustcacerts
keytool -import -alias mykey -file public.pem -keystore mykeystore -trustcacerts |
|
인증서 형식 변환 OpenSSL은 keytool과 유사한 기능이 있는 개방형 소프트웨어 도구입니다. http://www.openssl.org/contrib/ssl.ca-0.1.tar.gz에서 OpenSSL을 다운로드하십시오. PEM에서 PKCS#12(Netscape, IE 등)로 openssl pkcs12 -export -in pem-certificate-and-key-file -out pkcs-12-certificate-and-key-file
openssl pkcs12 -export -in pem-certificate-file -inkey pem-key-file -out pkcs-12-certificate-and-key-file
PKCS#12에서 PEM으로
openssl pkcs12 .in keyexport.pfx .nocerts .nodes .out keyexport.prv
openssl pkcs12 .in keyexport.pfx .nokeys .out keyexport.pub
openssl rsa -inform PEM|DER -outform DER|PEM -in pem-file|der-file -out der-file|pem-file
-----BEGIN CERTIFICATE----- ...ascii stuff.... -----END CERTIFICATE----- 참고: DER 키는 ascii 형식이므로 해독하기 어렵습니다. |
|
인증서 검토 개인 키:openssl -rsa -inform DER -in demokey.der -text
공개 키, 인증 기관: openssl -x509 -inform PEM -in democert.pem -text
Keystore: Keystore type: jks Your keystore contains 1 entry Alias name: mykey ******************************************* 기타 명령: pkcs12 파일에서 개인 키를 추출합니다. openssl pkcs12 .in keyexport.pfx .nocerts .nodes .out keyexport.prv
pkcs12 파일에서 공개 키를 추출합니다. openssl pkcs12 .in keyexport.pfx .nokeys .out keyexport.pub
자세한 내용은 http://www.techonline.com/community/ed_resource/feature_article/14364를 참조하십시오. |
|
keystore를 사용하도록 WLS 구성(단방향 SSL에만 해당) Custom Identity and Custom Trust Custom Identity Custom Identity Key Store File Name: mykeystore Custom Identity Key Store Type: jks Custom Identity Key Store Pass Phrase: password Confirm Custom Identity Key Store Pass Phrase: password Custom Trust Custom Trust Key Store File Name: mykeystore Custom Trust Key Store Type: jks Custom Trust Key Store Pass Phrase: password Confirm Custom Trust Key Store Pass Phrase: password Private Key Alias: mykey
Passphrase: password Confirm Passphrase: password
|
| <19 dUc. 2003 10 h 39 CET> <Debug> <TLS> <000000> <SSLManager.getServerCertifica te()> <19 dUc. 2003 10 h 39 CET> <Notice> <Security> <BEA-090171> <Loading the identity certificate stored under the alias mykey from the jks keystore file D:\_Wk\supportpattern\mydomain\demokeystore.> <19 dUc. 2003 10 h 39 CET> <Notice> <WebLogicServer> <BEA-000298> <Certificate expires in 14 days: [ [ Version: V3 Subject: CN=CertServer, OU=BEASystems, O=BEA, L=Paris, ST=Florida, C=FR Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@1bf Validity: [From: Fri Dec 19 01:00:00 CET 2003, To: Sat Jan 03 00:59:59 CET 2004] Issuer: OU=For VeriSign authorized testing only. No assurances (C)VS1997, OU=www.verisign.com/repository/TestCPS Incorp. By Ref. Liab. LTD., O="VeriSign, Inc" SerialNumber: [ 0ed7bf9a 778fd148 175bac0b e1d3627d] Certificate Extensions: 5 [1]: ObjectId: 2.5.29.31 Criticality=false Extension unknown: DER encoded OCTET string = 0000: 04 3B 30 39 30 37 A0 35 A0 33 86 31 68 74 74 70 .;0907.5.3.1http 0010: 3A 2F 2F 63 72 6C 2E 76 65 72 69 73 69 67 6E 2E ://crl.verisign. 0020: 63 6F 6D 2F 53 65 63 75 72 65 53 65 72 76 65 72 com/SecureServer 0030: 54 65 73 74 69 6E 67 43 41 2E 63 72 6C TestingCA.crl [2]: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ [1.3.6.1.5.5.7.3.1, 1.3.6.1.5.5.7.3.2]] [3]: ObjectId: 2.5.29.32 Criticality=false CertificatePolicies [ [CertificatePolicyId: [2.16.840.1.113733.1.7.21] [PolicyQualifierInfo: [ qualifierID: 1.3.6.1.5.5.7.2.1 qualifier: 0000: 16 2A 68 74 74 70 3A 2F 2F 77 77 77 2E 76 65 72 .*http://www.ver isign.com/repository/TestCPS 0010: 69 73 69 67 6E 2E 63 6F 6D 2F 72 65 70 6F 73 69 0020: 74 6F 72 79 2F 54 65 73 74 43 50 53 ]] ] ] [4]: ObjectId: 2.5.29.15 Criticality=false KeyUsage [ DigitalSignature Key_Encipherment ] [5]: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:false PathLen: undefined ] ] Algorithm: [SHA1withRSA] Signature: 0000: 08 3A F5 EC EE 10 AD 9C 3C D7 94 5A 84 9C 34 F2 .:......<..Z..4. 0010: 61 70 30 45 AF 99 03 79 AF 47 D9 A0 62 20 A6 D3 ap0E...y.G..b .. 0020: C1 21 98 59 A3 3D 6D 8F E9 58 71 CE 87 FE AB 8A .!.Y.=m..Xq..... 0030: 99 D8 F5 71 DE 44 55 2E BB EB 86 15 C0 31 BF 25 ...q.DU......1.% ]> <19 dUc. 2003 10 h 39 CET> <Info> <WebLogicServer> <BEA-000307> <Exportable key maximum lifespan set to 500 uses.> <19 dUc. 2003 10 h 39 CET> <Info> <WebLogicServer> <BEA-000308> <Using full strength (domestic) SSL.> <19 dUc. 2003 10 h 39 CET> <Notice> <Security> <BEA-090169> <Loading trusted certificates from the jks keystore file D:\_Wk\supportpattern\mydomain\demokeystore.> <19 dUc. 2003 10 h 39 CET> <Debug> <TLS> <000000> <Trusted CA: [ [ Version: V1 Subject: OU=For VeriSign authorized testing only. No assurances (C)VS1997, OU=www.verisign.com/repository/TestCPS Incorp. By Ref. Liab. LTD., O="VeriSign, Inc" Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4 Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@166 Validity: [From: Sun Jun 07 02:00:00 CEST 1998, To: Wed Jun 07 01:59:59 CEST 2006] Issuer: OU=For VeriSign authorized testing only. No assurances (C)VS1997, OU=www.verisign.com/repository/TestCPS Incorp. By Ref. Liab. LTD., O="VeriSign, Inc" SerialNumber: [ 52a9f424 da674c9d af4f5378 52abef6e] ] Algorithm: [MD5withRSA] Signature: 0000: A5 A7 47 F2 8F 37 10 A0 96 94 CF E6 7C DB A3 E4 ..G..7.......... 0010: 02 22 49 AC 08 F8 D3 08 C9 EF 9B B2 9C C0 32 60 ."I...........2` 0020: B9 A1 30 92 88 B5 80 14 98 F5 B8 89 A7 DA 0A F9 ..0............. 0030: CB F5 62 7D CA B9 53 3E 62 9B 5C 59 72 DF C7 12 ..b...S>b.\Yr... ]> <19 dUc. 2003 10 h 39 CET> <Debug> <TLS> <000000> <SSLManager: loaded 1 trusted CAs from D:\_Wk\supportpattern\mydomain\demokeystore> <19 dUc. 2003 10 h 39 CET> <Info> <WebLogicServer> <BEA-000307> <Exportable key maximum lifespan set to 500 uses.> <19 dUc. 2003 10 h 39 CET> <Info> <WebLogicServer> <BEA-000300> <Certificate contents: 2 certificate(s): fingerprint = 68dd50d604d078d8da79c2b93a6d9886, not before = Fri Dec 19 01:00:00 CET 2003, not after = Sat Jan 03 00:59:59 CET 2004, holder = C=FR SP=Florida L=Paris O=BEA OU=BEASystems CN=CertServer , issuer = O=VeriSign, Inc OU=For Veri Sign authorized testing only. No assurances (C)VS1997 , key = modulus length=12 9 exponent length=3 fingerprint = 40065311fdb33e880a6f7dd14e229187, not before = Sun Jun 07 02:00: 00 CEST 1998, not after = Wed Jun 07 01:59:59 CEST 2006, holder = O=VeriSign, Inc OU=For VeriSign authorized testing only. No assurances (C)VS1997 , issuer = O=VeriSign, Inc OU=For VeriSign authorized testing only. No assurances (C)VS1997 , key = modulus length=65 exponent length=3> <19 dUc. 2003 10 h 39 CET> <Notice> <WebLogicServer> <BEA-000355> <Thread "SSLListenThread.Default" listening on port 7002, ip address *.*> |
작업이 완료되었습니다. 단방향 SSL(클라이언트 인증 없음)을 수행하도록 WebLogic을 구성했습니다.
|
문제 해결어느 한 쪽의 SSL 구성이나 SSL 통신에 사용되는 인증서나 사용 중인 SSL 소프트웨어에서 문제가 발생할 수 있습니다. 우선 어느 쪽에서 어떤 SSL 오류가 발생했는지 정확히 파악해야 합니다. SSL 문제를 진단하려면 Java 명령줄에 다음 명령을 추가합니다.
-Dweblogic.security.SSL.debugEaten=true 플래그도 서버에 추가할 수 있습니다. 그러나 내용이 너무 복잡해질 수도 있으므로 최후에 추가하는 것이 좋습니다. config.xml에서 DebugSSL="true", <ServerDebug DebugSSL="true' Name="myserver"/>
및 Server Mbean에서 StdoutDebugEnabled="true" StdoutSeverityLevel="64"를 추가할 수 있습니다. |
|
2. 핸드셰이크는 정확히 어떤 형태입니까? 참고: 자세한 내용은 SSL 핸드셰이크란 무엇입니까?를 참조하십시오. 첫 번째 SSL 핸드셰이크 |
서버쪽
type mylogserver | grep "HANDSHAKEMESSAGE"
| <18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientHelloV2> <18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientKeyExchange> <18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientKeyExchange RSA> <18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Finished> |
type mylogserver | grep "CHANGE_CIPHER_SPEC"
| <18 d?c. 2003 13 h 26 CET> <Debug> <TLS> <000000> <write CHANGE_CIPHER_SPEC offset = 0 length = 1> |
클라이언트쪽
type mylogclient | grep ""HANDSHAKEMESSAGE"
| <18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHello> <18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Certificate> <18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHelloDone> <18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Finished> |
세션을 다시 시작하는 SSL
핸드셰이크가 두 번째 요청에서 세션을 다시 시작할 때 발생합니다.
그림 제공: FreeSSL.com. SSL Jargon Buster!. n.d.<http://www.freessl.com/ssl-certificate/ssl-terms.html> (2004년 5월 19일).
서버쪽
type mylogserver | grep "HANDSHAKEMESSAGE"
|
<18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientHelloV2> |
type mylogserver | grep "CHANGE_CIPHER_SPEC"
| <18 dUc. 2003 13 h 27 CET> <Debug> <TLS> <000000> <write CHANGE_CIPHER_SPEC offset = 0 length = 1> <18 dUc. 2003 13 h 27 CET> <Debug> <TLS> <000000> <126795 received CHANGE_CIPHER_SPEC> |
클라이언트쪽
type mylogclient | grep ""HANDSHAKEMESSAGE"
|
<18 dec. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHello> |
핸드셰이크에서 클라이언트 인증 수행(양방향 SSL)핸드셰이크에서 클라이언트 인증을 수행할 때 발생합니다(양방향 SSL).
그림 제공: FreeSSL.com. SSL Jargon Buster!. n.d.<http://www.freessl.com/ssl-certificate/ssl-terms.html> (2004년 5월 19일).
서버쪽
type mylogserver | grep "HANDSHAKEMESSAGE"
|
<19 dec. 2003 11 h 07 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientHello> |
클라이언트쪽
type mylogclient | grep ""HANDSHAKEMESSAGE"
|
>type mylogclient | grep ""HANDSHAKEMESSAGE" |
type mylogclient | grep "CHANGE_CIPHER_SPEC"
| <23 dec. 2003 15 h 59 CET> <Debug> <TLS> <000000> <write CHANGE_CIPHER_SPEC offs |
|
3. 로그 분석 - 오류 파악 |
|
일반 인증서 openssl x509 -in ca.pem -text |
|
Certificate: |
|
해결 방법 |
호스트 이름 유효성 검사 실패
클라이언트쪽
| [Security:090504]Certificate chain received from localhost - 127.0.0.1 failed hostname verification check. Certificate contained CertServer but check expected localhost javax.net.ssl.SSLKeyException: [Security:090504]Certificate chain received from localhost - 127.0.0.1 failed hostname verification check. Certificate contained CertServer but check expected localhost at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireException(Unknown Source) at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireAlertSent(Unknown Source) at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown Source).. |
|
해결 방법 -Dweblogic.security.SSL.hostnameVerifier=examples.security.sslclient. NulledHostnameVerifier NulledHostnameVerifier는 WLS의 예제에 포함되어 있습니다. |
CERT_CHAIN_UNTRUSTED
클라이언트쪽
| <23 dec. 2003 15 h 26 CET> <Warning> <Security> <BEA-090542> <Certificate chain received from localhost - 127.0.0.1 was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify -Dweblogic.security.TrustKeyStore=DemoTrust on the command line for this client.> <23 dUc. 2003 15 h 31 CET> <Debug> <TLS> <000000> <Validation error = 16> <23 dUc. 2003 15 h 31 CET> <Debug> <TLS> <000000> <Certificate chain is untrusted> <23 dUc. 2003 15 h 31 CET> <Debug> <TLS> <000000> <SSLTrustValidator returns: 16> <23 dUc. 2003 15 h 31 CET> <Debug> <TLS> <000000> <Trust status (16): CERT_CHAIN_UNTRUSTED> |
|
해결 방법 -Dweblogic.security.TrustKeyStore=CustomTrust 서버에서 보내는 모든 신뢰할 수 있는 CA(공개 키의 CA)를 함께 추가합니다. 또는 -Dweblogic.security.SSL.trustedCAKeyStore=<your keystore> SSL 핸드셰이크를 시도하기 전에 클라이언트(또는 서버가 SSL 클라이언트로 동작하는 경우의 서버)는 부팅 시에 로드한 신뢰할 수 있는 인증서를 로그에 표시합니다. 이 로그는 다음과 같습니다. |
|
<Mar 22, 2004 11:54:43 AM EST> <Debug> <TLS> <000000> <SSLManager, getting trusted CAs from default key store: /web/bea/weblogic700/server/lib/cacerts> |
SSL 핸드셰이크 동안 서버에서 인증서를 보내는 경우 로그는 다음과 같습니다.
|
<Mar 22, 2004 11:54:43 AM EST> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHello> |
두 목록을 비교하여 누락된 인증서와 누락된 원인을 파악하십시오. 다음은 몇 가지 예상되는 경우입니다.
- 인증서를 신뢰할 수 있지만 만료되었습니다.
- 클라이언트에서 cacerts 인증서를 로드하지 않습니다.
- 서버에서 자체 서명 인증서를 사용하는 경우 클라이언트가 신뢰하도록 구성해야 합니다.
BAD_CERTIFICATE(서명이 잘못되어 SSL 핸드셰이크 오류 발생)
클라이언트쪽
|
<23 dUc. 2003 15 h 36 CET> <Debug> <TLS> <000000> <Alert received from peer, notifying peer we received it: com.certicom.tls.record.alert.Alert@1b34126> |
서버쪽
|
<23 dUc. 2003 15 h 38 CET> <Warning> <Security> <BEA-090478> <Certificate chain received from 127.0.0.1 - 127.0.0.1 was not signed properly causing SSL handshake failure.> |
|
해결 방법 |
CLOSE_NOTIFY
|
CLOSE_NOTIFY에 대한 경고는 정상적으로 발생할 수 있으므로 추적 기능은 이 경고를 특별하게 취급하지 않습니다. ALERT 심각도 1 유형은 연결이 종료되었음을 나타냅니다. 그러나 핸드셰이크 완료를 나타내기 전에 모든 핸드셰이크 메시지를 확인하십시오. 다음은 예상되는 CLOSE_NOTIFY ALERT의 한 예입니다. |
|
<Jun 18, 2002 7:15:27 AM EDT> <Debug> <TLS> <000000> <NEW ALERT: com.certicom.tls.record.alert.Alert@2241f8 Se |
HANDSHAKE_FAILURE
이 오류는 WebLogic 서버가 원격 Microsoft 서버에 연결할 때 발생할 수 있습니다.
서버쪽
####<18.feb.2004 kl 16.09 CET> <Debug> <TLS> <zkb1b74v> <raitnow-server> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default'> <system> <> <000000> <26572483 received ALERT>
####<18.feb.2004 kl 16.09 CET> <Debug> <TLS> <zkb1b74v> <raitnow-server> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default'> <system> <> <000000> <NEW ALERT: com.certicom.tls.record.alert.Alert@75ca3e Severity: 2 Type: 40
java.lang.Throwable: Stack trace
at weblogic.security.utils.SSLSetup.debug(SSLSetup.java:265)
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)
at com.certicom.tls.record.alert.AlertHandler.handleAlertMessages(Unknown Source)
at com.certicom.tls.record.ReadHandler.interpretContent(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:123)
at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.java:99)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:296)
at java.net.URLConnection.getContent(URLConnection.java:582)
at no.nordea.safe.raitnow.ejb.impl.HTTPSRAConnection.getConnectionReader(HTTPSRAConnection.java:73)
at no.nordea.safe.raitnow.ejb.impl.HTTPRARequester.retrieveResponse(HTTPRARequester.java:211)
at no.nordea.safe.raitnow.ejb.impl.HTTPRARequester.sendRequest(HTTPRARequester.java:138)
at no.nordea.safe.raitnow.ejb.impl.CastorRADataTransformer.order(CastorRADataTransformer.java:199)
at no.nordea.safe.raitnow.ejb.EndUserRegistrationAuthorityBean.order(EndUserRegistrationAuthorityBean.java:98)
at no.nordea.safe.raitnow.ejb.EndUserRegistrationAuthorityBean_mzdjm5_EOImpl.order(EndUserRegistration
AuthorityBean_mzdjm5_EOImpl.java:532)
at no.nordea.safe.raitnow.ejb.EndUserRegistrationAuthorityBean_mzdjm5_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:108)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:353)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
>
####<18.feb.2004 kl 16.09 CET> <Debug> <TLS> <zkb1b74v> <raitnow-server> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default'> <system> <> <000000> <Alert received from peer, notifying peer we received it: com.certicom.tls.record.alert.Alert@75ca3e>
####<18.feb.2004 kl 16.09 CET> <Warning> <Security> <zkb1b74v> <raitnow-server> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default'> <system> <> <BEA-090497> <HANDSHAKE_FAILURE alert received from 193.214.20.203 - 193.214.20.203. Check both sides of the SSL configuration for mismatches in supported ciphers, supported protocol versions, trusted CAs, and hostname verification settings.>
'프로그래밍 > java' 카테고리의 다른 글
| 자바 날짜 가져오기.. (0) | 2009.02.18 |
|---|---|
| [ "==" 과 "equals()" 의 차이점] (0) | 2008.12.09 |
| 자바 정규식 (0) | 2008.08.27 |
| 자바보안과 암호화 (0) | 2007.10.17 |
| 난수발생 (0) | 2007.09.06 |
