SSL handshake with webcache

Hello,
I am having some trouble with using Webcache and WebLogic. Basically I have narrowed the problem through debug logs down to a certificate error involving the certificate being sent from weblogic to webcache. Webcache cannot validate it and as a result the handshake fails. I have recently installed WebLogic 12c and am testing the APEX listener I deployed on it. Currently I can access weblogic through the browser using SSL. However when I map webcache to the the weblogic address, the cert is not valid and the handshake fails resulting in no page being returned.
I have also encountered an unusual scenario changing things around. If I use SSL between a client and webcache and non ssl between webcache and weblogic it "almost works".
An example will be best
If i enter https://example.com/apex into the browser, I get a 404 error and the address changes to example.com/apex/f=?111111111
However if i add the https:// prefix to that url, the page shows up and the url is https://example.com/apex/f=?1111111
This may have something to do with local caching but haven't investigated much yet.
An additional note would be that I am using the Demo keystore provided with the weblogic 12c install.
Now to focus the above, Is there a reason WebCache does not like the demo keystore provided with weblogic 12c. I am doing this in a development environment before i proceed with certificates and keystore creation.
Thanks.

Similar Messages

Ssl-handshake fails with scandinavian chars in client certificate

Hello,
We've run into a problem with 2-way-ssl and certificates that have scandinavian
characters in the subject. The problem cert is used as client-certificate for
authentication and it goes like this:
1. Client surfs with http in our site, until clicks https-link that will immediately
start the ssl-handshake
2. Server presents it's trusted cert-list fine
3. PIN is being asked fine
4. Next the request processing stops on the exception below and nothing will happen
on the client side.
Certs without these äöå -chars work fine, so our guess is that they cause it,
but the certs ought to be according to specs: name-fields encoding is UTF-8 according
to RFC 2459 from year 1999. A failing example-cert is also below.
Would this be a problem with the certificate rather than BEA-implementation?
Same behavior on Windows and Solaris Weblogic 8.11 as such and with SP2 (and with
sp2 + CASE_ID_NUM: 501454 hotfix).
Best Regards,
Igor Styrman
<avalable(): 20303264 : 0 + 0 = 0>
<write ALERT offset = 0 length = 2>
<SSLIOContextTable.removeContext(ctx): 1765100>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <Filtering JSSE
SSLSocket>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <SSLIOContextTable.addContext(ctx):
6487148>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <SSLSocket will
be Muxing>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <SSLIOContextTable.findContext(is):
11153746>
<SSLFilter.isActivated: false>
<isMuxerActivated: false>
<SSLFilter.isActivated: false>
<21647856 readRecord()>
<21647856 SSL Version 2 with no padding>
<21647856 SSL3/TLS MAC>
<21647856 received SSL_20_RECORD>
<HANDSHAKEMESSAGE: ClientHelloV2>
<write HANDSHAKE offset = 0 length = 58>
<write HANDSHAKE offset = 0 length = 1789>
<Converting principal: OU=Class 4 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US>
<Converting principal: CN=SHP ROOT CA, O=SHP, C=FI>
<Converting principal: CN=topsel, O=Fujitsu Services Oy, C=FI>
<Converting principal: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions,
Inc.", O=GTE Corporation, C=US>
<Converting principal: CN=SatShp CA, O=Satakunnan sairaanhoitopiiri, C=FI>
<Converting principal: OU=Class 1 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US>
<Converting principal: [email protected], CN=Thawte Personal
Basic CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town,
ST=Western Cape, C=ZA>
<Converting principal: [email protected], CN=Thawte Personal
Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town,
ST=Western Cape, C=ZA>
<Converting principal: OU=Class 3 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US>
<Converting principal: CN=GTE CyberTrust Root, O=GTE Corporation, C=US>
<Converting principal: [email protected], CN=Thawte Server
CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western
Cape, C=ZA>
<Converting principal: [email protected], CN=Thawte Personal
Premium CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town,
ST=Western Cape, C=ZA>
<Converting principal: [email protected], CN=Thawte Premium
Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape
Town, ST=Western Cape, C=ZA>
<Converting principal: OU=Secure Server Certification Authority, O="RSA Data Security,
Inc.", C=US>
<Converting principal: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore,
C=IE>
<Converting principal: CN=Fujitsu Test CA, O=Fujitsu Services Oy, C=FI>
<Converting principal: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions,
Inc.", O=GTE Corporation, C=US>
<Converting principal: CN=PSHP CA, O=Pirkanmaan sairaanhoitopiiri, C=FI>
<Converting principal: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust,
O=Baltimore, C=IE>
<Converting principal: OU=Class 2 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US>
<write HANDSHAKE offset = 0 length = 2409>
<write HANDSHAKE offset = 0 length = 4>
<SSLFilter.isActivated: false>
<isMuxerActivated: false>
<SSLFilter.isActivated: false>
<21647856 readRecord()>
<21647856 SSL3/TLS MAC>
<21647856 received HANDSHAKE>
<HANDSHAKEMESSAGE: Certificate>
PM EEST> <Error> <Kernel> <> <satshpeduServer> <ExecuteThread: '14' for queue:
'weblogic.kernel.Default'> <<WLS Kernel>> <> <BEA-000802> <ExecuteRequest failed
java.lang.NullPointerException: Could not set value for ASN.1 string object..
java.lang.NullPointerException: Could not set value for ASN.1 string object.
     at com.certicom.security.asn1.ASN1String.setValue(Unknown Source)
     at com.certicom.security.asn1.ASN1String.setBufferTo(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeString(Unknown Source)
     at com.certicom.security.asn1.ASN1String.decode(Unknown Source)
     at com.certicom.security.pkix.AttributeTypeAndValue.decodeContents(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown Source)
     at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
     at com.certicom.security.asn1.ASN1SetOf.decodeContents(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeSetOf(Unknown Source)
     at com.certicom.security.asn1.ASN1SetOf.decode(Unknown Source)
     at com.certicom.security.asn1.ASN1SequenceOf.decodeContents(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown Source)
     at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
     at com.certicom.security.pkix.Name.decodeContents(Unknown Source)
     at com.certicom.security.asn1.ASN1Choice.decode(Unknown Source)
     at com.certicom.security.pkix.TBSCertificate.decodeContents(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown Source)
     at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
     at com.certicom.security.pkix.Certificate.decodeContents(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown Source)
     at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
     at com.certicom.security.asn1.ASN1Type.decode(Unknown Source)
     at com.certicom.security.cert.internal.x509.X509V3CertImpl.<init>(Unknown Source)
     at com.certicom.tls.record.handshake.MessageCertificate.<init>(Unknown Source)
     at com.certicom.tls.record.handshake.HandshakeMessage.create(Unknown Source)
     at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(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.net.ssl.CerticomContextWrapper.forceHandshakeOnAcceptedSocket(Unknown
Source)
     at weblogic.t3.srvr.SSLListenThread$1.execute(SSLListenThread.java:514)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
-----BEGIN CERTIFICATE-----
MIID+zCCAuOgAwIBAgIDFm/PMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkZJ
MRwwGgYDVQQKExNGdWppdHN1IFNlcnZpY2VzIE95MRgwFgYDVQQDEw9GdWppdHN1
IFRlc3QgQ0EwHhcNMDQwNjAyMTE1MjE4WhcNMDYwNjAyMTIyMjE4WjB3MQswCQYD
VQQGEwJGSTEQMA4GA1UEChMHRnVqaXRzdTEgMB4GA1UEAwwXSMO2bG3DtmzDpGlu
ZW4gw4VrZSAwMDExDDAKBgNVBAUTAzAwMTEXMBUGA1UEBAwOSMO2bG3DtmzDpGlu
ZW4xDTALBgNVBCoMBMOFa2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAO44
Zm31uJb8048/6PByPyXzaW3gCz1mT02TuwVtjMRJ4ObbFCqMGC+YosA2kNKoW0Ef
C+YlKNqhvaid0bATQefdSHVQhzFL3HFIfZc3ONAJQ/U+I6W69r2JePoCvZppknmC
YrnCCDx3Ap27B7v57f/XTmdpiB8IdiCTl3PnV78PAgMBAAGjggFEMIIBQDAfBgNV
HSMEGDAWgBT8T+xYc3T6j89O8cZ4hC9r1e9DojAdBgNVHQ4EFgQUtS4z8K26uW2d
IeJ3aelDnqnkBnYwCwYDVR0PBAQDAgSwMFMGA1UdEQRMMEqgKwYKKwYBBAGCNxQC
A6AdDBtha2UuaG9sbW9sYWluZW5AZnVqaXRzdS5jb22BG2FrZS5ob2xtb2xhaW5l
bkBmdWppdHN1LmNvbTB9BgNVHR8EdjB0MHKgcKBuhmxsZGFwOi8vMjEyLjI0Ni4y
MjIuMTQyOjM4OS9DTj1GdWppdHN1JTIwVGVzdCUyMENBLE89RnVqaXRzdSUyMFNl
cnZpY2VzJTIwVGVzdCxDPUZJP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3QwHQYD
VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQAZ
KV3Og/y6zUOMwZGswUxAne5fe4Ab70bmX+z49MVeA0dfdQwQdR9GwFVF+fcK+q0T
3Lmcwpm5KiHWYoIOxPb6MqTTWxV7HSXWr7A7P4BbTGxsujpUULcmQGQFAd69R0Ur
JFDwYnDEP2+4RzrvlP6AWspyHJePYmCt9h3JfxYAqVLTL0suO1uh8hgtStujmqsI
0WNCfnQ+sURdDzp6WpVFcxFQa5aAcyx9sWWqV5Ta5l6JTCmoHth7qoV3BtUKv4+z
SqIHKA1ixrvlhqWkjYxg51N6ihbbR5shBRRinAqRIQjTzXmun2wJzwNigt4zWiNg
tvrGCMOrvrb5QTxVtLNr
-----END CERTIFICATE-----

BMPString is another asn1 type that can be used for certificate attributes with
non-ascii characters. The workaround is simply to use the BMPString instead of
UTF8String for that subject name attribute in the certificate request. This off-course
assumes that you can replace the certificate, and have control over what asn1
type is used for the subject name attributes in the certificate request (via a
tool options, or by generating the request yourself), so it is probably not applicable.
Pavel.
"Ari Räisänen" <[email protected]> wrote:
>
Thanks again, Pavel!
I'm filing a support case about this. You talked about a workaround (BMPString).
Could you be more spesific? I haven't talked about this issue with Igor
yet.
Regards,
Ari
"Pavel" <[email protected]> wrote:
Sounds like a bug in certicom code. It should support UTF8String.
I'd file a support case.
You might be able to use BMPString instead as a workaround.
Pavel.
"Igor Styrman" <[email protected]> wrote:
Hello,
We've run into a problem with 2-way-ssl and certificates that have
scandinavian
characters in the subject. The problem cert is used as client-certificate
for
authentication and it goes like this:
1. Client surfs with http in our site, until clicks https-link thatwill
immediately
start the ssl-handshake
2. Server presents it's trusted cert-list fine
3. PIN is being asked fine
4. Next the request processing stops on the exception below and nothing
will happen
on the client side.
Certs without these äöå -chars work fine, so our guess is that they
cause it,
but the certs ought to be according to specs: name-fields encoding
is
UTF-8 according
to RFC 2459 from year 1999. A failing example-cert is also below.
Would this be a problem with the certificate rather than BEA-implementation?
Same behavior on Windows and Solaris Weblogic 8.11 as such and withSP2
(and with
sp2 + CASE_ID_NUM: 501454 hotfix).
Best Regards,
Igor Styrman
<avalable(): 20303264 : 0 + 0 = 0>
<write ALERT offset = 0 length = 2>
<SSLIOContextTable.removeContext(ctx): 1765100>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <Filtering
JSSE
SSLSocket>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <SSLIOContextTable.addContext(ctx):
6487148>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <SSLSocket
will
be Muxing>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <SSLIOContextTable.findContext(is):
11153746>
<SSLFilter.isActivated: false>
<isMuxerActivated: false>
<SSLFilter.isActivated: false>
<21647856 readRecord()>
<21647856 SSL Version 2 with no padding>
<21647856 SSL3/TLS MAC>
<21647856 received SSL_20_RECORD>
<HANDSHAKEMESSAGE: ClientHelloV2>
<write HANDSHAKE offset = 0 length = 58>
<write HANDSHAKE offset = 0 length = 1789>
<Converting principal: OU=Class 4 Public Primary Certification Authority,
O="VeriSign,
Inc.", C=US>
<Converting principal: CN=SHP ROOT CA, O=SHP, C=FI>
<Converting principal: CN=topsel, O=Fujitsu Services Oy, C=FI>
<Converting principal: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust
Solutions,
Inc.", O=GTE Corporation, C=US>
<Converting principal: CN=SatShp CA, O=Satakunnan sairaanhoitopiiri,
C=FI>
<Converting principal: OU=Class 1 Public Primary Certification Authority,
O="VeriSign,
Inc.", C=US>
<Converting principal: [email protected], CN=Thawte
Personal
Basic CA, OU=Certification Services Division, O=Thawte Consulting,
L=Cape
Town,
ST=Western Cape, C=ZA>
<Converting principal: [email protected], CN=Thawte
Personal
Freemail CA, OU=Certification Services Division, O=Thawte Consulting,
L=Cape Town,
ST=Western Cape, C=ZA>
<Converting principal: OU=Class 3 Public Primary Certification Authority,
O="VeriSign,
Inc.", C=US>
<Converting principal: CN=GTE CyberTrust Root, O=GTE Corporation, C=US>
<Converting principal: [email protected], CN=Thawte
Server
CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape
Town, ST=Western
Cape, C=ZA>
<Converting principal: [email protected], CN=Thawte
Personal
Premium CA, OU=Certification Services Division, O=Thawte Consulting,
L=Cape Town,
ST=Western Cape, C=ZA>
<Converting principal: [email protected], CN=Thawte
Premium
Server CA, OU=Certification Services Division, O=Thawte Consultingcc,
L=Cape
Town, ST=Western Cape, C=ZA>
<Converting principal: OU=Secure Server Certification Authority, O="RSA
Data Security,
Inc.", C=US>
<Converting principal: CN=Baltimore CyberTrust Root, OU=CyberTrust,O=Baltimore,
C=IE>
<Converting principal: CN=Fujitsu Test CA, O=Fujitsu Services Oy, C=FI>
<Converting principal: CN=GTE CyberTrust Root 5, OU="GTE CyberTrustSolutions,
Inc.", O=GTE Corporation, C=US>
<Converting principal: CN=PSHP CA, O=Pirkanmaan sairaanhoitopiiri,
C=FI>
<Converting principal: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust,
O=Baltimore, C=IE>
<Converting principal: OU=Class 2 Public Primary Certification Authority,
O="VeriSign,
Inc.", C=US>
<write HANDSHAKE offset = 0 length = 2409>
<write HANDSHAKE offset = 0 length = 4>
<SSLFilter.isActivated: false>
<isMuxerActivated: false>
<SSLFilter.isActivated: false>
<21647856 readRecord()>
<21647856 SSL3/TLS MAC>
<21647856 received HANDSHAKE>
<HANDSHAKEMESSAGE: Certificate>
PM EEST> <Error> <Kernel> <> <satshpeduServer> <ExecuteThread: '14'
for queue:
'weblogic.kernel.Default'> <<WLS Kernel>> <> <BEA-000802> <ExecuteRequest
failed
java.lang.NullPointerException: Could not set value for ASN.1 string
object..
java.lang.NullPointerException: Could not set value for ASN.1 string
object.
     at com.certicom.security.asn1.ASN1String.setValue(Unknown Source)
     at com.certicom.security.asn1.ASN1String.setBufferTo(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeString(UnknownSource)
     at com.certicom.security.asn1.ASN1String.decode(Unknown Source)
     at com.certicom.security.pkix.AttributeTypeAndValue.decodeContents(Unknown
Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown
Source)
     at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown
Source)
     at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
     at com.certicom.security.asn1.ASN1SetOf.decodeContents(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown
Source)
     at com.certicom.security.asn1.DERInputStream.decodeSetOf(Unknown Source)
     at com.certicom.security.asn1.ASN1SetOf.decode(Unknown Source)
     at com.certicom.security.asn1.ASN1SequenceOf.decodeContents(Unknown
Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown
Source)
     at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown
Source)
     at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
     at com.certicom.security.pkix.Name.decodeContents(Unknown Source)
     at com.certicom.security.asn1.ASN1Choice.decode(Unknown Source)
     at com.certicom.security.pkix.TBSCertificate.decodeContents(Unknown
Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown
Source)
     at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown
Source)
     at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
     at com.certicom.security.pkix.Certificate.decodeContents(Unknown Source)
     at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown
Source)
     at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown
