问题描述
使用 SSL（安全套接字层）协议的两个通信方因 SSL 失败而无法建立连接。 |
*什么是 SSL 并且其原理如何？
SSL 是安全套接字层 (Secure Sockets Layer) 的缩写。SSL 协议是由 Netscape 开发的，并得到了所有主流 Web 浏览器的支持，例如 Internet Explorer、Netscape、AOL 和 Opera。为使 SSL 发挥作用，必须在 Web 服务器上安装由某个证书颁发机构签发的 SSL 证书。此后才可以将 SSL 用于加密浏览器与 Web 服务器之间的数据传输（保护 SSL 事务）。浏览器通过将 http 改变为 https 并显示一个小锁符号，来指示用 SSL 加密的会话。网站访问者可单击该锁符号来查看 SSL 证书。
*FreeSSL.com. SSL Jargon Buster!. n.d. <http://www.freessl.com/ssl-certificate/ssl-terms.html>（2004 年 5 月 19 日）。
*什么是 PKC 并且其原理如何？
公钥加密 (PKC) 是一种安全交换信息的方法，此方法为涉及事务的个人分配两个互补的密钥（一个公钥，一个私钥）。公钥加密以密码学、消息的数学编码和解码为基础。
公钥加密解决了对称密钥加密的几个缺点。在公钥加密中，个人或组织拥有两个互补密钥：一个称为公钥，一个称为私钥。使用私钥加密的任何信息只能用公钥来解密。反之，使用公钥加密的任何信息只能用私钥来解密。例如：
1. Bob 拥有两个互补密钥
2. 一个密钥加密的内容可用另一个密钥解密
3. Bob 将一个密钥保留为私有（私钥）
4. Bob 将另一个密钥公用（公钥）
5. 如果 Alice 需要给 Bob 发送一条消息
6. Bob 将该公钥的一个副本发送给 Alice
7. Alice 用 Bob 的公钥加密一条消息
8. Bob 用他的私钥对该消息解密
在公钥加密中，如果 Alice 想发送一条秘密消息给 Bob，她必须获得他的公钥的一个副本。但是，在这样做之前，她需要确认该公钥确实属于 Bob。
证书（也称为数字 ID）可以解决这个问题。证书是一个电子文档，它将公钥绑定到特定个人或组织。证书是由一个受信任的第三方（称为证书颁发机构 (CA)）发放的。在发出证书之前，一个优秀的 CA 将执行一系列身份验证过程，以确认 Bob 的真实身份，且该证书中的公钥确实属于 Bob。
*VeriSign, Inc. About Digital IDs FAQ\'s. n.d. < https://digitalid.s-trust.de/secure/server/about/aboutFAQ.htm>（2004 年 5 月 19 日）。
*什么是证书？
从技术上说，SSL 证书（也称为数字证书）将身份与一对可用于加密和签名数字信息的电子密钥绑定。SSL 证书能够实现对某人自称有权使用特定密钥的声明的验证，有助于防止有人使用欺骗性密钥来模拟其他用户。当与加密配合使用时，SSL 证书可提供完整的安全解决方案，可以保证参与事务的一方或各方的身份。
SSL 证书是由受信任的第三方（称为证书颁发机构 (CA)）发放的。CA 的作用有些像护照办理处。CA 必须采取一些措施来确定要向其发放 ID 的人或组织的身份。一旦 CA 建立某个组织的身份后，就可以发出一个包含该组织的公钥的证书，并用 CA 的私钥对其签名。
通过使用 SSL 证书，您就能在自己的站点上开展验证身份的、加密的在线商务活动。访问您站点的用户将可以向站点提交信用卡号或其他个人信息，从而保证他们真心实意与您进行业务交易（并非是骗子），并且他们发送给您的信息不会被目标接收者以外的任何人截取或解密。您的 SSL 证书将包含下列信息：
- 您的组织的公用名称（如 www.bea.com）
- 其它标识性信息（如 IP 和物理地址）
- 您的公钥
- 公钥的到期日期
- 发出此 ID 的 CA 的名称（如 VeriSign）
- 一个唯一的序列号
- VeriSign 的数字签名
*eLiteral.Digital Certificates. n.d. <http://services.eliteral.com/digital-certificate-mumbai/index.php>（2004 年 5 月 19 日）。
*什么是证书颁发机构？
证书颁发机构是一个受信任的第三方，类似于一个护照办理处或经过认证的会计师事务所。证书颁发机构负责发放、废除、续发数字证书，并提供数字证书的目录。证书颁发机构必须遵循严格的过程来验证为其发放证书的个人和组织的身份。所有数字证书都用证书颁发机构的私钥“签名”，从而确保可靠性。证书颁发机构的公钥广泛分发。
*VeriSign, Inc. About Digital IDs FAQ\'s. n.d. < https://digitalid.s-trust.de/secure/server/about/aboutFAQ.htm>（2004 年 5 月 19 日）。
返回页首
*什么是 SSL 握手？
SSL 握手是用于描述浏览器和 Web 服务器建立 SSL 会话的过程的术语。SSL 握手过程包括：浏览器接收 SSL 证书，然后发送“质询”数据给 Web 服务器，以便以密码方式证实该 Web 服务器是否持有与该 SSL 证书关联的 SSL 密钥。如果加密质询是成功的，那么 SSL 握手就已经完成，并且该 Web 服务器将与 Web 浏览器进行 SSL 会话。在 SSL 会话过程中，Web 服务器与 Web 浏览器之间传输的数据将会被加密。
只有在理解握手过程之后，您才能够理解如何排除握手故障。当使用调试选项调试握手时，需要分析每个握手阶段，以便能够确定问题所在。若要理解握手进行的过程，请参考
http://wp.netscape.com/eng/ssl3/3-SPEC.HTM
客户端向服务器发送一条 ClientHello 消息，服务器必须以 ServerHello 消息响应它，否则将会发生致命错误，连接将失败。客户端呼叫和服务器呼叫用于建立客户端和服务器之间的安全增强能力。客户端呼叫和服务器呼叫建立下列属性：协议版本、会话 ID、密码套件以及压缩方法。
在呼叫消息之后，服务器将发送其证书（如果要对服务器进行验证身份）。
如果服务器获得了身份验证，它可能请求客户端鉴别来自客户端的一个证书 (CertificateRequest)，检验其是否适合所选择的密码套件（可选双向）。
现在，服务器将发送 ServerHelloDone 消息，表示握手的呼叫消息阶段已完成。然后服务器将等待客户端响应。
如果服务器已发送了一条 CertificateRequest 消息，客户端必须发送证书消息或无证书提示（可选双向）。现在已发送了 ClientKeyExchange 消息，该消息的内容将依赖于 ClientHello 和 ServerHello 之间选择的公钥算法。如果客户端利用签名功能发送了证书，则发送一个数字签名的 CertificateVerify 消息，以明确验证该证书。
此时，客户端将发送一条 ChangeCipherSpec 消息，并且客户端将未决的密码规范 (Cipher Spec) 复制到当前密码规范中。然后客户端立即用新算法、密钥和密码发送已完成的消息。在响应中，服务器将发送其本身的 ChangeCipherSpec 消息，将未决的密码规范转换为当前密码规范，并用新的密码规范发送其已完成的消息。至此，握手已完成，客户端和服务器可以开始交换应用层数据。（请参阅下面的流程图。）
*FreeSSL.com. SSL Jargon Buster!. n.d. <http://www.freessl.com/ssl-certificate/ssl-terms.html>（2004 年 5 月 19 日）。
证书格式
主要的证书类型有：
PEM
可以包括所有私钥（RSA 和 DSA）、公钥（RSA 和 DSA）和 (x509) 证书。它存储用 Base64 编码的 DER 格式数据，用 ascii 报头包围，因此适合系统之间的文本模式传输。
-----BEGIN CERTIFICATE-----
MIICJjCCAdCgAwIBAgIBITANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFTAT
BgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxIzAhBgNVBAMT
GkRlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5MR4wHAYJKoZIhvcNAQkBFg9zdXBw
b3J0QGJlYS5jb20wHhcNMDAwNTMwMjEzODAxWhcNMDQwNTEzMjEzODAxWjCBjDEL
MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG
cmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzEZMBcGA1UEAxMQd2VibG9n
aWMuYmVhLmNvbTEeMBwGCSqGSIb3DQEJARYPc3VwcG9ydEBiZWEuY29tMFwwDQYJ
KoZIhvcNAQEBBQADSwAwSAJBALdsXEHqKHgs6zj0hU5sXMAUHzoT8kgWXmNkKHXH
79qbPh6EfdlriW9G/AbRF/pKrCQu7hhllAxREbqTuSlf2EMCAwEAATANBgkqhkiG
9w0BAQQFAANBACgmqflL5m5LNeJGpWx9aIoABCiuDcpw1fFyegsqGX7CBhffcruS
1p8h5vkHVbMu1frD1UgGnPlOO/K7Ig/KrsU=
-----END CERTIFICATE-----
DER
辨别编码规则 (DER) 可包含所有私钥、公钥和证书。它是大多数浏览器的缺省格式，并按 ASN1 DER 格式存储。它是无报头的 － PEM 是用文本报头包围的 DER。
PKCS#12
公钥加密标准 #12 (PKCS#12) 可包含所有私钥、公钥和证书。其以二进制格式存储，也称为 PFX 文件。
生成演示证书
生成演示证书的过程可在下列位置找到：
WLS 8.1
http://support.bea.com/askbea_soln/attachments/S-22841/Configure_Keystore_SSL_WLS81_viewlet_swf.html
WLS 6.1 和 7.0 http://support.bea.com/askbea_soln/attachments/S-21880/Setup_SSL_Certificates_WLS70_61_viewlet_swf.html
下面也简要说明此过程：
若要设置证书配置，确保拥有下面一组证书：
第 1 步 － 创建演示私钥
可通过三种方式创建私钥：您可以使用：
- keytool
- 证书 Servlet
- openssl
keytool（从 jdk 中）
若要生成私钥：
Usage; keytool -genkey [-v] [-alias <alias>] [-keyalg <keyalg>]
[-keysize <taille_clú>] [-sigalg <sigalg>]
[-dname <nomd>] [-validity <joursval>]
[-keypass <mot_passe_clú>] [-keystore <keystore>]
[-storepass <mot_passe_store>] [-storetype <type_store>]
[-provider <classe_fournisseur>] ...
keytool -genkey -keyalg RSA -alias mykey -keystore mykeystore.jks
Enter keystore password: password
What is your first and last name?
[Unknown]: Colette Gotfried
What is the name of your organizational unit?
[Unknown]: Customer Service
What is the name of your organization?
[Unknown]: BEA
What is the name of your City or Locality?
[Unknown]: Liberty Corner
What is the name of your State or Province?
[Unknown]: New Jersey
What is the two-letter country code for this unit?
[Unknown]: NJ
Is CN=Colette, OU=Customer Service, O=BEA, L=Liberty Corner, ST=NJ, C=NJ correct?
[no]: yes
Enter key password for <mykey>
(RETURN if same as keystore password):
结果您将获得一个文件：mykeystore.jks，其中包含一个私钥和一个自签名的公钥。有关使用 keytool 的详细信息，请参考 Keytool Manual。
WebLogic 中的证书 Servlet（不建议在 7.0 中使用）
在使用时，应用程序是 certificate.war 文件。其调用形式如下：
http://hostname:port/certificate
第 2 步 － 由一个受信任 CA 签署公钥
下一步是由一个已知的 CA 签署公钥。此步骤是通过得到 CSR（证书签名请求）并将其发送到一个证书颁发机构来完成的。
keytool -certreq -keystore demokeystore
Enter keystore password : password
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBrTCCARYCAQAwbTELMAkGA1UEBhMCRlIxEDAOBgNVBAgTB0Zsb3JpZGUxDjAMBgNVBAcTBVBh
cmlzMQwwCgYDVQQKEwNCRUExEzARBgNVBAsTCkJFQVN5c3RlbXMxGTAXBgNVBAMTEFNlYmFzdGll
bk1hbGJvaXMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMMfPz2S+6tXayJ2qmQ0yF6MFXxQ
XcmL2n9QqnE1k+hmIRfvD6dAYSOc8wZorbjZppEqHMK4ZVRKQuqvrRdyasR7DJO6ezQSGG0kyB+J
qLDLMkwT8ig0Z6eiIdQkvrbnCTi9hPWI76rdgwxF8UIeJbh7k0NctG1CISZdLGwRxeOJAgMBAAGg
ADANBgkqhkiG9w0BAQQFAAOBgQB5gK/tsCt3S6FTA+kfYpXMyplmbI7sDd4I0JOlciqe7ssw+va1
wA5UEVt8HqRXQMczEcZRwrf0QbxjQXJUMz4e6i4OuQvp/XMK+EOWHTcLwYgu708A81GyisXUd3/D
iecFRcH4TBCIHHbdqtFtVH0BXKsLUuiAxabRyI0507XfXg==
-----END NEW CERTIFICATE REQUEST-----
您需要将所有这些内容（包括 -----BEGIN NEW CERTIFICATE REQUEST----- 和 -----END NEW CERTIFICATE REQUEST-----）复制并粘贴到 Certification Authority 中。
下例使用了 Verisign CA：
- 转到 Verisign 站点
- 单击“SSL Trial ID”
- 填写您的所有详细信息，并复制和粘贴生成的 CSR
- 然后 Verisign 将给您发送一个电子邮件，其中包含公钥的 PEM 内容。将其保存到 public.pem 下
- 提供了一个 Verisign CA 根证书链接，将其保存到一个新文件中，例如 CA.pem
将 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
http://support.globalsign.net/en/serversign/pkcs12.cfm
- 从 pkcs12 文件提取私钥
- 从 openssl/bin 目录打开一个命令行
- 运行下列命令，以便从 pkcs12 文件提取私钥：
openssl pkcs12 .in keyexport.pfx .nocerts .nodes .out keyexport.prv
- 输入用于创建 pkcs12 (.pfx) 文件的密码
- 从 pkcs12 文件提取公钥
- 运行下列命令，以从 pkcs12 文件提取公钥：
openssl pkcs12 .in keyexport.pfx .nokeys .out keyexport.pub
- 输入用于创建 pkcs12 (.pfx) 文件的密码
- 输入 PEM 口令并确认
- 从 PEM/DER 到 DER/PEM - RSA 密钥
openssl rsa -inform PEM|DER -outform DER|PEM -in pem-file|der-file -out der-file|pem-file
一个 PEM 密钥类似如下形式：
-----BEGIN CERTIFICATE-----
...ascii stuff....
-----END CERTIFICATE-----
备注：DER 密钥不能以 ascii 格式读取。
查看证书
私钥：
openssl -rsa -inform DER -in demokey.der -text
公钥，证明颁发机构：
openssl -x509 -inform PEM -in democert.pem -text
密钥库：
keytool -list -keystore mykeystore.jks -v
Enter keystore password: password
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: mykey
Creation date: Mar 30, 2004
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Colette, OU=Customer Service, O=BEA, L=Liberty Corner, ST=NJ, C=NJ
Issuer: CN=Colette, OU=Customer Service, O=BEA, L=Liberty Corner, ST=NJ, C=NJ
Serial number: 4069afc4
Valid from: Tue Mar 30 12:35:00 EST 2004 until: Mon Jun 28 13:35:00 EDT 2004
Certificate fingerprints:
MD5: 1D:D7:8F:82:19:6D:A6:BF:C9:B1:DA:E2:EB:B3:C1:93
SHA1: 0A:83:65:79:B2:59:35:33:24:56:AF:84:E6:A3:D0:E9:12:69:C8:67
*******************************************
*******************************************
其它命令：
从 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
配置 WLS 以使用密钥库（仅单向 SSL）
从管理控制台转到服务器页面，并在“Keystore&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
确保选择了“SSL Listen Port Enabled”，然后重新启动服务器。
<19 dúc. 2003 10 h 39 CET> <Debug> <TLS> <000000> <SSLManager.getServerCertifica
te()>
<19 dúc. 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 dúc. 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 dúc. 2003 10 h 39 CET> <Info> <WebLogicServer> <BEA-000307> <Exportable key maximum lifespan set to 500 uses.>
<19 dúc. 2003 10 h 39 CET> <Info> <WebLogicServer> <BEA-000308> <Using full strength (domestic) SSL.>
<19 dúc. 2003 10 h 39 CET> <Notice> <Security> <BEA-090169> <Loading trusted certificates from the jks keystore file D:\\_Wk\\supportpattern\\mydomain\\demokeystore.>
<19 dúc. 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 dúc. 2003 10 h 39 CET> <Debug> <TLS> <000000> <SSLManager: loaded 1 trusted CAs from D:\\_Wk\\supportpattern\\mydomain\\demokeystore>
<19 dúc 2003 10 h 39 CET> <Info> <WebLogicServer> <BEA-000307> <Exportable key maximum lifespan set to 500 uses.>
<19 dúc. 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 dúc. 2003 10 h 39 CET> <Notice> <WebLogicServer> <BEA-000355> <Thread "SSLListenThread.Default" listening on port 6152, ip address *.*>
操作完成，WebLogic 现在已成功配置为执行单向 SSL（无客户端身份验证）。
故障排除
问题可能有以下起源：其中一方的 SSL 配置，用于 SSL 通信的证书，或所使用的 SSL 软件。第一步是识别相关各方所遇到的确切的 SSL 失败问题。
1. 了解失败问题：启用 SSL 调试标志跟踪 SSL 问题
为了诊断 SSL 问题，可在 java 命令行中添加下列信息：
- -Dweblogic.security.SSL.verbose=true
- -Dssl.debug=true
- -Dweblogic.StdoutDebugEnabled=true
-Dweblogic.security.SSL.debugEaten=true 标志也可添加到服务器上。由于此标志产生的信息过于冗长，建议最后再添加它。
在 config.xml 中，可以添加 DebugSSL="true"。
<ServerDebug DebugSSL="true\' Name="myserver"/>
而在 Server Mbean 中，StdoutDebugEnabled="true" StdoutSeverityLevel="64"。
如果服务器和客户端都在使用 WebLogic SSL 软件包，则必须为两者都添加这些选项，否则，仅为握手的 WebLogic 方添加。
2. 正确的握手是什么形式？
备注：有关详细信息，请参考什么是 SSL 握手？
第一次 SSL 握手
如果您 grep 一个 SSL 日志，那么一个成功的握手应显示下列信息：
服务器端
type mylogserver | grep "HANDSHAKEMESSAGE"
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientHelloV2>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientKeyExchange>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientKeyExchange RSA>
<18 déc. 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 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHello>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Certificate>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHelloDone>
<18 déc. 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 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientHelloV2>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientKeyExchange>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientKeyExchange RSA>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Finished>
<REQUEST ONE PROCESSED>
<NOW PROCESSING REQUEST TWO>
<18 dúc. 2003 13 h 27 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientHello>
<18 dúc. 2003 13 h 27 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Finished>
type mylogserver | grep "CHANGE_CIPHER_SPEC"
<18 dúc. 2003 13 h 27 CET> <Debug> <TLS> <000000> <write CHANGE_CIPHER_SPEC offset = 0 length = 1>
<18 dúc. 2003 13 h 27 CET> <Debug> <TLS> <000000> <126795 received CHANGE_CIPHER_SPEC>
客户端
type mylogclient | grep ""HANDSHAKEMESSAGE"
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHello>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Certificate>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHelloDone>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Finished>
<REQUEST ONE PROCESSED>
<18 déc. 2003 13 h 26 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHello>
<18 déc. 2003 13 h 27 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Finished>
握手执行客户端身份验证（双向 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 déc. 2003 11 h 07 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientHello>
<19 déc. 2003 11 h 07 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Certificate>
<19 déc. 2003 11 h 07 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientKeyExchange>
<19 déc. 2003 11 h 07 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientKeyExchange RSA>
<19 déc. 2003 11 h 07 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: CertificateVerify>
<19 déc. 2003 11 h 07 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Finished>
客户端
type mylogclient | grep ""HANDSHAKEMESSAGE"
>type mylogclient | grep ""HANDSHAKEMESSAGE"
<23 déc. 2003 15 h 59 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHello>
<23 déc. 2003 15 h 59 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Certificate>
<23 déc. 2003 15 h 59 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: CertificateRequest>
<23 déc. 2003 15 h 59 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHelloDone>
<23 déc. 2003 15 h 59 CET> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Finished>
type mylogclient | grep "CHANGE_CIPHER_SPEC"
<23 déc. 2003 15 h 59 CET> <Debug> <TLS> <000000> <write CHANGE_CIPHER_SPEC offs
3. 分析日志 － 确定失败
通过查看日志，您应当能找到服务器或客户端抛出的第一个 SSL 异常。所有可能的失败为：
close_notify、unexpected_message、bad_record_mac、decryption_failed、record_overflow、decompression_failure、handshake_failure、bad_certificate、unsupported_certificate、certificate_revoked、certificate_expired、 certificate_unknown、illegal_parameter、unknown_ca、access_denied、decode_error、decrypt_error、 export_restriction、protocol_version、insufficient_security、internal_error、user_canceled、no_renegotiation
最常见的失败及故障排除方法有：
普通证书
在开始查找或重现问题之前，需要检查所有证书。
openssl x509 -in ca.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, ST=California, L=San Francisco, O=BEA WebLogic, OU=Security, CN=Demo Certificate Authority/Email=support@bea.com
Validity
Not Before: May 30 21:37:44 2000 GMT
Not After : May 14 21:37:44 2004 GMT
Subject: C=US, ST=California, L=San Francisco, O=BEA WebLogic, OU=Security, CN=Demo Certificate Authority/Email=support@bea.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (512 bit)
Modulus (512 bit):
00:dd:51:28:0f:64:36:96:7e:0f:ca:29:54:35:4c:
8f:6b:dc:90:c5:2e:98:a8:99:3b:c7:05:a5:00:76:
79:00:08:6a:ed:d9:28:b1:90:c2:35:96:18:61:36:
62:86:93:b1:19:c8:0b:c2:a6:3a:81:86:42:37:ba:
70:96:4f:a1:fd
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
00:5b:0a:65:9f:5d:73:59:da:e6:51:e9:3b:c1:0b:f3:91:0f:
0c:f4:72:08:9f:65:4d:1c:37:6c:f3:04:a8:8b:72:06:e1:00:
5e:1f:30:a1:18:06:37:98:fd:2a:29:c3:a1:6b:26:14:20:4e:
e4:c1:72:a8:de:69:e0:03:cb:e3
-----BEGIN CERTIFICATE-----
MIICQzCCAe2gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFTAT
BgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxIzAhBgNVBAMT
GkRlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5MR4wHAYJKoZIhvcNAQkBFg9zdXBw
b3J0QGJlYS5jb20wHhcNMDAwNTMwMjEzNzQ0WhcNMDQwNTE0MjEzNzQ0WjCBqTEL
MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG
cmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJp
dHkxIzAhBgNVBAMTGkRlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5MR4wHAYJKoZI
hvcNAQkBFg9zdXBwb3J0QGJlYS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEA
3VEoD2Q2ln4PyilUNUyPa9yQxS6YqJk7xwWlAHZ5AAhq7dkosZDCNZYYYTZihpOx
GcgLwqY6gYZCN7pwlk+h/QIDAQABMA0GCSqGSIb3DQEBBAUAA0EAAFsKZZ9dc1na
5lHpO8EL85EPDPRyCJ9lTRw3bPMEqItyBuEAXh8woRgGN5j9KinDoWsmFCBO5MFy
qN5p4APL4w==
-----END 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.ignoreHostnameVerification=true。这意味着在该证书中，服务器证书的 CN 是 CertServer，并且在要连接的 URL 中未使用它。如果使用了 t3://CertServer:6151，则不需要 HostnameVerification 开关。
另一个解决方法可以是设置
-Dweblogic.security.SSL.hostnameVerifier=examples.security.sslclient.
NulledHostnameVerifier
NulledHostnameVerifier 已被作为 WLS 的一个示例部分发布。
CERT_CHAIN_UNTRUSTED
客户端
<23 déc. 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 dúc. 2003 15 h 31 CET> <Debug> <TLS> <000000> <Validation error = 16>
<23 dúc. 2003 15 h 31 CET> <Debug> <TLS> <000000> <Certificate chain is untrusted>
<23 dúc. 2003 15 h 31 CET> <Debug> <TLS> <000000> <SSLTrustValidator returns: 16>
<23 dúc. 2003 15 h 31 CET> <Debug> <TLS> <000000> <Trust status (16): CERT_CHAIN_UNTRUSTED>
解决办法
服务器正在发送的链路不受客户端的信任。添加
-Dweblogic.security.TrustKeyStore=CustomTrust
-Dweblogic.security.CustomTrustKeyStoreFileName=<yourkeystore>
包括服务器发送的所有受信任的 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/weblogic615/server/lib/cacerts>
<Mar 22, 2004 11:54:43 AM EST> <Debug> <TLS> <000000> <Trusted CA: Serial number: 69042098805081595651034369680212310004
Issuer:C=US, ST=MyState, L=MyTown, O=MyOrganization, OU=FOR TESTING ONLY, CN=CACERT
Subject:C=US, ST=MyState, L=MyTown, O=MyOrganization, OU=FOR TESTING ONLY, CN=CACERT
Not Valid Before:Thu Mar 21 15:12:27 EST 2002
Not Valid After:Tue Mar 22 15:12:27 EST 2022
Signature Algorithm:MD5withRSA
>
<Mar 22, 2004 11:54:43 AM EST> <Debug> <TLS> <000000> <Trusted CA: Serial number: 46914133237969612308202465797198785159
Issuer:C=US, ST=MyState, L=MyTown, O=MyOrganization, OU=FOR TESTING ONLY, CN=CertGenCAB
Subject:C=US, ST=MyState, L=MyTown, O=MyOrganization, OU=FOR TESTING ONLY, CN=CertGenCAB
Not Valid Before:Thu Oct 24 11:54:45 EDT 2002
Not Valid After:Tue Oct 25 11:54:45 EDT 2022
Signature Algorithm:MD5withRSA
>
<Mar 22, 2004 11:54:43 AM EST> <Debug> <TLS> <000000> <Trusted CA: Serial number: 11374952449
Issuer:C=US, O=VeriSign, Inc., OU=Class 4 Public Primary Certification Authority
Subject:C=US, O=VeriSign, Inc., OU=Class 4 Public Primary Certification Authority
Not Valid Before:Sun Jan 28 19:00:00 EST 1996
Not Valid After:Fri Dec 31 18:59:59 EST 1999
Signature Algorithm:MD2withRSA
当服务器在 SSL 握手期间发送其证书时，日志应类似于如下形式：
<Mar 22, 2004 11:54:43 AM EST> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ServerHello> <Mar 22, 2004 11:54:43 AM EST> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: Certificate> <Mar 22, 2004 11:54:43 AM EST> <Debug> <TLS> <000000> <Performing hostname validation checks: secure.authorize.net> <Mar 22, 2004 11:54:44 AM EST> <Debug> <TLS> <000000> <validationCallback: validateErr = 0> <Mar 22, 2004 11:54:44 AM EST> <Debug> <TLS> <000000> < cert[0] = Serial number: 61240024771365919750260051707246880350 Issuer:O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign Subject:C=US, ST=Washington, L=Bellevue, O=InfoSpace, OU=Authorize.Net, OU=Terms of use at www.verisign.com/RPA (c)01, CN=secure.authorize.net Not Valid Before:Mon Apr 21 20:00:00 EDT 2003 Not Valid After:Thu Apr 21 19:59:59 EDT 2005 Signature Algorithm:MD5withRSA > <Mar 22, 2004 11:54:44 AM EST> <Debug> <TLS> <000000> < cert[1] = Serial number: 49573667635714834907930444256359116452 Issuer:C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Subject:O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign Not Valid Before:Wed Apr 16 20:00:00 EDT 1997 Not Valid After:Mon Oct 24 19:59:59 EDT 2011 Signature Algorithm:SHAwithRSA > <Mar 22, 2004 11:54:44 AM EST> <Debug> <TLS> <000000> < cert[2] = Serial number: 149843929435818692848040365716851702463 Issuer:C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Subject:C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Not Valid Before:Sun Jan 28 19:00:00 EST 1996 Not Valid After:Tue Aug 01 19:59:59 EDT 2028 Signature Algorithm:MD2withRSA
比较两个列表，并尝试确定缺少哪个证书及其原因。可能的原因包括：
- 证书是可信的，但已过期失效
- 客户端没有加载 cacerts 证书
- 服务器使用一个自签名的证书，而客户端必须配置为信任该证书
BAD_CERTIFICATE （未正确签名导致 SSL 握手失败）
客户端
<23 dúc. 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 dúc. 2003 15 h 36 CET> <Warning> <Security> <BEA-090482> <BAD_CERTIFICATE alert was received from localhost - 127.0.0.1. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.>
<23 dúc. 2003 15 h 36 CET> <Debug> <TLS> <000000> <close(): 6386542>
[Security:090482]BAD_CERTIFICATE alert was received from localhost - 127.0.0.1.Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determ
ine the exact reason the certificate was rejected.javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was received from localhost - 127.0.0.1. Check the peer to determine why it rejected the certificate chain (trusted CA c
onfiguration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.
服务器端
<23 dúc. 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.>
解决办法
这可能是因为发送到服务器的 CA 证书以错误的链路顺序显示。检查 CA，并查看是否考虑了诸如“公共”、“中间”、“根 CA”等顺序。
CLOSE_NOTIFY
CLOSE_NOTIFY 的警报信息是正常的并且预计发生，跟踪过程没有对它进行特别处理。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 verity: 1 Type: 0 java.lang.Exception: Stack trace at weblogic.security.utils.SSLSetup.debug(SSLSetup.java:290) at com.certicom.tls.record.alert.Alert.<init>(Unknown Source) at com.certicom.tls.interfaceimpl.TLSConnectionImpl.closeWriteHandler(Unknown Source) at com.certicom.tls.interfaceimpl.TLSConnectionImpl.close(Unknown Source) at javax.net.ssl.impl.SSLSocketImpl.close(Unknown Source) at weblogic.socket.NTSocketMuxer.cleanup(NTSocketMuxer.java:500) at weblogic.rjvm.t3.T3JVMConnection.close(T3JVMConnection.java:692) at weblogic.rjvm.ConnectionManager.removeConnection(ConnectionManager.java:982) at weblogic.rjvm.ConnectionManager.shutdown(ConnectionManager.java:573) at weblogic.rjvm.ConnectionManagerServer.shutdown(ConnectionManagerServer.java:527) at weblogic.rjvm.RJVMImpl.peerGone(RJVMImpl.java:937) at weblogic.rjvm.RJVMImpl.gotExceptionReceiving(RJVMImpl.java:615) at weblogic.rjvm.ConnectionManager.gotExceptionReceiving(ConnectionManager.java:826) at weblogic.rjvm.t3.T3JVMConnection.hasException(T3JVMConnection.java:634) at weblogic.socket.SSLFilter.hasException(SSLFilter.java:302) at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:537) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:141) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:122 HANDSHAKE_FAILURE
当 WebLogic Server 连接到远程 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_EOImplorder(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.>
解决方法
此现象发生在客户端获得 ServerHello 消息之前。Microsoft 服务器正在拒绝握手，因为为远程服务器指定的密码套件不是 128 位的。远程服务器不允许低于此位数的密码。如果在 WebLogic Server 端更改客户端许可证，问题即可解决。
| 
发起投票
技术讨论
加好友
发消息
2015-3-20 9:44:06 |
赞(
操作
