The SSL client won't know the server's certificate requirement until the
handshake occurs. During the handshake, the server may or may not ask
for the client's cert at all depending
on its setting. If the server's client-auth setting is "required" or
"allowed", then it'll ask the client for a certificate. If the client
has an identity certificate, it'll send it.
Normally in JSSE, the default SSLContext is initialized with an empty
KeyStore(e.g. no outbound identity certificate), unless the system
property javax.net.ssl.keyStore is specified.
Since 3.1, GlassFish overwrites the default SSLContext with a custom
one, which has an outbound identity certificate.
The behavior is correct for JSSE to send a certificate when the server's
setting is "allowed".
There is no property or configuration setting to disable the overwriting
of the default SSLContext by GlassFish.
If you feel it'd make sense to have an option not to overwrite the
default SSL context, please file a JIRA request.
Quang
On 10/3/12 7:31 PM, Kevin Schmidt wrote:
> Thanks for the all the help.
>
> What we discovered is that the LDAP server (Oracle Directory Server
> 6.3) had client-auth set to "allowed" rather than "off" and GlassFIsh
> 3 and its KeyManager seems to send the cert in this case. When it was
> changed to "off" then the cert isn't sent and things work.
>
> So, is the correct behavior for the KeyManager to send the cert when
> the setting is just "allowed" rather than "required"? Is there some
> config or a setting we can use to disable sending the cert when it is
> "allowed"?
>
> We are also going to look into getting a valid cert that the LDAP
> server will trust which should solve it too.
>
> On Fri, Sep 28, 2012 at 3:05 PM, Quang Dang <quang.dang_at_oracle.com
> <mailto:quang.dang_at_oracle.com>> wrote:
>
>
>
> The custom KeyManager in GlassFish,
> com.sun.enterprise.security.ssl.J2EEKeyManager, has been there
> prior to GF 3.
> It is used to handle keystores with multiple entries.
> However in 3.1, there was a change to set the default JVM-wide
> SSLContext to the one initialized for outbound HTTPS connections.
> This change would affect any code that uses the default
> SSLContext(such as calling
> javax.net.ssl.SSLSocketFactory.getDefault().createSocket())
> I think this change is related to the handshake error you're seeing.
> No, it's not possible to disable the custom KeyManager wrapper in
> favor of the default onevia configuration given the way it's coded.
> (Even if it can be disabled, that'll definitely cause problems for
> starting the server).
> Hopefully the setting in your ldap server can be changed to
> disable client cert requests.
> Quang
>
>
>
>
> On 9/28/12 12:09 PM, Kevin Schmidt wrote:
>> Quang,
>>
>> Thanks for the responses.
>>
>> Per your earlier question, yes, I am
>> using com.sun.jndi.ldap.LdapCtxFactory. And I am checking with
>> the LDAP server administrator on its configuration.
>>
>> But what you just sent reminded me of something else different in
>> the SSL debug output. I am running GlassFish on AIX and so using
>> the IBM JRE. Using GlassFish v2 there is a line:
>>
>> ClientHandshaker: KeyManager com.ibm.jsse2.wc
>>
>> While on GlassFish v3 it is:
>>
>> ClientHandshaker: KeyManager
>> com.sun.enterprise.security.ssl.J2EEKeyManager
>>
>> I'm guessing this difference in the key manager being used could
>> be the reason for the different behavior? Is it the case that v2
>> uses the JVM's default key manager (com.ibm.jsse2.wc) but v3
>> specifies a specific/custom one
>> (com.sun.enterprise.security.ssl.J2EEKeyManager)? Is there a way
>> to get v3 to use the default/IBM one?
>>
>> Thanks,
>>
>> Kevin
>>
>> On Fri, Sep 28, 2012 at 8:59 AM, Quang Dang
>> <quang.dang_at_oracle.com <mailto:quang.dang_at_oracle.com>> wrote:
>>
>>
>> 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
>>> <quang.dang_at_oracle.com <mailto:quang.dang_at_oracle.com>> 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 <http://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
>>>
>>>
>>
>>
>
>