Source)
     at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
     at com.certicom.security.asn1.ASN1Type.decode(Unknown Source)
     at com.certicom.security.cert.internal.x509.X509V3CertImpl.<init>(Unknown
Source)
     at com.certicom.tls.record.handshake.MessageCertificate.<init>(Unknown
Source)
     at com.certicom.tls.record.handshake.HandshakeMessage.create(Unknown
Source)
     at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(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.net.ssl.CerticomContextWrapper.forceHandshakeOnAcceptedSocket(Unknown
Source)
     at weblogic.t3.srvr.SSLListenThread$1.execute(SSLListenThread.java:514)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
-----BEGIN CERTIFICATE-----
MIID+zCCAuOgAwIBAgIDFm/PMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkZJ
MRwwGgYDVQQKExNGdWppdHN1IFNlcnZpY2VzIE95MRgwFgYDVQQDEw9GdWppdHN1
IFRlc3QgQ0EwHhcNMDQwNjAyMTE1MjE4WhcNMDYwNjAyMTIyMjE4WjB3MQswCQYD
VQQGEwJGSTEQMA4GA1UEChMHRnVqaXRzdTEgMB4GA1UEAwwXSMO2bG3DtmzDpGlu
ZW4gw4VrZSAwMDExDDAKBgNVBAUTAzAwMTEXMBUGA1UEBAwOSMO2bG3DtmzDpGlu
ZW4xDTALBgNVBCoMBMOFa2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAO44
Zm31uJb8048/6PByPyXzaW3gCz1mT02TuwVtjMRJ4ObbFCqMGC+YosA2kNKoW0Ef
C+YlKNqhvaid0bATQefdSHVQhzFL3HFIfZc3ONAJQ/U+I6W69r2JePoCvZppknmC
YrnCCDx3Ap27B7v57f/XTmdpiB8IdiCTl3PnV78PAgMBAAGjggFEMIIBQDAfBgNV
HSMEGDAWgBT8T+xYc3T6j89O8cZ4hC9r1e9DojAdBgNVHQ4EFgQUtS4z8K26uW2d
IeJ3aelDnqnkBnYwCwYDVR0PBAQDAgSwMFMGA1UdEQRMMEqgKwYKKwYBBAGCNxQC
A6AdDBtha2UuaG9sbW9sYWluZW5AZnVqaXRzdS5jb22BG2FrZS5ob2xtb2xhaW5l
bkBmdWppdHN1LmNvbTB9BgNVHR8EdjB0MHKgcKBuhmxsZGFwOi8vMjEyLjI0Ni4y
MjIuMTQyOjM4OS9DTj1GdWppdHN1JTIwVGVzdCUyMENBLE89RnVqaXRzdSUyMFNl
cnZpY2VzJTIwVGVzdCxDPUZJP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3QwHQYD
VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQAZ
KV3Og/y6zUOMwZGswUxAne5fe4Ab70bmX+z49MVeA0dfdQwQdR9GwFVF+fcK+q0T
3Lmcwpm5KiHWYoIOxPb6MqTTWxV7HSXWr7A7P4BbTGxsujpUULcmQGQFAd69R0Ur
JFDwYnDEP2+4RzrvlP6AWspyHJePYmCt9h3JfxYAqVLTL0suO1uh8hgtStujmqsI
0WNCfnQ+sURdDzp6WpVFcxFQa5aAcyx9sWWqV5Ta5l6JTCmoHth7qoV3BtUKv4+z
SqIHKA1ixrvlhqWkjYxg51N6ihbbR5shBRRinAqRIQjTzXmun2wJzwNigt4zWiNg
tvrGCMOrvrb5QTxVtLNr
-----END CERTIFICATE-----

Odd SSL errors in webcache logs

Oracle application server 10.1.2.3 using ssl. Im seeing this in my event_log for webcache over and over. Dosent seem to be service impacting, just curious why im getting them?
[error 11321] [ecid: 130119394485,0] Connection from browser cannot be established.
[req-info] [ecid: 143004296375,0] [client: 140.251.214.222] [host: -] [url: -]
[warning 11904] [ecid: 143004296375,0] SSL handshake fails NZE-29014
Oracle error explination
NZE-29014: Maximum fragment length extension is incorrect.
Cause: The maximum fragment length extension specified is incorrect.
Action: Enable Oracle Net tracing and attempt the connection again. Contact Oracle customer support with the trace output.

Is your certificate expired?
There is an Oracle note 558640.1 take seems to be close to what you describe.
regards
mseberg
This is worth a look for sure:
244527.1
Edited by: mseberg on Feb 9, 2011 2:40 PM

How to do Handshake with tired party(bank) HTTPS URL from SAP PI server

Dear Expert,
I have developed bunch of scenarios, all are synchronous ABAP proxy to HTTP_AAE with bank on PI 7.4(dual stack). Bank web server is HTTPS enabled server. Our ABAP developments are still in progress also we have few issue in connection from ECC to PI.but that is not the focus of discussion here.
we want to do the handshake to check the connectivity with bank on their HTTPS URL from PI. Bank has provided the privet key for SSL from their server and corresponding public key they have maintained on their server. I have imported the private key under NWA -> Certificates -> Key Storage -> TrustedCA->Import Entry->Entry Type->PKCS#12->select the SSL.p12 file->import , also I have selected the option to "Use SSL" in HTTP_AAE receiver communication channel and selected the corresponding entryin "keystore view" and "keystore entry". All these I have done in our DEV system, and we are trying to connect our PI dev to bank Dev server.
Questions
Is there any specific steps to do the handshake with third party HTTPS(bank in my case) server? if not, how can we just test the HTTPS connectivity by using the SSL private installed on our PI server, without running the complete scenarios. Our PI has been installed on UNIX, and "telnet https url 443" is working, as network team has opened the HTTPS port.
We have not enabled the SSL technically on our PI server, and we have not installed any generated certificate from our PI server. Moreover, we have not made our PI url as "https:hostname:port" as we just need to communicate with bank by using their private key. Do you guys think we should enable the SSL? if yes, please explain why.
What is the best practice to test the connection with third party having HTTPS URL? how can I just assure HTTPS communication is working fine, before testing my actual scenarios.
Thanks for helping always.
Regards,
Farhan

Hi Farhan,
Some part of the blog is applicable for sending HTTPS request to partners/third party (Receiver SOAP Adapter).
If banks certificates are already in trustedCA, then, can you check if it also imported under user PIISuser under Identity management in NWA. If above 2 steps are done then i think your are good to go. But be careful when you install certificate, it should be in proper order.
As you already mentioned, connectivity is already established and you are able to PIng/telnet from pi server, connectivity looks ok.
While sending request, if you are getting 401 unauthorized, below might be the reason -
1. Certificate not installed correctly or some missing steps
2. Partner or TP is not ready to receive it, some certificate issue in there side.
other than 401 means you are ok (As per certificate and Connectivity) - 403 and 500 errors are next stops.
403 - error because of encoding method.
500 - data issue.
Regards
Aashish Sinha

SSL handshake failed: X509CertChainIncompleteErr - How to call secure WS?

Hi all, I'm trying to use a third party web service over SSL. I'm using jdk 1.5.0_11 and jDev 10.1.3.0.4.
Here is what I've done so far:
1 - I generated a web service proxy using jDev's wizard.
2 - I created a simple keystore with keytool with the following cmd:
keytool -genkey -keystore techdspc.keystore -storepass ****** . I copied the .keystore file in my project under the src directory.
3 - I used the wizard "Secure Proxy" on my web service with the following options:
- "Use x509 to authenticate"
- I specified my newly created keystore file as the keystore path as well as the password.
- I left the default choice to all the other options.
Once the files were all created by the wizard, I tried out the proxy and got the following error:
ATTENTION: Unable to connect to URL: https://test.eai.adpclaims.com/WSProxy/WS_Proxy.asmx due to java.security.PrivilegedActionException: javax.xml.soap.SOAPException: Message send failed: javax.net.ssl.SSLException: SSL handshake failed: X509CertChainIncompleteErr
java.rmi.RemoteException: ; nested exception is:
     HTTP transport error: javax.xml.soap.SOAPException: java.security.PrivilegedActionException: javax.xml.soap.SOAPException: Message send failed: javax.net.ssl.SSLException: SSL handshake failed: X509CertChainIncompleteErr
     at audatex3.runtime.WSProxySoap_Stub.transmit(WSProxySoap_Stub.java:679)
     at audatex3.WSProxySoapClient.transmit(WSProxySoapClient.java:83)
     at audatex3.WSProxySoapClient.main(WSProxySoapClient.java:43)
The owner of the Web Service told me that the error is without a doubt on the proxy side. Si my question is: What am I doing wrong?
Your help will be greatly appreciated.
thanks!

I tried generating an other keystore with a slightly different cmd and I still get the same error so this does not seem to be the problem...
Any ideas?¸
Thanks

Write Channel Closed, possible SSL handshaking or trust failure

Hi,
I Have a problem while working with Two-way SSL. I get Write Channel Closed, possible
SSL handshaking or trust failure error while contacting the server for invoking
a webservice secured by SSL.
I could figure out that the error is happening on client side while validating
the server certificate.
One more observation that i was able to find is, it works fine if the Server certificate
and the client certificate are signed by the same (root) CA.
I tried various options but couldn't find my luck. The BEA documentation in this
regards is not at all sufficient.
If i give strict checking false on my client end, the application works fine.
But for my scenario i want strict checking to be happend (otherwise there is no
point in going for SSL itself).
I am using WLSSLAdapter on my client side. The client application is a standalone
java class running out of weblogic (ideally running on JRun).
The way i have coded in my java class is:
String certificatePath = "C:/Cerificates/cert.pem";
          String caCertificatePath = "C:/Cerificates/clientca.pem";
          String targetURL = "https://localhost:443/feedservice/FeedService";
          //set weblogic ServiceFactory
          System.setProperty( "javax.xml.rpc.ServiceFactory",
          "weblogic.webservice.core.rpc.ServiceFactoryImpl" );
          System.setProperty("java.protocol.handler.pkgs","com.certicom.net.ssl");
          System.setProperty("https.cipherSuites","SHA1withRSA,MD5withRSA");
          SSLAdapterFactory sslFactory = SSLAdapterFactory.getDefaultFactory();
          WLSSLAdapter adapter = (WLSSLAdapter) sslFactory.getSSLAdapter();
          adapter.setProtocolVersion("SSL3");
          adapter.setStrictChecking(true);
          adapter.setVerbose(true);
          FileInputStream clientCredentialFile = new FileInputStream (certificatePath);
          String pwd = "password";
          System.out.println("Loding Certificate from ........"+certificatePath);
          adapter.loadLocalIdentity(clientCredentialFile, pwd.toCharArray());
          System.out.println("Loding CA Certificate from ........"+caCertificatePath);
          adapter.setTrustedCertificatesFile(caCertificatePath);
          // optionally set the Adapter factory to use this instance always.
          sslFactory.setDefaultAdapter(adapter);
          sslFactory.setUseDefaultAdapter(true);
          // Webservice invocation code..
          call.setTargetEndpointAddress(targetURL);
          call.setProperty("weblogic.webservice.client.ssladapter",adapter);
          Object result = call.invoke(new Object[]{"test.xml"});
The error that i get :
java.io.IOException: Write Channel Closed, possible SSL handshaking or trust failure
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireAlertSent(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(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:67)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:106)
at java.io.FilterOutputStream.write(FilterOutputStream.java:78)
at weblogic.webservice.binding.soap.HttpClientBinding.writeToStream(HttpClientBinding.java:359)
at weblogic.webservice.binding.soap.HttpClientBinding.send(HttpClientBinding.java:284)
at weblogic.webservice.core.handler.ClientHandler.handleRequest(ClientHandler.java:34)
at weblogic.webservice.core.HandlerChain.handleRequest(HandlerChain.java:131)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:421)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:363)
at weblogic.webservice.core.rpc.CallImpl.invoke(CallImpl.java:423)
at weblogic.webservice.core.rpc.CallImpl.invoke(CallImpl.java:292)
at com.chase.userspace.aceclient.Client.main(Client.java:253)
Exception in handler's handleRequest().
Exception in thread "main" javax.xml.rpc.soap.SOAPFaultException: Write Channel
Closed, possible SSL handshaking or trust fail
ure
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:479)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:363)
at weblogic.webservice.core.rpc.CallImpl.invoke(CallImpl.java:423)
at weblogic.webservice.core.rpc.CallImpl.invoke(CallImpl.java:292)
at com.chase.userspace.aceclient.Client.main(Client.java:253)
Can someone give the working phone number of ....BEA CUSTOMER SUPPORT...

