LDAPS error

[swarsa]

I have been porting a working app over from WebSphere 7 to JBoss EAP 7.  I have the most of the thing working now after facing and overcoming many challenges.  Now, as I promote this app up in our environment at my company from DEV to TEST, some of the things I'm connecting to are changing.  The one thing that changed is the ldap URL for example in my JNDI properties - in DEV it was:

<config-property name="JndiProperties">java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,java.naming.provider.url=ldap://xxx-xxx-yyy.zzzz.aaa:389</config-property>

But now in the TEST tier, it is:

<config-property name="JndiProperties">java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,java.naming.provider.url=ldaps://xxx-xxx-yyy.zzzz.aaa:636</config-property>

I was getting an error during the JMS lookup of the QueueConnectionFactory like this: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Then I figured that was related to not having the certificate for the ldap server.  So, I imported the certificate into the jre's cacerts keystore using the following command:

<JAVA_HOME>\jdk1.8.0_112\bin> keytool -import -trustcacerts -alias ldap_test -file <cert-path>/ldap.cert -keystore ..\jre\lib\security\cacerts

Then I reran my JMS scenario and now I'm getting a different error (normally a good thing): Caused by: javax.naming.ServiceUnavailableException: xxx-xxx-yyy.zzzz.aaa:636; socket closed; remaining name 'cn=MyQueueConnectionFactory,ou=xxx-yyy-zzz,ou=xxxxYYYY,ou=xxx,dc=xxx,dc=xxxx'

So, now I'm wondering if maybe if done something wrong or missed something.

Again, this same configuration data is working in JBoss EAP 7 when pointed to a non-SSL ldap location.  It is also working in WebSphere 7 with the same configuration data pointing to the SSL ldap location.

Has anyone done this?

Thanks,

Steve

[mchoma]

Try to run EAP with -Djavax.net.debug=all to see ssl handshake details. But I wonder is there chance your LDAP server is configured for requesting certificate from client to authenticate?

[andey]

This happens because the service you are calling is secured with TLS/SSL but the server certificate is not considered trusted. You need to download the server certificate and add it to an appropriate truststore. If you are not configuring TLS/SSL programmatically you can just import the server certificate into $JAVA_HOME/jre/lib/security/cacerts.

Alternatively, you can import the server certificate into a new keystore and configure the keystore as the default truststore in Java with the system property javax.net.ssl.trustStore. You can do this in EAP by adding the following to $JBOSS_HOME/bin/standalone.conf:

  JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=/path/to/keystore"

So, usually you either need to add their certificate to your truststore, or your truststore has the certificate but the truststore is in the wrong location or you are using the wrong truststore so that the certificate is not being found. See this article[1] for more details:

Why does my Java application throw a SSLHandshakeException: "unable to find valid certification path to requested target…

[swarsa]

Thanks for the reply - I added that debugging and got a lot of messages I don't understand.  I will paste relevant details as a reply to this whole thread.

[swarsa]

Thanks - I did add the cert to the cacerts keystore using this command:

<JAVA_HOME>\jdk1.8.0_112\bin> keytool -import -trustcacerts -alias ldap_test -file <cert-path>/ldap.cert -keystore ..\jre\lib\security\cacerts

But after that I was still getting the error.  I now added some debug logging as suggested by another person and got a whole bunch of messages I don't understand.  I will post those as a reply to the original post.

[swarsa]

As suggested by Martin Choma, I've added debug logging using "-Djavax.net.debug=ssl,handshake".  Now, I get a whole bunch of logging that I don't really understand.  Here is what I think is the relevant logging just prior to the error happening:

2017-03-21 09:45:54,957 INFO  [stdout] (Thread-99) ***

