[GLASSFISH-18175] The key-store, trust-store element in ssl protocol element are not working Created: 12/Jan/12  Updated: 25/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-18179 When SSL keystore or truststore is sp... Sub-task Closed Amy Roh  
Tags: 3_1_2-exclude

 Description   

Specifying the keystore and truststore in ssl protocol element in domain.xml are not working.
One still pick up the keystore and truststore from jvm options.

A sample xml snapshot is as follows:
<protocol security-enabled="true" name="ssl-listener">
<http default-virtual-server="server">
<file-cache></file-cache>
</http>
<ssl key-store="/opscenter/security/keystore/keystore" ssl3-tls-ciphers="+SSL_RSA_WITH_RC4_128_MD5,+SSL_RSA_WITH_RC4_128_SHA" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" trust-store="/opscenter/security/keystore/truststore_gf" cert-nickname="s1as"></ssl>
</protocol>

I notice the following in debugger:
GlassfishSSLImpl#getServerSocketFactory() --> new GlassfishServerSocketFactory()
and we have GlassfishServerSocketFactory#getKeyManagers as follows:

        if (sslUtils == null) {
            initSSLUtils();
        }
        String keystoreFile = (String) attributes.get("keystore");
        if (logger.isLoggable(Level.FINE)) {
            logger.log(Level.FINE, "Keystore file= {0}", keystoreFile);
        }

        String keystoreType = (String) attributes.get("keystoreType");
        if (logger.isLoggable(Level.FINE)) {
            logger.log(Level.FINE, "Keystore type= {0}", keystoreType);
        }
        KeyManager[] kMgrs = sslUtils.getKeyManagers(algorithm);
        if (keyAlias != null && keyAlias.length() > 0 && kMgrs != null) {
            for (int i = 0; i < kMgrs.length; i++) {
                kMgrs[i] = new J2EEKeyManager((X509KeyManager) kMgrs[i], keyAlias);
            }
        }
        return kMgrs;
    }

(a) I notice that the keystoreFile are correctly pick up from protocol ssl element.
(b) the keystoreFile above is computed but "not" used in the computation of key managers
(c) The key managers are dervied from SSLUtils which is looked up from habitat.
However, we have
SSLUtils is scoped by Singleton.class
(ii) inside SSLUtils, the key managers are computed from SecuritySupportImpl.java
(iii) SecuritySupportImpl is also Singleton scoped
also, #initJKS method only get keystores info from jvm options



 Comments   
Comment by Shing Wai Chan [ 12/Jan/12 ]

Per discussion with Kumar, this bug is similar to http://java.net/jira/browse/GLASSFISH-15973.

I have manually classname attribute in ssl protocol element.
Then it works.

Now we have the following questions.
1) Now, by default, we use GlassfishSSLImpl. It seems that we should use "" here.
"" means that we will use the default from Grizzly.
Should we always use "" as a default?

2) If we edit the ssl keystore and truststore from admin console, then the classname will be set to GlassfishSSLImpl. And one cannot set the classname to "" from admin console.

Comment by kumarjayanti [ 12/Jan/12 ]

Shing Wai wrote :
------------
Now we have the following questions.
1) Now, by default, we use GlassfishSSLImpl. It seems that we should use "" here.
"" means that we will use the default from Grizzly.
Should we always use "" as a default?

2) If we edit the ssl keystore and truststore from admin console, then the classname will be set to GlassfishSSLImpl. And one cannot set the classname to "" from admin console.
----------------

Comment on #1 : So we cannot switch to "" as the default because we need to be secure by default.

Comment on #2 : Agreed this is an issue and we need to fix this in the CLI command. when explicit keystore and truststore are specified then the command should remove the classname.

Comment by Shing Wai Chan [ 12/Jan/12 ]

Can you clarify why "" is "not" secure?
If it is really not secure, then I think we should fix our default implementation to support the switching keystores as one don't want to compromise the security by using a two different keystores.

Comment by kumarjayanti [ 13/Jan/12 ]

"" is not secure because in this case the default Grizzly SSLImplementation is used and it expects the keystore and truststore passwords to be supplied

Either as additional attributes in the ssl element,
OR
as System properties javax.net.ssl.keyStorePassword and javax.net.ssl.trustStorePassword.

The default impl as you know reads Keystore and TrustStore from the System properties javax.net.ssl.keyStore and javax.net.ssl.trustStore so there is no issue there.

However you seem to have found an issue that GlassFish cannot be started if trustStore points to a different location other than domain config. This problem is independent of the Default SSL Implementation and i see that you have filed a different bug for that.

Generated at Tue Jul 26 04:37:36 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.