1. 홈
  2. 질의 응답
  3. HTTPS를 사용하여 REST 서비스를 호출하는 Oracle BPEL (Java 8U92)은 SSL 핸드 셰이크 예외를 제공합니다.

HTTPS를 사용하여 REST 서비스를 호출하는 Oracle BPEL (Java 8U92)은 SSL 핸드 셰이크 예외를 제공합니다.

2016-07-06 3 views
2

Apples APN 서비스를 호출 할 수있는 컴포지트를 개발하기 위해 oracle SOA 12c를 기본 웹 로직 도메인으로 설정했습니다. Apple APN은 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 및 TLS 1.2로 암호화 된 HTTP2 연결이 필요합니다.HTTPS를 사용하여 REST 서비스를 호출하는 Oracle BPEL (Java 8U92)은 SSL 핸드 셰이크 예외를 제공합니다.

JKS truststore가 루트, 중간 및 서버 인증서의 인증서로 구성되고로드되었습니다.

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은 SSLHandshakeException이 실패하면 애플의 APN 서비스에 REST 호출을 간단한 BPEL 복합을 테스트 할 때 자바 속성 -Djavax.net.ssl.trustStore=/u01/data/keystores/truststore.jks

를 추가하여 변경되었습니다 :

[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의 발행자는 일련 번호 023a74 인 CN=GeoTrust Global CA, O=GeoTrust Inc., C=US입니다. 이 인증서는 신뢰 저장소에도로드됩니다.

별칭 이름 : 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으로 열어 인증서를 검사 할 때 truststore에서와 동일한 결과를 얻습니다.

== 업데이트 1 ==

컬을 사용하여 연결을 시도했습니다./U01/데이터/ 

$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 --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; 완료 됨

아니요 ...

== 업데이트 3 == 관리 서버를 다시 시작하는 것은 이제 기본 자체 서명 된 인증서도로드하는 server.out에 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

javax.net.ssl.trustStore가 사용자 정의 트러스트 스토어로 설정되었습니다. 또한 웹 로직에서는 Identity 및 Truststore 위치가 사용자 정의 JKS 상점으로 설정되었습니다.

$ WLS_HOME/lib에서 DemoTrust.jks를 제거한 후에도 certs는 신뢰할 수있는 인증서로 추가됩니다. 나는 현재 이들이 어디에서 왔는지 알 수 없다.

== 업데이트 4 ==

$ DOMAIN_HOME/보안은 DemoIdentity.jks 포함되어 있습니다. 이 파일을 제거하고 관리 서버를 다시 시작하면 데모 트러스트 된 인증서가 더 이상로드되지 않습니다.

== 업데이트 5 ==

는 대상 URL SAS SSL/TLS의 diagnosics 도구에 대한 신뢰를 확인했습니다. 트러스트 스토어가 올바르게 설정되었는지 확인하십시오.

SAS SSL/TLS diagnostics tool

으로는 OPSS 키 저장소 대신 자바 속성 정보 javax.net.ssl.trustStore에 정의 된 JKS 키 저장소로 사용할 수있다 user2351802에 의해 지적했다.

SOA 스위트 10g/11g에서 단방향 SSL을 사용하여 컴포지트에서 외부 웹 서비스를 호출 할 때 표준 보안 방법은 JKS truststore를 작성하고 javax.net.ssl.trustStore Java 특성에서 해당 트러스트 스토어의 위치를 ​​지정하는 것입니다 . SOA Suite 12.2.1.1 Admin Guide에 SOA 컴포지트의 maken 단방향 SSL 연결에 JKS truststore를 사용하는 방법이 여전히 문서화되어 있습니다. Oracle WebLogic Server 12.2.1.1.0 Admin Guide은 (새) OPSS 키 저장소를 언급하고 새 KSS OPSS 키 저장소를 사용하고 구성하기 위해 "Securing Applications with Oracle Platform Security Services"문서를 참조합니다. LDAP에 단방향 SSL을 명시 적으로 설정하는 절차가 언급되어 있지만 FMW 응용 프로그램의 새로운 일반적인 방법으로 보입니다.

weblogic에서 ID 및 트러스트 스토어를 정리하고 신원 저장소에 서버 인증서를 추가 한 다음 (따라서 JKS 트러스트 스토어에 더 이상 신뢰할 수있는 인증서가 없습니다) 루트 인증서를 OPSS 시스템에 추가하거나 작동했는지 확인하십시오!

출처

2016-07-06 pcvnes

+0

'$ JAVA_HOME/lib/security/java.security' 파일의'jdk.certpath.disabledAlgorithms' 줄에 무엇이 들어 있습니까? –

+0

포함되어 있습니다; jdk.certpath.disabledAlgorithms = MD2, MD5, RSA keySize <1024 – pcvnes

+0

openssl s_client -connect ...와 함께 OpenSSL과 같은 SSL 연결을 성공적으로 만들 수 있습니까? –

답변

1

확인. 그것은 이상하게 들리 겠지만 효과가있을 것입니다. 우리는 동일한 SOA 12c 설정을 가지고 있지만 관리 SOA 서버에 표준 Java 신뢰 키 스토어를 사용하고 있습니다.

키 저장소로 /u01/data/keystores/truststore.jks를 지정하도록 setDomainEnv.sh를 수정 한 것을 볼 수 있습니다.

이론상 루트 인증서가 내 케이스의 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 서버를 반송하십시오. 서비스를 테스트하십시오. 그것은 잘 작동합니다.

는 내가 이해 해달라고 것은 : 시스템 (스트라이프) -> 신뢰 = 도메인을 구성 할 때이 데모 신뢰 저장소로 미리 입니다. I 이 (가) cacerts를 사용하도록 관리되는 서버의 키 저장소 설정을 이미 변경했습니다. 어떻게 든이 kss 트러스트 스토어는 여전히 어딘가에서 참조 된 인 것 같습니다. 문제는 어디에 있습니까?

당신이 이것을 알아낼 수있는 경우를 대비하여 공유하십시오. 그 동안 솔루션을 통해 얻을 수 있습니다.

출처

2016-07-19 15:27:04 user2351802

+0

안녕하세요, 지적 해 주셔서 감사합니다! – pcvnes

관련 문제

 관련 문제