The signature validation failure means your trusted CA certificate is not the issuer
of the identity certificate. The identity certificate issuer name can match to
the trusted CA certificate name, but the signature check really determines whether
it is the issuer.
Pavel.
"Chandra Sekhar Rao" <[email protected]> wrote:
>
Hi payal,
I have the issuer of the server identity certificate in the trust file
on client
side. The problem is with signature validation
"Pavel" <[email protected]> wrote:
It looks like your client does not trust the server certificate. Make
sure the
certificate you pass in adapter.setTrustedCertificatesFile(caCertificatePath);
is the issuer of the server's identity certificate.
Pavel.
"Chandra Sekhar Rao" <[email protected]> wrote:
Hi,
I Have a problem while working with Two-way SSL. I get Write Channel
Closed, possible
SSL handshaking or trust failure error while contacting the server
for
invoking
a webservice secured by SSL.
I could figure out that the error is happening on client side whilevalidating
the server certificate.
One more observation that i was able to find is, it works fine if the
Server certificate
and the client certificate are signed by the same (root) CA.
I tried various options but couldn't find my luck. The BEA documentation
in this
regards is not at all sufficient.
If i give strict checking false on my client end, the application works
fine.
But for my scenario i want strict checking to be happend (otherwisethere
is no
point in going for SSL itself).
I am using WLSSLAdapter on my client side. The client application is
a standalone
java class running out of weblogic (ideally running on JRun).
The way i have coded in my java class is:
String certificatePath = "C:/Cerificates/cert.pem";
          String caCertificatePath = "C:/Cerificates/clientca.pem";
          String targetURL = "https://localhost:443/feedservice/FeedService";
          //set weblogic ServiceFactory
          System.setProperty( "javax.xml.rpc.ServiceFactory",
          "weblogic.webservice.core.rpc.ServiceFactoryImpl" );
          System.setProperty("java.protocol.handler.pkgs","com.certicom.net.ssl");
          System.setProperty("https.cipherSuites","SHA1withRSA,MD5withRSA");
          SSLAdapterFactory sslFactory = SSLAdapterFactory.getDefaultFactory();
          WLSSLAdapter adapter = (WLSSLAdapter) sslFactory.getSSLAdapter();
          adapter.setProtocolVersion("SSL3");
          adapter.setStrictChecking(true);
          adapter.setVerbose(true);
          FileInputStream clientCredentialFile = new FileInputStream (certificatePath);
          String pwd = "password";
          System.out.println("Loding Certificate from ........"+certificatePath);
          adapter.loadLocalIdentity(clientCredentialFile, pwd.toCharArray());
          System.out.println("Loding CA Certificate from ........"+caCertificatePath);
          adapter.setTrustedCertificatesFile(caCertificatePath);
          // optionally set the Adapter factory to use this instance always.
          sslFactory.setDefaultAdapter(adapter);
          sslFactory.setUseDefaultAdapter(true);
          // Webservice invocation code..
          call.setTargetEndpointAddress(targetURL);
          call.setProperty("weblogic.webservice.client.ssladapter",adapter);
          Object result = call.invoke(new Object[]{"test.xml"});
