Bug 444260 - GlassFish installation fails adding cert to keystore
Summary: GlassFish installation fails adding cert to keystore
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Thomas Fitzsimmons
QA Contact: Fedora Extras Quality Assurance
Depends On: 448497
Blocks: 385291
TreeView+ depends on / blocked
Reported: 2008-04-26 06:25 UTC by Thomas Fitzsimmons
Modified: 2008-07-26 05:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-06-13 02:20:49 UTC
Type: ---

Attachments (Terms of Use)

Description Thomas Fitzsimmons 2008-04-26 06:25:59 UTC
Description of problem:

GlassFish installation as part of netbeans-6.0.1-ml-linux.sh fails.

Version-Release number of selected component (if applicable):

netbeans-6.0.1-ml-linux.sh and java-1.6.0-openjdk-

How reproducible:

Every time.

Steps to Reproduce:
1. sh netbeans-6.0.1-ml-linux.sh
2. proceed with normal installation

Actual results:

Installation fails at GlassFish (approx 80% total install progress).  Logs show:

[2008-04-26 01:52:51.297]: executing command:
/home/fitzsim/glassfish-v2ur1/bin/asadmin create-domain --interactive=false
--adminport 4848 --user admin --passwordfile
/home/fitzsim/glassfish-v2ur1/nbi-56798.tmp --instanceport 8080
--domainproperties http.ssl.port=8181 --savemasterpassword=true domain1, in
directory: /home/fitzsim/glassfish-v2ur1
[2008-04-26 01:52:52.396]:     [stdout]: Using port 4848 for Admin.
[2008-04-26 01:52:52.396]:     [stdout]: Using port 8080 for HTTP Instance.
[2008-04-26 01:52:52.396]:     [stdout]: Using default port 7676 for JMS.
[2008-04-26 01:52:52.396]:     [stdout]: Using default port 3700 for IIOP.
[2008-04-26 01:52:52.396]:     [stdout]: Using port 8181 for HTTP_SSL.
[2008-04-26 01:52:52.396]:     [stdout]: Using default port 3820 for IIOP_SSL.
[2008-04-26 01:52:52.396]:     [stdout]: Using default port 3920 for
[2008-04-26 01:52:52.396]:     [stdout]: Using default port 8686 for JMX_ADMIN.
[2008-04-26 01:52:52.396]:     [stdout]: Domain being created with
profile:developer, as specified by variable AS_ADMIN_PROFILE in configuration file.
[2008-04-26 01:52:53.601]:     [stdout]: Security Store uses: JKS
[2008-04-26 01:53:05.986]:     [stdout]: keytool error: java.io.IOException:
Invalid keystore format

The stacktrace is:

java.io.IOException: Invalid keystore format
	at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:651)
	at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
	at java.security.KeyStore.load(KeyStore.java:1201)
	at sun.security.tools.KeyTool.doCommands(KeyTool.java:651)
	at sun.security.tools.KeyTool.run(KeyTool.java:198)
	at sun.security.tools.KeyTool.main(KeyTool.java:188)

Expected results:

GlassFish install completes successfully.

Additional info:

Through several layers, the GlassFish installer is trying to run:

/usr/lib/jvm/java-1.6.0-openjdk- -import -noprompt
-keystore /etc/pki/tls/certs/ca-bundle.crt -alias
/home/fitzsim/glassfish-v2ur1/domains/domain1 -file

If I run this command manually and add "-storetype CertBundle" I get farther.

Then I get a permission denied error because the installer is running this
command not as the super user.

Enter keystore password:  
Certificate was added to keystore
[Storing /etc/pki/tls/certs/ca-bundle.crt]
keytool error: java.io.FileNotFoundException: /etc/pki/tls/certs/ca-bundle.crt
(Permission denied)

The stacktrace is:

java.io.FileNotFoundException: /etc/pki/tls/certs/ca-bundle.crt (Permission denied)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:209)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:99)
        at sun.security.tools.KeyTool.doCommands(KeyTool.java:967)
        at sun.security.tools.KeyTool.run(KeyTool.java:198)
        at sun.security.tools.KeyTool.main(KeyTool.java:188)