2017-03-21 09:45:54,968 INFO  [stdout] (Thread-99) Found trusted certificate:

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) [

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) [

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   Version: V3

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   Subject: CN=zzzzzzzzz, O=yyyyyyyy, C=US

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   Key:  Sun RSA public key, 1024 bits

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   modulus: 149768031229355317819669627003541010970188409896072123942659823055749257442913555306139263532680887521476069480498423244630043039059932665046536606777806669151992913044418121042873068648955756669726859500240051803178353300912112534643112797025626661774438729388377935143233681906223561041770767373053814591257

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   public exponent: 65537

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   Validity: [From: Wed Jun 07 15:39:09 MST 2006,

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)                To: Tue Apr 14 15:39:09 MST 2026]

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   Issuer: CN=zzzzzzzzzz, O=yyyyyyyyy, C=US

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   SerialNumber: [    4488a70d]

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) ]

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   Algorithm: [MD5withRSA]

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)   Signature:

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) 0000: 7E FD B5 99 18 7C 58 B6   19 63 80 EA 16 8B 1F BD  ......X..c......

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) 0010: 2F 23 B9 ED 91 53 B4 11   6F 35 B4 02 F5 24 D6 EE  /#...S..o5...$..

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) 0020: BA 3E 5B FA BC 0D 74 9E   43 02 BE A9 D7 5B B6 71  .>[...t.C....[.q

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) 0030: 99 C8 F9 40 B6 C1 04 E8   35 AA 3E 40 30 66 65 FC  ...@....5.>@0fe.

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) 0040: 4A 4B 8A 9B B7 C9 B7 93   F6 C5 57 03 DE 9C F4 7F  JK........W.....

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) 0050: 91 92 1E 17 F4 1D 17 4A   80 11 61 85 B0 06 5D 8C  .......J..a...].

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) 0060: 25 C0 56 E9 6F DB 80 35   94 0D BF 53 85 1E D5 15  %.V.o..5...S....

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) 0070: 61 9F BA B5 6F 1F 5E 00   E7 43 76 41 C1 01 E4 F1  a...o.^..CvA....

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99)

2017-03-21 09:45:54,969 INFO  [stdout] (Thread-99) ]

2017-03-21 09:45:54,970 INFO  [stdout] (Thread-99) *** ServerHelloDone

2017-03-21 09:45:54,973 INFO  [stdout] (Thread-99) *** ClientKeyExchange, RSA PreMasterSecret, TLSv1.1

2017-03-21 09:45:54,973 INFO  [stdout] (Thread-99) Thread-99, WRITE: TLSv1.1 Handshake, length = 134

2017-03-21 09:45:54,973 INFO  [stdout] (Thread-99) SESSION KEYGEN:

2017-03-21 09:45:54,973 INFO  [stdout] (Thread-99) PreMaster Secret:

2017-03-21 09:45:54,974 INFO  [stdout] (Thread-99) 0000: 03 03 B0 FE B7 4F C0 4D   8F 0F C3 1C CF 5F A8 ED  .....O.M....._..

2017-03-21 09:45:54,974 INFO  [stdout] (Thread-99) 0010: 80 89 5B 6D 6F CD 6D 64   CC E1 48 7D 29 3A C0 86  ..[mo.md..H.):..

2017-03-21 09:45:54,975 INFO  [stdout] (Thread-99) 0020: 9E 72 06 52 07 86 EA DC   AC BB 39 55 D1 0E 69 79  .r.R......9U..iy

2017-03-21 09:45:54,980 INFO  [stdout] (Thread-99) CONNECTION KEYGEN:

2017-03-21 09:45:54,980 INFO  [stdout] (Thread-99) Client Nonce:

2017-03-21 09:45:54,980 INFO  [stdout] (Thread-99) 0000: 58 D1 58 C2 5C 2A 29 17   C9 D6 D9 4A 08 21 DE 42  X.X.\*)....J.!.B

2017-03-21 09:45:54,980 INFO  [stdout] (Thread-99) 0010: 5E 0D 7B 88 6D 4D 04 5E   49 6F 40 84 9B 1C AC E5  ^...mM.^Io@.....

2017-03-21 09:45:54,981 INFO  [stdout] (Thread-99) Server Nonce:

2017-03-21 09:45:54,981 INFO  [stdout] (Thread-99) 0000: 00 00 00 C2 8B A1 1C B7   A6 DC A0 10 D8 39 EE 21  .............9.!

2017-03-21 09:45:54,982 INFO  [stdout] (Thread-99) 0010: 2F 7F FC 66 9B 1D B8 E1   A7 27 62 66 1E E3 36 D4  /..f.....'bf..6.

2017-03-21 09:45:54,982 INFO  [stdout] (Thread-99) Master Secret:

2017-03-21 09:45:54,983 INFO  [stdout] (Thread-99) 0000: 80 CF C9 67 A8 D5 26 36   25 87 B8 01 3E 4D 30 0B  ...g..&6%...>M0.

2017-03-21 09:45:54,983 INFO  [stdout] (Thread-99) 0010: 7C DB 55 3C FF 3E 6F 33   BA E3 1C 89 A1 41 8F 61  ..U<.>o3.....A.a

2017-03-21 09:45:54,984 INFO  [stdout] (Thread-99) 0020: BA DB 3C B5 03 A4 6C 6B   F0 EE 2A 3B 72 F6 79 0D  ..<...lk..*;r.y.

2017-03-21 09:45:54,984 INFO  [stdout] (Thread-99) Client MAC write Secret:

2017-03-21 09:45:54,985 INFO  [stdout] (Thread-99) 0000: 42 82 CB C4 68 EE 6A 20   14 97 26 90 D8 B7 A5 28  B...h.j ..&....(

2017-03-21 09:45:54,985 INFO  [stdout] (Thread-99) 0010: 2C 5C 58 C0                                        ,\X.

2017-03-21 09:45:54,985 INFO  [stdout] (Thread-99) Server MAC write Secret:

2017-03-21 09:45:54,986 INFO  [stdout] (Thread-99) 0000: CC F4 2C 49 F0 53 79 22   99 8E 09 0F E2 43 0A DD  ..,I.Sy".....C..

2017-03-21 09:45:54,986 INFO  [stdout] (Thread-99) 0010: A2 A5 F1 F4                                        ....

2017-03-21 09:45:54,986 INFO  [stdout] (Thread-99) Client write key:

2017-03-21 09:45:54,987 INFO  [stdout] (Thread-99) 0000: D0 48 B8 BA 89 C6 72 C4   92 BB 3B D8 7D 1B 00 BF  .H....r...;.....

2017-03-21 09:45:54,987 INFO  [stdout] (Thread-99) Server write key:

2017-03-21 09:45:54,988 INFO  [stdout] (Thread-99) 0000: 8A B9 E0 2C DD B9 DA 97   02 02 C0 63 9D 7A 2F A5  ...,.......c.z/.

2017-03-21 09:45:54,988 INFO  [stdout] (Thread-99) ... no IV derived for this protocol

2017-03-21 09:45:54,989 INFO  [stdout] (Thread-99) Thread-99, WRITE: TLSv1.1 Change Cipher Spec, length = 1

2017-03-21 09:45:54,991 INFO  [stdout] (Thread-99) *** Finished

2017-03-21 09:45:54,991 INFO  [stdout] (Thread-99) verify_data:  { 72, 68, 241, 201, 139, 148, 155, 212, 114, 170, 87, 236 }

2017-03-21 09:45:54,991 INFO  [stdout] (Thread-99) ***

2017-03-21 09:45:54,991 INFO  [stdout] (Thread-99) Thread-99, WRITE: TLSv1.1 Handshake, length = 64

2017-03-21 09:45:54,992 INFO  [stdout] (Thread-99) Thread-99, READ: TLSv1.1 Change Cipher Spec, length = 1

2017-03-21 09:45:54,993 INFO  [stdout] (Thread-99) Thread-99, READ: TLSv1.1 Handshake, length = 64

2017-03-21 09:45:54,994 INFO  [stdout] (Thread-99) *** Finished

2017-03-21 09:45:54,994 INFO  [stdout] (Thread-99) verify_data:  { 81, 220, 109, 100, 71, 72, 36, 254, 157, 248, 81, 248 }

2017-03-21 09:45:54,994 INFO  [stdout] (Thread-99) ***

2017-03-21 09:45:54,995 INFO  [stdout] (Thread-99) %% Cached client session: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]