The error that i get :
java.io.IOException: Write Channel Closed, possible SSL handshakingor
trust failure
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireAlertSent(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(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:67)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:106)
at java.io.FilterOutputStream.write(FilterOutputStream.java:78)
at weblogic.webservice.binding.soap.HttpClientBinding.writeToStream(HttpClientBinding.java:359)
at weblogic.webservice.binding.soap.HttpClientBinding.send(HttpClientBinding.java:284)
at weblogic.webservice.core.handler.ClientHandler.handleRequest(ClientHandler.java:34)
at weblogic.webservice.core.HandlerChain.handleRequest(HandlerChain.java:131)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:421)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:363)
at weblogic.webservice.core.rpc.CallImpl.invoke(CallImpl.java:423)
at weblogic.webservice.core.rpc.CallImpl.invoke(CallImpl.java:292)
at com.chase.userspace.aceclient.Client.main(Client.java:253)
Exception in handler's handleRequest().
Exception in thread "main" javax.xml.rpc.soap.SOAPFaultException: Write
Channel
Closed, possible SSL handshaking or trust fail
ure
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:479)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:363)
at weblogic.webservice.core.rpc.CallImpl.invoke(CallImpl.java:423)
at weblogic.webservice.core.rpc.CallImpl.invoke(CallImpl.java:292)
at com.chase.userspace.aceclient.Client.main(Client.java:253)
Can someone give the working phone number of ....BEA CUSTOMER SUPPORT...

