使用HTTPS调用REST服务的Oracle BPEL (Java8U92)提供SSL握手异常

Question

我使用oracleSOA12c设置了一个基本的weblogic域，用于开发一个可以调用Apples服务的组合。Apple需要使用HTTP2和TLS 1.2加密的TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384连接。

JKS信任库已经配置并加载了根证书、中间证书和服务器证书的证书。

geotrustrootca, Jun 21, 2016, trustedCertEntry, 
Certificate fingerprint (SHA1): DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
serverc_ss_cert, Jun 21, 2016, trustedCertEntry, 
Certificate fingerprint (SHA1): 73:C4:A9:4E:E8:1B:14:58:7B:64:47:02:73:01:15:3E:88:E8:E8:66
appledevpush, Jun 21, 2016, trustedCertEntry, 
Certificate fingerprint (SHA1): CC:18:A5:75:04:74:3A:3B:72:D7:A5:07:F2:CD:E4:83:51:11:34:CB
appleintermediate, Jun 21, 2016, trustedCertEntry, 
Certificate fingerprint (SHA1): 8E:83:21:CA:08:B0:8E:37:26:FE:1D:82:99:68:84:EE:B5:F0:D6:55

setDomainEnv.sh已通过添加java属性-Djavax.net.ssl.trustStore=/u01/data/keystores/truststore.jks进行了更改。

在测试一个简单的BPEL组合时，如果一个SSLHandshakeException失败了，则对苹果的APN服务进行REST调用：

[ACTIVE] ExecuteThread: '58' for queue: 'weblogic.kernel.Default (self-tuning)', SEND TLSv1.2 ALERT:  fatal, description = certificate_unknown
[ACTIVE] ExecuteThread: '58' for queue: 'weblogic.kernel.Default (self-tuning)', WRITE: TLSv1.2 Alert, length = 2
[ACTIVE] ExecuteThread: '58' for queue: 'weblogic.kernel.Default (self-tuning)', called closeSocket()
[ACTIVE] ExecuteThread: '58' for queue: 'weblogic.kernel.Default (self-tuning)', handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

调试时可以看到SSL协商；

%% No cached client session
*** ClientHello, TLSv1.2

....

*** ServerHello, TLSv1.2
RandomCookie:  GMT: 1922117017 bytes = { 236, 133, 59, 43, 182, 3, 165, 71, 241, 54, 240, 145, 222, 41, 200, 242, 63, 237, 253, 77, 188, 235, 187, 177, 245, 173, 53, 232 }
Session ID:  {119, 250, 96, 4, 116, 33, 211, 17, 47, 213, 227, 158, 164, 107, 14, 73, 157, 194, 0, 104, 54, 237, 0, 58, 229, 225, 158, 2, 29, 159, 79, 171}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

...