If I run the same command as root, I get:

Enter keystore password:  
Certificate was added to keystore
[Storing /etc/pki/tls/certs/ca-bundle.crt]
keytool error: java.lang.UnsupportedOperationException: read-only key stores

With the stacktrace:

java.lang.UnsupportedOperationException: read-only key stores
	at java.security.KeyStore.store(KeyStore.java:1133)
	at sun.security.tools.KeyTool.doCommands(KeyTool.java:970)
	at sun.security.tools.KeyTool.run(KeyTool.java:198)
	at sun.security.tools.KeyTool.main(KeyTool.java:188)

and /etc/pki/tls/certs/ca-bundle.crt becomes an empty file.

So there are a few issues here:

1) GlassFish must be looking up the path to the cert file from a system
   property, passing the result to keytool, but not looking up the storetype.
   Since we're using the OpenSSL certs by default, should our keytool assume a
   storetype of CertBundle by default?

2) GlassFish tries to modify the system certs as a normal user.

3) Even with the correct -storetype option to keytool adding certs to
   /etc/pki/tls/certs/ca-bundle.crt doesn't work, and in fact clears the file's
   contents.  I'm not sure if it's possible or desirable to use keytool to add
   OpenSSL certs to the system set.  Casey?  Maybe we need a modifiable cacerts
   file for administrator-managed certs, that layers on top of the system
   OpenSSL certs?

Comment 1 Casey Marshall 2008-04-26 18:46:45 UTC
I think supporting writable CertBundle key store is a good way to handle this. It isn't trying to store private keys 
in the store, it seems, so in this case it might work fine.

It's very simple to write one of these files: it's just each certificate in base-64, delimited by BEGIN and END 
CERTIFICATE lines. One concern is that these files can contain "comments" -- information between END and 
BEGIN markers, which is ignored -- which won't be preserved if you re-write the file.

I'd be a little concerned about that software tries to install random certificates in the *system* certificate 
bundle, though. You do that, and all of a sudden your system accepts certificates from some random, 
unverified entity.

One alternative might be to generate a JKS store from the system certificate bundle, then pass *that* JKS store 
to glassfish, if it's possible to do that.

Comment 2 Thomas Fitzsimmons 2008-05-02 21:46:32 UTC
The root problem is that Fedora 9's OpenJDK 6 packages define
javax.net.ssl.trustStore by default.  GlassFish allows this property to override
its default trust store (~/.asadmintruststore).  The lookup code is in

    private static final String ASADMIN_TRUSTSTORE = ".asadmintruststore";


    public static final String CLIENT_TRUSTSTORE_PROPERTY = 
    public static final String CLIENT_TRUSTSTORE_PASSWORD_PROPERTY =
    public static File getAsadminTruststore()
        String location = System.getProperty(CLIENT_TRUSTSTORE_PROPERTY);
        if (location == null) {
            return new File(System.getProperty("user.home") + File.separator +
        } else {
            return new File(location);

GlassFish assumes the store type is JKS, so keytool operations fail on the
CertBundle store.

Comment 3 Bug Zapper 2008-05-14 10:12:07 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 4 Lillian Angel 2008-05-28 15:22:36 UTC
Will be in next release and rawhide within the next few days.


Comment 5 Thomas Fitzsimmons 2008-05-28 21:49:16 UTC
I tested this patch against the GlassFish installation (as run by the NetBeans
installer) and confirmed that it works.  I also tested installing a package
through Eclipse's update manager, which verifies the repository certificate
against the JDK cacerts file.  This check was failing.  I confirmed that my
patch fixes it.

Comment 6 Fedora Update System 2008-06-11 18:57:00 UTC
java-1.6.0-openjdk- has been submitted as an update for Fedora 9

Comment 7 Fedora Update System 2008-06-13 02:20:46 UTC
java-1.6.0-openjdk- has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2008-07-26 05:58:05 UTC
java-1.6.0-openjdk- has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.