Weblogic server 10.3.5 error during SSL handshake

Please some one help to figure the issue with following logs.
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <Filtering JSSE SSLSocket>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.addContext(ctx): 33092690>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <SSLSocket will be Muxing>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <Filtering JSSE SSLSocket>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.addContext(ctx): 33095418>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <SSLSocket will be Muxing>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <33092490 SSL Version data invalid>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <Connection to SSL port from Sa-PC - 150.1.104.124 appears to be either unknown SSL version or maybe is plaintext>
<16-Jan-2013 18:40:40 o'clock GMT> <Warning> <Security> <BEA-090476> <Invalid/unknown SSL header was received from peer Sa-PC - 150.1.104.124 during SSL handshake.>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <NEW ALERT with Severity: FATAL, Type: 70
java.lang.Exception: New alert stack
     at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)
     at com.certicom.tls.record.ReadHandler.getProtocolVersion(Unknown Source)
     at com.certicom.tls.record.ReadHandler.checkVersion(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 javax.net.ssl.impl.SSLSocketImpl.startHandshake(Unknown Source)
     at weblogic.server.channels.DynamicSSLListenThread$1.run(DynamicSSLListenThread.java:130)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <write ALERT, offset = 0, length = 2>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <close(): 33092490>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <close(): 33092490>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.removeContext(ctx): 33092690>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <33095215 SSL Version data invalid>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <Connection to SSL port from Sa-PC - 150.1.104.124 appears to be either unknown SSL version or maybe is plaintext>
<16-Jan-2013 18:40:40 o'clock GMT> <Warning> <Security> <BEA-090476> <Invalid/unknown SSL header was received from peer Sa-PC - 150.1.104.124 during SSL handshake.>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <NEW ALERT with Severity: FATAL, Type: 70
java.lang.Exception: New alert stack
     at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)
     at com.certicom.tls.record.ReadHandler.getProtocolVersion(Unknown Source)
     at com.certicom.tls.record.ReadHandler.checkVersion(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 javax.net.ssl.impl.SSLSocketImpl.startHandshake(Unknown Source)
     at weblogic.server.channels.DynamicSSLListenThread$1.run(DynamicSSLListenThread.java:130)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <write ALERT, offset = 0, length = 2>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <close(): 33095215>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <close(): 33095215>
<16-Jan-2013 18:40:40 o'clock GMT> <Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.removeContext(ctx): 33095418>
I just created domain with http and https ports. I installed an web app. When I am trying to access the app from browser through https the above error is occurring.
Please somebody help me.
Thanks in advance.
SK

This message indicates that the SSL connection is closed successfully. It is a warning message and normal to see in the logs when you enable the SSL debug flags. This is an expected behavior. If you see alerts when SSL debug is NOT ENABLED then it is a real alert and we need to take care of those issues. Also, it is not a real alert, it is a caught and handled exception from the certicom code which is not harmful and should be ignored, just because you have enabled the SSL debug flag. Once you turn it off, you won't see it in the logs.
Edited by: sharmela on Jan 22, 2013 4:55 AM

Possible SSL handshaking or trust failure in WLS 7.0

hi,
i have set Server Certificate File Name to democert.pem, Server Key File Name
to demokey.pem, and Server Certificate Chain File Name to ca.pem, using the demo
certificate. when running the client, i use -Dweblogic.webservice.client.ssl.strictcertchecking=false
from the cmd. still getting exception:
java.io.IOException: Write Channel Closed, possible SSL handshaking or trust failure
at com.certicom.tls.record.WriteHandler.write(Unknown Source) ...
i believe it no longer can be the wrong server name in the certificate, so it
must be the trusted CA's list. i cannot find any corresponding file though. what
should i be using for the Trusted CA File Name? i can access the webservices home
page by browser as well as the wsdl file, but once i try using the web service
methods, i get the same error through browser and with a soap client.
any ides?

Taime
add this setting also to start you Weblogic - Server - Instance include the strictcert
- setting. Then you can use your webservice from a http - client. I do it the
same way.
Regards
"taime giamzone" <[email protected]> wrote:
>
thanks markus,
now i can use the service through a java client! weird enough, by browser,
i still
get the same exception. has somebody succeeded in using a secure web
service by
browser?
"Markus Gasser" <[email protected]> wrote:
Hi Claudia , Hi Taime
I had the same problem. It was a hard way to find out. Here's the solution
Add -Dtrustedfile=<your path>\trusted.crt
to the vm parameters starting your wls - server or client.
The problem is, that WLS 7 expects a trusted ceritficate and the demo
certificate
isn't trusted.
You will find the trusted.crt normally in the domain directory
Markus
"Claudia" <[email protected]> wrote:
Hi,
I have the same problem. I followed the instructions from the Configuring
Security
side, but it doesn't work.
I tried to test the WebService with the default web page generated
from
weblogic
and there I figured out, that I have to enter the default realm password.
I supposed
that would be the password I use to start the server, but it wasn't.
Still I haven't
guessed the password.
The security works too goog ;-)
Please help.
Claudia