%% Initialized:  [Session-7, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
** TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[ACTIVE] ExecuteThread: '58' for queue: 'weblogic.kernel.Default (self-tuning)', READ: TLSv1.2 Handshake, length = 2576
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: C=US, ST=California, O=Apple Inc., OU=management:idms.group.533599, CN=api.development.push.apple.com
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

...

chain [1] = [
[
  Version: V3
  Subject: C=US, O=Apple Inc., OU=Certification Authority, CN=Apple IST CA 2 - G1
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

...

***
%% Invalidated:  [Session-7, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
[ACTIVE] ExecuteThread: '58' for queue: 'weblogic.kernel.Default (self-tuning)', SEND TLSv1.2 ALERT:  fatal, description = certificate_unknown
[ACTIVE] ExecuteThread: '58' for queue: 'weblogic.kernel.Default (self-tuning)', WRITE: TLSv1.2 Alert, length = 2
[ACTIVE] ExecuteThread: '58' for queue: 'weblogic.kernel.Default (self-tuning)', called closeSocket()
[ACTIVE] ExecuteThread: '58' for queue: 'weblogic.kernel.Default (self-tuning)', handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

我的结论是服务器N=api.development.push.apple.com的服务器证书被接受，但中间CA CN=Apple IST CA 2 - G1的证书被拒绝。

CN=Apple IST CA 2 - G1的发行者是CN=GeoTrust Global CA, O=GeoTrust Inc., C=US，序列号为023a74。此证书也加载在信任库中；

别名: geotrustrootca创建日期:2016年6月21日输入类型: trustedCertEntry

Owner: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Issuer: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Serial number: 23456
Valid from: Tue May 21 06:00:00 CEST 2002 until: Sat May 21 06:00:00 CEST 2022
Certificate fingerprints:
     MD5:  F7:75:AB:29:FB:51:4E:B7:77:5E:FF:05:3C:99:8E:F5
     SHA1: DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
     SHA256: FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A
     Signature algorithm name: SHA1withRSA
     Version: 3

有什么想法(如果我的结论是正确的)，为什么中间证书被拒绝或如何进一步调试这一点？当使用浏览器将URI打开到APN并检查证书时，我得到的结果与信任库中的相同。

==更新1 ==

试着用卷发连接。首先，将证书从信任存储库导出到/u 01/data/keystore

$keytool -keystore truststore.jks -exportcert -alias geotrustrootca | openssl x509 -inform der -text > geotrustrootca.pem
 $keytool -keystore truststore.jks -exportcert -alias appledevpush | openssl x509 -inform der -text > appledevpush.pem
$keytool -keystore truststore.jks -exportcert -alias appleintermediate | openssl x509 -inform der -text > appleintermediate.pem

然后尝试使用curl连接

$ curl --capath /u01/data/keystores --verbose  https://api.development.push.apple.com/3/device/
* About to connect() to api.development.push.apple.com port 443 (#0)
*   Trying 17.172.238.203... connected
* Connected to api.development.push.apple.com (17.172.238.203) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* failed to load '/u01/data/keystores/identitykeystore.jks' from CURLOPT_CAPATH
* failed to load '/u01/data/keystores/appledevpush.cer' from CURLOPT_CAPATH
* failed to load '/u01/data/keystores/geotrustrootca.cer' from CURLOPT_CAPATH
* failed to load '/u01/data/keystores/truststore.jks' from CURLOPT_CAPATH
* failed to load '/u01/data/keystores/yum-oracle-8v1ncO' from CURLOPT_CAPATH
* failed to load '/u01/data/keystores/vm0010.localdomain-rootCA.der' from CURLOPT_CAPATH
* failed to load '/u01/data/keystores/appleintermediate.cer' from CURLOPT_CAPATH
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: /u01/data/keystores
* NSS: client certificate not found (nickname not specified)
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*   subject: C=US,ST=California,O=Apple Inc.,OU=management:idms.group.533599,CN=api.development.push.apple.com
*   start date: Jun 19 01:49:43 2015 GMT
*   expire date: Jul 18 01:49:43 2017 GMT
*   common name: api.development.push.apple.com
*   issuer: C=US,O=Apple Inc.,OU=Certification Authority,CN=Apple IST CA 2 - G1
> GET /3/device/ HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.21 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: api.development.push.apple.com
> Accept: */*
> 
* Connection #0 to host api.development.push.apple.com left intact
* Closing connection #0
@@�HTTP/2 client preface string missing or corrupt. Hex dump for received bytes: 474554202f332f6465766963652f20485454502f312e310d

所以证书是正确的。

==更新2 ==

再次创建信任库。通过在netscape中打开url https://api.development.push.apple.com/3/device/并以pem格式保存证书来获取pem文件。

在新的truststore.jks中导入证书

用于ls -1 *.der中的文件；do keytool -importcert -keystore truststore.jks -file $file -storepass welcome1 -noprompt -alias $file；已完成

不Joy..。

==更新3 ==

在server.out中重新启动托管服务器时，也会加载默认的自签名证书。

<Jul 11, 2016 10:15:50 PM CEST> <Warning> <oracle.soa.healthcheck> <BEA-000000> <On startup, health check id 881 failed for category 'Startup'. Ran 6 checks. Number of failures=1, errors=1, warnings=0.>
adding as trusted cert:
  Subject: CN=CertGenCA, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
  Issuer:  CN=CertGenCA, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
  Algorithm: RSA; Serial number: 0x40044886c441ef3b643a8066409afca0
  Valid from Sat Dec 01 04:07:51 CET 2012 until Thu Dec 02 04:07:51 CET 2032

adding as trusted cert:
  Subject: CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
  Issuer:  CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
  Algorithm: RSA; Serial number: 0x234b5559d1fa0f3ff5c82bdfed032a87
  Valid from Thu Oct 24 17:54:45 CEST 2002 until Tue Oct 25 17:54:45 CEST 2022

javax.net.ssl.trustStore设置为自定义信任库。在weblogic中，Identity和Truststore位置也被设置为自定义JKS商店。

即使从$WLS_HOME/lib中删除了DemoTrust.jks，也会将证书作为受信任的证书添加。我目前不知道这些是从何而来的。

==更新4 ==

$DOMAIN/security包含DemoIdentity.jks。删除此文件并重新启动托管服务器后，不再加载演示可信证书。

==更新5 ==

根据目标url、SAS、SSL/TLS诊断工具验证信任存储。以确保信任库的设置正确。

​

​

正如user2351802所指出的，必须使用OPSS而不是在javax.net.ssl.trustStore属性javax.net.ssl.trustStore中定义的JKS。

在Suite 10g/11g中，使用单向SSL从组合调用外部webservices时，标准的安全传输方式是创建JKS信任库，并在javax.net.ssl.trustStore属性中指定该信任存储的位置。甚至在SOA套房12.2.1.1管理指南中仍然记录了使用JKS信任库来建立来自SOA组合的单向SSL连接。Oracle12.2.1.1.0 WebLogic服务器管理指南提到了(新的) OPSS，并引用了用于使用和配置新的用Oracle平台安全服务保护应用程序密钥的文档"用Oracle平台安全服务保护应用程序“。虽然它提到了为LDAP显式设置单向SSL的过程，但它似乎是FMW应用程序的新的通用方法。

清理weblogic中的标识和信任存储库，只将服务器证书添加到标识存储区(因此JKS信任库中不再有可信证书)，然后将根证书添加到OPSS系统/信任中，这样就可以工作了！

Answer 1

好的。这听起来很棒，但会奏效的。我们有相同的SOA12c设置，但是对于托管SOA服务器，我们使用标准Java信任密钥存储库。

我可以看到，您已经修改了setDomainEnv.sh，将/u 01/data/ keystore /信任存储.u01指定为密钥存储库。

理论上，如果根证书在我的例子中位于仙人掌中，而在您的例子中是truststore.jks，那么它应该可以工作。我可以确认SOAP服务在keystore中运行良好。

不知何故，通过REST适配器调用REST服务由于证书错误而失败，这与您的错误相同。

Here's what made it to work:
Login to EM
Weblogic Domain -> Security -> Keystore
Select System (stripe) -> trust -> Hit the manage button
Here import the root cert of geotrustrootca.

弹出SOA服务器。测试你的服务。它应该能正常工作。

我不明白的是:当您配置域时，系统(条带) ->信任=这是预先配置为演示信任存储的。我已经将托管服务器的密钥存储设置更改为使用仙人掌。不知何故，这个kss信任商店看起来还在某个地方被引用。问题是在哪里？

一定要分享，以防你搞清楚这件事。与此同时，解决办法会让你走。