Hello.

"Good" to hear - thought that I was going crazy.
I will file a bug report some time tomorrow.

Is there a work around? For example, how do you unlock your keystore in the 3:rd step?

Greetings,

On Fri, Dec 5, 2008 at 3:41 PM, Vamsavardhana Reddy <c1vamsi1c@gmail.com> wrote:
Hmm...  the 3rd step is indeed unearthing a bug.  At that step, a second "attribute" element is getting added (instead of replacing the existing element) to the keystore gbean for keystorePassword and keyPasswords attributes in config.xml .  Can you create an issue in the JIRA [1]? The problem summary is, "locking and unlocking for availability of a keystore results in duplicate attributes in config.xml".


[1] https://issues.apache.org/jira/browse/GERONIMO


On Fri, Dec 5, 2008 at 7:29 PM, Christian Svensson <blue@cmd.nu> wrote:
Hello.

It's a correct assumption that I am using Jetty, I'm using 2.1.3 Geronimo w/ Jetty package from the website (running with Sun Java 1.6).
I think it's the 3:rd step I'm lacking behind at.

This is how I created my setup:

1. Create a new keystore 'plasma-ssl'
2. Create a new private key 'wildcard'
3. Now the text on "Available" says "trust only" or something like that, I lock it and then unlock it in order for it to change to "1 key ready"
4. Then I configure my HTTPS connector to use the new keystore
5. Since the web server does not seem to do anything when I press "Shutdown" in the console, I use Ctrl+C to kill it.
6. Start the server again
7. Message appears.

1 to 4 are applied using the web console.

Have I done the step "Unlock keystore 'mykeystore' and private-key 'mykey' for availability." correctly?

Greetings,


On Fri, Dec 5, 2008 at 9:28 AM, Vamsavardhana Reddy <c1vamsi1c@gmail.com> wrote:
Hi Christian,

Once you create a new keystore, the keystore is not unlocked for availability automatically.  After creating the keystore and private key, you need unlock the keystore for availability.  The unlocked state for "availability" of the keystore is persistent. I assume that you are using Geronimo Jetty Server.  Here are the steps I tried with Geronimo Jetty 2.1.3 and had no problem restarting the server.
1. Created a new keystore 'mykeystore'.
2. Created a private-key 'mykey'.
3. Unlock keystore 'mykeystore' and private-key 'mykey' for availability.
4. Edit HTTS web connector to use 'mykeystore'
5. Restart the server.

6. Unlock 'mykeystore' for editing.
7. Change password for 'mykey'.
8. Restart the server.

The Geronimo Tomcat server does not use the keystoregbean for HTTPS and directly access the keystore files.  Also, "the keystore password and keypassword must be same" is applicable to G Tomcat server.

Can you tell me the exact version of Geronimo server and the steps you are following that are resulting in the problem?



On Tue, Dec 2, 2008 at 5:48 AM, Christian Svensson <blue@cmd.nu> wrote:
Hello!

I've been trying for the better part of today getting keystores to automatically unlock on startup - with very limited success.
Is there something that I should know about keystore password / key password? Digging around some old mailing list threads said something about key password must be equal to keystore password - any more of those gotchas?

The problem is that I create (or change password on geronimo-default for that matter) a new keystore, assign SSL to use the certificate and restart the server:
org.apache.geronimo.management.geronimo.KeystoreIsLocked: Keystore 'plasma-ssl' is locked; please use the keystore page in the admin console to unlock it
        at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLContext(FileKeystoreManager.java:343)
        at org.apache.geronimo.jetty6.connector.GeronimoSelectChannelSSLListener.createSSLContext(GeronimoSelectChannelSSLListener.java:54)


Resetting the SSL connector to using geronimo-default / geronimo with secret / secret as passwords makes it work again - but why on earth doesn't Geronimo unlock my keystores on startup? I mean, it saves the password (or something like it) in config.xml.

Greetings,
--
Christian Svensson
Command Systems



--
Vamsi



--
Christian Svensson
Command Systems



--
Vamsi



--
Christian Svensson
Command Systems