Unable to connect to internal SSL sites with unknown CA's after 36.0 update.

Last week my browser auto-updated to version 36.0 and I am now no longer able to connect to certain internal corporate websites. These sites either have self-signed certs, or certs signed by an internal CA. They do not use certs signed by publicly known "trusted" CA's.
For example, one of the errors that I receive is below:
Secure Connection Failed
An error occurred during a connection to [HOST]:[PORT]. SSL peer rejected a handshake message for unacceptable content. (Error code: ssl_error_illegal_parameter_alert)
Although a warning message is received in IE or Chrome we are given the option to proceed and the site opens correctly, despite those browsers also indicating that the servers cert is not trusted.
I have added the internal CA's cert to the Authorities tab in the Firefox Certificate Manager, but am still not able to connect to the internal site.
Firefox allows me to accept some incorrect certs (or at least it did in the past), why is this not the default behavior with *all* certificate related problems? I realize that there are malicious sites out there, but there are also internal ones that are being blocked as well. Is there a config option that can be set so a user is prompted for all cert errors and they can decide to proceed if desired instead of just being blocked from the site? I understand blocking by default, but there also needs to be a way to proceed for advanced users.
Are there any configuration options to loosen the cert standards for sites? All other sites seem to load properly and otherwise there are no problems with the browser.
Sorry if this is the wrong place to post, I wasn't sure where to.
Thanks for any assistance!
-Beaty

First, sorry for the delay in responding, things have been crazy here lately.
Secondly, here is the output from openSSL for connecting to the server:
OpenSSL> s_client -connect qrsa01.qnao.net:443
Loading 'screen' into random state - done
CONNECTED(00000180)
depth=1 CN = RSA root CA for qrsa01.qnao.net, serialNumber = 15702a01a563d5b8f2b
a65250ad81947eef537554eae2320efed2159a8193bd5
verify error:num=19:self signed certificate in certificate chain
Certificate chain
0 s:/CN=qrsa01.qnao.net/serialNumber=3b444eeb8355fb2b5b686d03ce1c0a61cd3552a184
001b9564700f7cebcbe9f0
i:/CN=RSA root CA for qrsa01.qnao.net/serialNumber=15702a01a563d5b8f2ba65250a
d81947eef537554eae2320efed2159a8193bd5
1 s:/CN=RSA root CA for qrsa01.qnao.net/serialNumber=15702a01a563d5b8f2ba65250a
d81947eef537554eae2320efed2159a8193bd5
i:/CN=RSA root CA for qrsa01.qnao.net/serialNumber=15702a01a563d5b8f2ba65250a
d81947eef537554eae2320efed2159a8193bd5
Server certificate
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIQYNRTnyH83tfcpTKMxP2kbTANBgkqhkiG9w0BAQUFADB1
MSgwJgYDVQQDDB9SU0Egcm9vdCBDQSBmb3IgcXJzYTAxLnFuYW8ubmV0MUkwRwYD
VQQFE0AxNTcwMmEwMWE1NjNkNWI4ZjJiYTY1MjUwYWQ4MTk0N2VlZjUzNzU1NGVh
ZTIzMjBlZmVkMjE1OWE4MTkzYmQ1MB4XDTEzMTExMTIxMTcwMloXDTMzMTExMjIx
MTcwMlowZTEYMBYGA1UEAwwPcXJzYTAxLnFuYW8ubmV0MUkwRwYDVQQFE0AzYjQ0
NGVlYjgzNTVmYjJiNWI2ODZkMDNjZTFjMGE2MWNkMzU1MmExODQwMDFiOTU2NDcw
MGY3Y2ViY2JlOWYwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwgkK
Lx1fAgNJsejbev9HP/j6I1quZH3oH4mQ5sy/Hx/F2yWXnf0vUFjclP8swte3OFA+
+okNqESCUDTZYHA4b3GCJDbzLKTWXOZ9GuZ8f2xAGbTYNEVdzTD2io0HBVwvd0O/
XGYn1vF1J+PghKJq40fQgdvVSJ2ZKeFc8U1yBRrEbL7/9XG7cgQxMkyzwdaWUg8k
9aGWn7ajSduJqYAb0NFbycZyY9JqKLRaI+L4bUyZZSUiDNV08dzPca7zDlA/G26K
mVfxdnQDp5sX6x7LMUDfo25gJVHOB7bp25/XCSASWBKG0BQx+Snl/mPmiY+00B6l
PTjyV4h3j2e4o255rQIDAQABoxAwDjAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB
BQUAA4IBAQCdUBdHPPmMzArZ8w5+FLoOo6VFA1gNDtOa+YDpt1H5K/ki0lO49W2v
vKDPC6J60gTnvwtNe7zT2l6QIEf/k1Ene+ZvWFmOW1Eco2cWnXaxEmbb3L1uxvid
6vMCWscKvbo0LRLrskAWhzionoziGazkt8XqM7prmlroH7n9keLyIFRFhbzSYKhp
q3Zd2Ys/7AFzwIGymTe8MncU1bYw5vYl5hvy8KR8t+qqz/DNBXDCQ2FPpEK9SWrT
7LF7iPrrCi0Zd8gSFkcCWWojCcOpk+FKU3Lo3geURvNypNZMihenuWPoTSn+PCE/
vJZCWnp7n2DDeDOBmNvaV2K2R5w81+xN
-----END CERTIFICATE-----
subject=/CN=qrsa01.qnao.net/serialNumber=3b444eeb8355fb2b5b686d03ce1c0a61cd3552a
184001b9564700f7cebcbe9f0
issuer=/CN=RSA root CA for qrsa01.qnao.net/serialNumber=15702a01a563d5b8f2ba6525
0ad81947eef537554eae2320efed2159a8193bd5
No client certificate CA names sent
SSL handshake has read 1948 bytes and written 675 bytes
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : RC4-SHA
Session-ID: 550194FCFA9BE4A1060430A13EBA67B9EBD793485253412053534C4A20202020
Session-ID-ctx:
Master-Key: F1FD3AB4846FBC14D35EB7BBAFF8704821940DDE5A0549519A0AFF2EC8CAF245
08DCAA6D4F9FB1D125664FC7BFE87E95
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1426167036
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
read:errno=0
OpenSSL>
I had already set the tls.security.version.min to 0, so would have expected to be able to connect.
At this point it seems like the problem is that we are using an internal CA to sign the cert for this server, but Firefox won't allow me to proceed despite this. Is there an option that I can set to have firefox prompt on all certificate issues and give me the option to proceed anyways?
Any other thoughts/suggestions?

