Skip to main content

SSL Client Certificate Error with v3 but not v2 using LDAPS

1 reply [Last post]
Anonymous

Hi,

I have an application running in GlassFIsh that makes a connection to an
LDAP server using SSL and it works fine in GlassFish v2, but in v3 the SSL
handshake fails with the LDAP server reporting this error:

[25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - fd=69 slot=69
LDAPS connection from 10.171.11.11:47721 to 10.178.23.133
[25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - SSL error-8156
(Issuer certificate is invalid.); unauthenticated client
CN=sigma,OU=GlassFish,O=Oracle Corporation,L=Santa
Clara,ST=California,C=US; issuer CN=sigma,OU=GlassFish,O=Oracle
Corporation,L=Santa Clara,ST=California,C=US

The LDAP server is not configured to require client certificate
authentication, so I'm confused as to why a client certificate is being
sent? My understanding of the handshake is that it would only be sent if
the server requests it which it isn't doing.

Did something change between v2 and v3 in how the SSL handshake is done for
clients running in GlassFish and connecting to a resource using SSL? Is
there certain configuration that I need to check or verify in v3 that may
have defaulted to what works in v2 but not v3?

Thanks,

KEvin

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Quang Dang

Hi,

How does your application obtain the SSL socket/connection? Have you
tried setting the system property -Djavax.net.debug=ssl on the client
side to get more debug output?
Quang

On 9/27/12 1:22 AM, Kevin Schmidt wrote:
> Hi,
>
> I have an application running in GlassFIsh that makes a connection to
> an LDAP server using SSL and it works fine in GlassFish v2, but in v3
> the SSL handshake fails with the LDAP server reporting this error:
>
> [25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - fd=69
> slot=69 LDAPS connection from 10.171.11.11:47721
> to 10.178.23.133
> [25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - SSL
> error-8156 (Issuer certificate is invalid.); unauthenticated client
> CN=sigma,OU=GlassFish,O=Oracle Corporation,L=Santa
> Clara,ST=California,C=US; issuer CN=sigma,OU=GlassFish,O=Oracle
> Corporation,L=Santa Clara,ST=California,C=US
>
> The LDAP server is not configured to require client certificate
> authentication, so I'm confused as to why a client certificate is
> being sent? My understanding of the handshake is that it would only
> be sent if the server requests it which it isn't doing.
>
> Did something change between v2 and v3 in how the SSL handshake is
> done for clients running in GlassFish and connecting to a resource
> using SSL? Is there certain configuration that I need to check or
> verify in v3 that may have defaulted to what works in v2 but not v3?
>
> Thanks,
>
> KEvin

Kevin Schmidt

Quang,

Thanks for the response.

I did get the more debug output, and compared it when connecting from
within GlassFish with the output from a Java client doing the same and saw
it was a bit different.

After the ServerHelloDone, the GlassFish v3 debug output displays the
default self-signed certificate that is in its keystore, the Java client
output not displaying any certificate chain. So, as part of the SSL
handshake, is GlassFish going to send this self-signed cert simply because
it exists in the keystore even if it wasn't requested for client-cert
authentication? And did this change between v2 and v3?

If it does send it regardless, since it is the self-signed cert, is the
LDAP server (Oracle Directory Server 6.3) going to reject it solely because
it is self-signed even though it isn't doing client-cert authentication?

Thanks,

Kevin

On Thu, Sep 27, 2012 at 7:10 AM, Quang Dang wrote:

>
> Hi,
>
> How does your application obtain the SSL socket/connection? Have you
> tried setting the system property -Djavax.net.debug=ssl on the client side
> to get more debug output?
> Quang
>
>
>
>
> On 9/27/12 1:22 AM, Kevin Schmidt wrote:
>
> Hi,
>
> I have an application running in GlassFIsh that makes a connection to an
> LDAP server using SSL and it works fine in GlassFish v2, but in v3 the SSL
> handshake fails with the LDAP server reporting this error:
>
> [25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - fd=69 slot=69
> LDAPS connection from 10.171.11.11:47721 to 10.178.23.133
> [25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - SSL error-8156
> (Issuer certificate is invalid.); unauthenticated client
> CN=sigma,OU=GlassFish,O=Oracle Corporation,L=Santa
> Clara,ST=California,C=US; issuer CN=sigma,OU=GlassFish,O=Oracle
> Corporation,L=Santa Clara,ST=California,C=US
>
> The LDAP server is not configured to require client certificate
> authentication, so I'm confused as to why a client certificate is being
> sent? My understanding of the handshake is that it would only be sent if
> the server requests it which it isn't doing.
>
> Did something change between v2 and v3 in how the SSL handshake is done
> for clients running in GlassFish and connecting to a resource using SSL?
> Is there certain configuration that I need to check or verify in v3 that
> may have defaulted to what works in v2 but not v3?
>
> Thanks,
>
> KEvin
>
>
>

Quang Dang

Kevin,

I did some tracing in the relevant SSL code and it looks like GF
initializes an SSLContext object using the identity specified by the
"com.sun.enterprise.security.httpsOutboundKeyAlias" alias for outbound
HTTPS connections.
The code then sets that SSLContext to be the default SSLContext(
javax.net.ssl.SSLContext.setDefault(SSLContext) )
If your LDAP client creates SSLSockets from that new default SSLContext,
it'll have that identity.
As to why the client then sends its certificate even if the LDAP server
never asks for it at all, that's not GF behavior but rather the
underlying JSSE implementation(SunJSSE in this case).
I'd double check the LDAP server setting to be sure it will not request
for optional client certificates.
Quang

On 9/27/12 4:27 PM, Kevin Schmidt wrote:
> Quang,
>
> Thanks for the response.
>
> I did get the more debug output, and compared it when connecting from
> within GlassFish with the output from a Java client doing the same and
> saw it was a bit different.
>
> After the ServerHelloDone, the GlassFish v3 debug output displays the
> default self-signed certificate that is in its keystore, the Java
> client output not displaying any certificate chain. So, as part of
> the SSL handshake, is GlassFish going to send this self-signed cert
> simply because it exists in the keystore even if it wasn't requested
> for client-cert authentication? And did this change between v2 and v3?
>
> If it does send it regardless, since it is the self-signed cert, is
> the LDAP server (Oracle Directory Server 6.3) going to reject it
> solely because it is self-signed even though it isn't doing
> client-cert authentication?
>
> Thanks,
>
> Kevin
>
> On Thu, Sep 27, 2012 at 7:10 AM, Quang Dang > wrote:
>
>
> Hi,
>
> How does your application obtain the SSL socket/connection? Have
> you tried setting the system property -Djavax.net.debug=ssl on the
> client side to get more debug output?
> Quang
>
>
>
>
> On 9/27/12 1:22 AM, Kevin Schmidt wrote:
>> Hi,
>>
>> I have an application running in GlassFIsh that makes a
>> connection to an LDAP server using SSL and it works fine in
>> GlassFish v2, but in v3 the SSL handshake fails with the LDAP
>> server reporting this error:
>>
>> [25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - fd=69
>> slot=69 LDAPS connection from 10.171.11.11:47721
>> to 10.178.23.133
>> [25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - SSL
>> error-8156 (Issuer certificate is invalid.); unauthenticated client
>> CN=sigma,OU=GlassFish,O=Oracle Corporation,L=Santa
>> Clara,ST=California,C=US; issuer CN=sigma,OU=GlassFish,O=Oracle
>> Corporation,L=Santa Clara,ST=California,C=US
>>
>> The LDAP server is not configured to require client certificate
>> authentication, so I'm confused as to why a client certificate is
>> being sent? My understanding of the handshake is that it would
>> only be sent if the server requests it which it isn't doing.
>>
>> Did something change between v2 and v3 in how the SSL handshake
>> is done for clients running in GlassFish and connecting to a
>> resource using SSL? Is there certain configuration that I need
>> to check or verify in v3 that may have defaulted to what works in
>> v2 but not v3?
>>
>> Thanks,
>>
>> KEvin
>
>

Quang Dang

I'm not sure what exactly changed between GF 2 & 3 in that area but I
think this has to do with how the ssl socket used by the ldap client was
created.
Did you use com.sun.jndi.ldap.LdapCtxFactory for the outbound ldap over
SSL connection?
My guess is that your LDAP server might have been configured to ask the
clients to *optionally* provide a certificate, otherwise the client
wouldn't have just blindly sent a cert.

Quang

On 9/27/12 4:27 PM, Kevin Schmidt wrote:
> Quang,
>
> Thanks for the response.
>
> I did get the more debug output, and compared it when connecting from
> within GlassFish with the output from a Java client doing the same and
> saw it was a bit different.
>
> After the ServerHelloDone, the GlassFish v3 debug output displays the
> default self-signed certificate that is in its keystore, the Java
> client output not displaying any certificate chain. So, as part of
> the SSL handshake, is GlassFish going to send this self-signed cert
> simply because it exists in the keystore even if it wasn't requested
> for client-cert authentication? And did this change between v2 and v3?
>
> If it does send it regardless, since it is the self-signed cert, is
> the LDAP server (Oracle Directory Server 6.3) going to reject it
> solely because it is self-signed even though it isn't doing
> client-cert authentication?
>
> Thanks,
>
> Kevin
>
> On Thu, Sep 27, 2012 at 7:10 AM, Quang Dang > wrote:
>
>
> Hi,
>
> How does your application obtain the SSL socket/connection? Have
> you tried setting the system property -Djavax.net.debug=ssl on the
> client side to get more debug output?
> Quang
>
>
>
>
> On 9/27/12 1:22 AM, Kevin Schmidt wrote:
>> Hi,
>>
>> I have an application running in GlassFIsh that makes a
>> connection to an LDAP server using SSL and it works fine in
>> GlassFish v2, but in v3 the SSL handshake fails with the LDAP
>> server reporting this error:
>>
>> [25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - fd=69
>> slot=69 LDAPS connection from 10.171.11.11:47721
>> to 10.178.23.133
>> [25/Sep/2012:20:16:09 -0400] conn=8346156 op=-1 msgId=-1 - SSL
>> error-8156 (Issuer certificate is invalid.); unauthenticated client
>> CN=sigma,OU=GlassFish,O=Oracle Corporation,L=Santa
>> Clara,ST=California,C=US; issuer CN=sigma,OU=GlassFish,O=Oracle
>> Corporation,L=Santa Clara,ST=California,C=US
>>
>> The LDAP server is not configured to require client certificate
>> authentication, so I'm confused as to why a client certificate is
>> being sent? My understanding of the handshake is that it would
>> only be sent if the server requests it which it isn't doing.
>>
>> Did something change between v2 and v3 in how the SSL handshake
>> is done for clients running in GlassFish and connecting to a
>> resource using SSL? Is there certain configuration that I need
>> to check or verify in v3 that may have defaulted to what works in
>> v2 but not v3?
>>
>> Thanks,
>>
>> KEvin
>
>