Oracle BPEL（Java 8U92）使用HTTPS调用REST服务会导致SSL握手异常

我已经使用OracleSOA12C设置了一个基本的weblogic域，用于开发一个可以调用Apple APN服务的组合。苹果APN需要一个使用TLS加密的HTTP2连接，TLS使用TLS加密ECDHE加密RSA加密，TLS使用TLS加密AES加密256加密GCM加密SHA384加密，TLS使用TLS 1.2加密

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

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

==更新1==

尝试使用curl连接。
首先将证书从信任库导出到/u01/data/keystores

$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==

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

在新的truststore.jks中导入了证书

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

没有快乐

==更新3==

重新启动时，服务器中的托管服务器现在为obvserved。我们将检查是否也加载了默认的自签名证书

<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


添加为受信任证书：
主题：CN=CertGenCA，OU=仅用于测试，O=MyOrganization，L=MyTown，ST=MyState，C=US
发卡机构：CN=CertGenCA，OU=仅用于测试，O=MyOrganization，L=MyTown，ST=MyState，C=US
算法：RSA；序列号：0x40044886c441ef3b643a8066409afca0
有效期为2012年12月1日星期六04:07:51至2032年12月2日星期四04:07:51
添加为受信任证书：
主题：CN=CertGenCAB，OU=仅用于测试，O=MyOrganization，L=MyTown，ST=MyState，C=US
发卡机构：CN=CertGenCAB，OU=仅用于测试，O=MyOrganization，L=MyTown，ST=MyState，C=US
算法：RSA；序列号：0x234B559D1FA0F3FF5C82BDFED032A87
有效期为2002年10月24日星期四17:54:45至2022年10月25日星期二17:54:45

javax.net.ssl.trustStore设置为自定义信任库。此外，在weblogic中，标识和信任存储位置已设置为自定义JKS存储

即使从$WLS_HOME/lib中删除democrust.jks，证书也会作为受信任证书添加。我现在不知道这些是从哪里来的

==更新4==

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

==更新5==

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


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

在SOA Suite 10g/11g中，当使用单向SSL从组合调用外部Web服务时，标准的安全传输方式是创建JKS信任库，并在javax.net.SSL.truststore Java属性中指定该信任库的位置。使用JKS truststore从SOA组合生成单向SSL连接的过程中，甚至还有文档记录。提到（新的）OPSS密钥库，并参考文档“”以使用和配置新的KSS OPSS密钥库。虽然它提到了为LDAP显式设置单向SSL的过程，但它似乎是FMW应用程序的新的通用方法

在weblogic中清理了identity和truststore，仅将服务器证书添加到identity store（因此JKS truststore中不再有可信证书）并将根证书添加到OPSS系统/信任之后，它就工作了
 好的。这听起来很奇怪，但会奏效。我们有相同的SOA12C设置，但我们正在为托管SOA服务器使用标准Java信任密钥库

我可以看到您已经修改了setDomainEnv.sh，将/u01/data/keystores/truststore.jks指定为您的密钥库

理论上，如果根证书在我的案例中存在于cacerts中，而在你的案例中存在于truststore.jks中，那么它应该可以工作。我可以确认SOAP服务与密钥库一起工作良好

由于证书错误，通过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信托商店看起来仍然很安全
在某处引用。问题是在哪里

一定要分享，以防万一你弄明白了。同时，该解决方案将让您继续。
文件
$JAVA\u HOME/lib/security/JAVA.security
中的
jdk.certpath.disabledAlgorithms
行包含什么？它包含；jdk.certpath.disabledAlgorithms