Node Manager unable to start managed Server. SSL Handshake problem

I am getting the following Error:
weblogic.nodemanager.NodeManagerException: [Could not execute command start for server wecarebeadev via the Node Manager - reason: [CommandInvoker: Failed to send command: 'online to server 'wecarebeadev' to NodeManager at host: 'localhost:5555' with exception Write Channel Closed, possible SSL handshaking or trust failure. Please ensure that the NodeManager is active on the target machine].]
I have Weblogic Server 7.0 SP1 with Admin and Managed Server running on the same physical machine as Windows Services.
SSL port has been setup properly for Managed Server. Host Name Verification Ignored is checked for MS.

Hi Ajay,
This happens when the SSL communication between the admin and the node
manager fails. The SSL configuration of the admin server or the node
manager is the problem.
cheers,
gaurav.
On 30 Jun 2003 12:19:49 -0700, Ajay Kulkarni <[email protected]> wrote:
I am getting the following Error:
weblogic.nodemanager.NodeManagerException: [Could not execute command
start for server wecarebeadev via the Node Manager - reason:
[CommandInvoker: Failed to send command: 'online to server 'wecarebeadev'
to NodeManager at host: 'localhost:5555' with exception Write Channel
Closed, possible SSL handshaking or trust failure. Please ensure that the
NodeManager is active on the target machine].]
I have Weblogic Server 7.0 SP1 with Admin and Managed Server running on
the same physical machine as Windows Services.
SSL port has been setup properly for Managed Server. Host Name
Verification Ignored is checked for MS.
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

SSL handshake failed: X509CertChainIncompleteErr

I am trying to send name-value pairs using https and JSSE. I am using JDev 9i, and first I create a war file and bundle JSSE with it, then deploy it to an ear file, and use Enterprise Manager of 9iAS Rel2 to deploy the ear file to the server (on Windows 2000).
I get the following error (please excuse the test output lines):
Response: xxx test000+ test0+ test1+ test2+ test3+ test4+ test4a+
javax.net.ssl.SSLException: SSL handshake failed: X509CertChainIncompleteErr
Here's my code:
import java.net.*;
import java.io.*;
import com.sun.net.ssl.*;
public class testsend {
public testsend()
public String myTest () throws Exception {
String endresult = "xxx ";
String url = "https://www.mysite.com/myfile.php?" ;
endresult = endresult + "test000+ ";
// actual name-value pairs are sent out, this is just an example
String data = "name1=value1&name2=value2";
URL server = null;
try {
server = new URL(url);
endresult = endresult + "test0+ ";
catch(MalformedURLException e) {
endresult = endresult + e.getMessage();
ObjectInputStream myresponse = null;
Object result = null;
try {
URLConnection con = server.openConnection();
endresult = endresult + "test1+ ";
con.setDoOutput(true);
con.setUseCaches(false);
con.setRequestProperty("Content-Type", "application/octet-stream");
endresult = endresult + "test2+ ";
ObjectOutputStream request = new ObjectOutputStream(new BufferedOutputStream(con.getOutputStream()));
endresult = endresult + "test3+ ";
request.writeObject(data);
endresult = endresult + "test4+ ";
request.flush();
endresult = endresult + "test4a+ ";
request.close();
endresult = endresult + "test4b+ ";
// get the result input stream
myresponse = new ObjectInputStream(new BufferedInputStream(con.getInputStream()));
endresult = endresult + "test6+ ";
// read response back from the server
result = myresponse.readObject();
endresult = endresult + result.toString();
catch(Exception e) {
endresult = endresult + e.getMessage();
return endresult;
I've searched for the error message on the web but did not have much luck finding a solution. It obviously won't open a input stream.
Any one have any thoughts? Thanks.
jv

Hi Francisco,
I am(Oracle 9iAS) sending SOAP messages over SSL to a remote server(Microsoft IIS) hosting the web services. The remote HTTPS site is up and I can view the certificate. It has a 3 level chain. user certificate, intermediate and a root CA.
Through my application when I try to establish handshake, I have some code to display the certificate chain of the remote server. Here I see only the user and the intermediate certificate. I donot see the root CA. I understand that this is the reason for the Incomplete cert chain error. Is this something the remote server hosting the web services should do with their configuration?? Or can I do something at my end??
Please let me know,
Thank you

SSL Handshake Error in Android (ADF Mobile)

Hi Guys,
Now I am tried to using "https" Web service with my application, but seems show SSL handshake error specially in Android only, iOS is totally working.
Log from Android is
09-27 18:09:03.252: I/System.out(30444): [SEVERE - oracle.adfmf.framework - adf.mf.internal - logError] Request: {classname: oracle.adfmf.framework.api.Model; method: processBatchRequests; params: [0: false][1: [0: {classname: oracle.adfmf.framework.api.Model; method: evaluateMethodExpression; params: [0: #{bindings.AgentAuthenCDKey.execute}][1: [0: {.type: oracle.adfmf.amx.event.ActionEvent; }]][2: void][3: [0: oracle.adfmf.amx.event.ActionEvent]]; }]]; } exception: {message: SSL handshake failure; errorCode: 409; .type: oracle.adfmf.framework.exception.AdfInvocationRuntimeException; .exception: true; severity: ERROR; errorCategory: WEBSERVICE; }
How to solved this one ?
** If my android didn't connect to internet, it still show "SSL handshake error" too, that so weird !

Hi,
Sorry to bump this, but I have the exact same problem. "SSL Handshake Error" when calling SSL enabled web services - works fine on iOS, but not on Android, which implies to me a problem with the framework rather than my certificate?
: D/CVM(985): [SEVERE - oracle.adfmf.framework - Utility - invoke] InvocationTargetException Error: ERROR [oracle.adfmf.framework.exception.AdfInvocationRuntimeException] - SSL handshake failure
I'm on JDeveloper 11.1.2.4, ADF Mobile Framework 11.1.2.4.39.64.51.
Are there any known issues with ADF Mobile/SSL on Android?
Any help is much appreciated.
Rich.

SSL handshake error when calling Web Service

Hi Grant,
I am using your example here:
http://groundside.com/blog/GrantRonald.php?title=calling_a_web_service_from_oracle_forms__2&more=1&c=1&tb=1&pb=1
to call a web service from forms 10g on a machine with no proxies set up.
I get to the point where I click the button that calls this code:
DECLARE
     jo ora_java.jobject;
     xo ora_java.jobject;
     rv varchar2(100);
     --rv number;
     ex ora_java.jobject;
BEGIN
     jo := SendServiceSoapClient.new;
     rv := SendServiceSoapClient.sendMessage(jo,'07000000000', 'Test text message from Forms', xo, xo);
--     rv := SendServiceSoapClient.sendMessage(jo,:block6.number_to_text, :block6.text_msg, xo, xo);
EXCEPTION
     WHEN ORA_JAVA.JAVA_ERROR then
                    message('Unable to call out to Java, ' ||ORA_JAVA.LAST_ERROR);
     WHEN ORA_JAVA.EXCEPTION_THROWN then
                    ex := ORA_JAVA.LAST_EXCEPTION;
     --     message(Exception_.toString(ex));
     --     message(Exception_.toString(ex));
     :block6.item11 := Exception_.toString(ex);
END;
I then get the message:
java.rmi.RemoteException: ; nested exception is:
     HTTP transport error: javax.xml.soap.SOAPException: java.security.PrivilegedActionException: javax.xml.soap.SOAPException: Message send failed: javax.net.ssl.SSLException: SSL handshake failed: X509CertChainIncompleteErr
My Jinitiator box says:
Loading http://xpjdev11g.uk.conde-nast.biz:8889/forms/java/frmall_jinit.jar from JAR cache
Loading http://xpjdev11g.uk.conde-nast.biz:8889/forms/java/wsarchive3.jar from JAR cache
proxyHost=null
proxyPort=0
connectMode=HTTP, native.
Forms Applet version is : 10.1.2.0
Please note additional steps:
I have tried to sign my JAR file (called wsarchive3.jar) - not sure if I have it done it correctly??
I have added the JAR file in the system CLASSPATH
I have added the JAR file to formsweb.cfg
If you could help with the SSL error, I'd greatly appreciate it. Thanks.

Let me check - have you got the "HOW TO" I created working when you use the following WSDL
http://www.esendex.com/secure/messenger/soap/SendService.asmx?wsdl
Does this work ok from Forms?
The reason I ask is there is an HTTP web service (which is what the how to documents) but there is also and HTTPS versions - if you are getting errors about SSL it might be you are using the HTTPS version
I just want to make sure I understand what you have and have not working so far.
Grant

EAP-TLS or PEAP authentication failed during SSL handshake

Hi Pros,
I am a newbie in the ACS 4.2 and EAP-TLS implementation, with that being said. I face an issue during a EAP-TLS implementation. My search shows that this kind of error message is already certificate issue;However, I have deleted and recreated the certificate in both ACS and the client with the same result. I have deleted and re-install the certchain as well.
When I check my log in the failed attemps, there is what I found:
Date
Time
Message-Type
User-Name
Group-Name
Caller-ID
Network Access Profile Name
Authen-Failure-Code
Author-Failure-Code
Author-Data
NAS-Port
NAS-IP-Address
Filter Information
PEAP/EAP-FAST-Clear-Name
EAP Type
EAP Type Name
Reason
Access Device
Network Device Group
06/23/2010
17:39:51
Authen failed
000e.9b6e.e834
Default Group
000e.9b6e.e834
(Default)
EAP-TLS or PEAP authentication failed during SSL handshake
1101
10.111.22.24
25
MS-PEAP
wbr-1121-zozo-test
Office Networ
06/23/2010
17:39:50
Authen failed
[email protected]
Default Group
000e.9b6e.e834
(Default)
EAP-TLS or PEAP authentication failed during SSL handshake
1098
10.111.22.24
25
MS-PEAP
wbr-1121-zozo-test
Office Network
[email protected] = my windows active directory name
1. Why under EAP-TYPE it shows MS-PEAP not EAP-TLS? I did configure EAP-TLS....
2. Why sometimes it just shows the MAC of the client for username?
3. Why it puts me in DEFAULT-GROUP even though i belongs to a group well definy in the acs?
2. Secondly, When I check in pass authentications... there is what i saw
Date
Time
Message-Type
User-Name
Group-Name
Caller-ID
NAS-Port
NAS-IP-Address
Network Access Profile Name
Shared RAC
Downloadable ACL
System-Posture-Token
Application-Posture-Token
Reason
EAP Type
EAP Type Name
PEAP/EAP-FAST-Clear-Name
Access Device
Network Device Group
06/23/2010
17:30:49
Authen OK
groszozo
NOC Tier 2
10.11.10.105
1
10.111.22.24
(Default)
wbr-1121-zozo-test
Office Network
06/23/2010
17:29:27
Authen OK
groszozo
NOC Tier 2
10.11.10.105
1
10.111.22.24
(Default)
wbr-1121-zozo-test
Office Network
In the output below, it says that the user is authenticate and it puts the user in the right group with the right username, but the user never really authenticate. Maybe for the first few seconds when I initiate the connection.
Before I forget, the suppliant is using WIN XP and 802.1x is enable. I even uncheck not verify the server and the ACS under External User Databases, I did check ENABLE EAP-TLS machine authentication.
Thanks in advance for your help,
Crazy---

Any ideas on this guys?? In my end, i've been reading some docs... Things started to make sens to me, but I still cannot authenticate, still the same errors. One more thing that catch my attention now is the time it takes to open a telnet session to cisco device which has the ACS for auth server.
My AD(Active Direct) and the ACS server are local same subnet(server subnet). Ping to the ACS from my desktop which is in different subnet is only take 1ms. To confirm that the issue is the ACS server, I decided to use another server in remote location, the telnet connection is way faster than the local ACS.
Let's brain storm together to figure out this guys.
Thanks in advance,
----Paul

EAP-TLS or PEAP authentication failed due to unknown CA certificate during SSL handshake

Hi All ,
             I am trying to test EAP_TLS authentication on acs 4.2.1.15 running on Appliance 1120 , I have installed my server certficate along with CA certficate on my appliance box , I have enabled features of EAP_TLS under golbal authentication setup .
             I have downloaded client supplicant certficate file for my windows XP machine .
When i tried to authenticated i am finding following error message under failed attempts(EAP-TLS or PEAP authentication failed due to unknown CA certificate during SSL handshake) on my acs appliance box .
Under certficate revocation list , I have forced my CA as CRL in use . Attached snap shot of all .
Suggest me whether i need to enable all corresponding CA certficate undercertficate trust list , Kindly let me know were i am doing wrong on this ..

Hello,
I am NO expert on certificates but I have seen your error dozens of times from wireless clients on my Cisco ACS 4.2 Radius server.
Through trial and error I wrote up this procedure for our Helpdesk for installing certs in Windows XP and Windows 7. These steps haven't failed me yet and the Helpdesk doesn't bother me as much anymore so see if this helps you:
-          Manually install the Global CA under BOTH Trusted Root Certification Authorities\Certificates AND Intermediate Certification                      Authorities\Certificates
-          Manually install the Intermediate CA under JUST the Intermediate Certification Authorities\Certificates
-          Delete the wireless network from the computer
-          REBOOT!!
-          Open the Microsoft Management Console, “mmc”.
-          Go FILE\Add Remove SnapIn. Select Certificates ..
-          If promoted, do it for “My User Account”.
-          Make sure the certificates are where you put them.
-          If you see any of these exact certificates out of place in either Trusted Root Certification Authorities\Certificates or Intermediate Certification                      Authorities\Certificates, remove them.
-          Redo wireless network setup again
I hope this helps you.
Mike

SSL handshake with webcache

Similar Messages

Maybe you are looking for