2017-03-21 09:45:54,995 INFO  [stdout] (default task-54) default task-54, WRITE: TLSv1.1 Application Data, length = 192

2017-03-21 09:45:54,999 INFO  [stdout] (Thread-99) Thread-99, received EOFException: ignored

2017-03-21 09:45:54,999 INFO  [stdout] (Thread-99) Thread-99, called closeInternal(false)

2017-03-21 09:45:54,999 INFO  [stdout] (Thread-99) Thread-99, SEND TLSv1.1 ALERT:  warning, description = close_notify

2017-03-21 09:45:55,000 INFO  [stdout] (Thread-99) Thread-99, WRITE: TLSv1.1 Alert, length = 48

2017-03-21 09:45:55,000 INFO  [stdout] (Thread-99) Thread-99, called closeSocket(false)

2017-03-21 09:45:55,000 INFO  [stdout] (Thread-99) Thread-99, called close()

2017-03-21 09:45:55,000 INFO  [stdout] (Thread-99) Thread-99, called closeInternal(true)

2017-03-21 09:45:55,003 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (default task-54) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: zzzzzzzzzzzzzz:636; socket closed

Any clue what all this means?

[swarsa]

I enabled some additional logging (-Dcom.sun.net.ssl.requireCloseNotify=true) and now seeing this in my logs:

2017-03-21 11:05:04,196 INFO  [stdout] (Thread-99) Thread-99, received EOFException: error

2017-03-21 11:05:04,196 INFO  [stdout] (Thread-99) Thread-99, handling exception: javax.net.ssl.SSLProtocolException: Remote host closed connection incorrectly

2017-03-21 11:05:04,197 INFO  [stdout] (Thread-99) %% Invalidated:  [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]

2017-03-21 11:05:04,197 INFO  [stdout] (Thread-99) Thread-99, SEND TLSv1.1 ALERT:  fatal, description = unexpected_message

Interestingly enough I found this bug report that seems to describe my issue (title=IBM Tivoli LDAP server unexpectedly closing SSL socket on Oracle JDK):

https://bugs.openjdk.java.net/browse/JDK-8065236

The link seems to indicate that the error only happens on Oracle JDK, but works on IBM JDK.  At the end of the article, it had the following statement:

Turns out that the LDAP server was not able to handle packet splitting. Packet splitting was introduced to combat a TLS issue with CBC based ciphersuites from a few years ago. Server will need to be fixed up. Reverting to the old behaviour is possible via setting a system property : -Djsse.enableCBCProtection=false

However, that didn't work for me.

[mchoma]

From debug message it seems to me SSL handhake is performed succesfully.

So seems to me the problem could be a next application protocol.

I am just curious:

- does whole debug log contains "CertificateRequest" string?

- Is IBM Tivoli LDAP java process? If yes, what is java version used? Try to set on LDAP server side -Djsse.enableCBCProtection=false

- Try to use TLSv1.2

[swarsa]

Hello Martin, thanks for the answer.  To give the specific answers:

- does whole debug log contains "CertificateRequest" string? (No, the debug log does not contain the string CertificateRequest)

- Is IBM Tivoli LDAP java process? If yes, what is java version used? Try to set on LDAP server side -Djsse.enableCBCProtection=false (IBM Tivoli LDAP is not a local process - it is used by the whole enterprise and probably will not be changed for this one JBoss app)

- Try to use TLSv1.2 (that sounds like an interesting idea - do you know how I can do it?  Also, just to clarify, I'm already using JDK 1.8, which, from what I hear, is supposed to be using TLSv1.2 by default, however it is obviously not using that in my case)

[caopei00825]

Hello, thanks for your previous answer last week. But another question is that whether it is legal or not to own software like VLC DVD Ripper  in that country, sure no copyright protection law?