|
Replies:
22
-
Last Post:
Dec 3, 2007 12:53 AM
by: kumarjayanti
|
|
|
|
|
|
|
Problems w/ SSL for https:// access
Posted:
Aug 3, 2006 8:59 AM
|
|
|
I'm currently trying to move our storefront application from JBoss 4.0.4 to Glassfish b48. The SSL setup in JBoss was painless and has worked fine since installing...I'm not having the same luck in Glassfish.
I've already gone through the whole keytool process and have a keystore file that is valid. I've imported it and it exists as an alias in the keystore. However, when I try to configure it Glassfish I get the following exception:
java.io.IOException: Alias name mykeyalias does not identify a key entry
at org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.getKeyManagers(JSSE14SocketFactory.java:143)
at org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:107)
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:103)
at com.sun.enterprise.web.connector.grizzly.SelectorThread.initEndpoint(SelectorThread.java:607)
at com.sun.enterprise.web.connector.grizzly.GrizzlyHttpProtocol.init(GrizzlyHttpProtocol.java:119)
at org.apache.coyote.tomcat5.CoyoteConnector.initialize(CoyoteConnector.java:1525)
at com.sun.enterprise.web.connector.coyote.PECoyoteConnector.initialize(PECoyoteConnector.java:760)
at org.apache.catalina.startup.Embedded.start(Embedded.java:925)
at com.sun.enterprise.web.WebContainer.start(WebContainer.java:784)
at com.sun.enterprise.web.PEWebContainer.startInstance(PEWebContainer.java:722)
at com.sun.enterprise.web.PEWebContainerLifecycle.onStartup(PEWebContainerLifecycle.java:72)
at com.sun.enterprise.server.ondemand.ServiceGroup.startLifecycleServices(ServiceGroup.java:266)
at com.sun.enterprise.server.ondemand.WebServiceGroup.startLifecycleServices(WebServiceGroup.java:210)
at com.sun.enterprise.server.ondemand.WebServiceGroup.start(WebServiceGroup.java:60)
at com.sun.enterprise.server.ondemand.ServiceGroup$1.run(ServiceGroup.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.server.ondemand.ServiceGroup.startChildren(ServiceGroup.java:177)
at com.sun.enterprise.server.ondemand.MainServiceGroup.start(MainServiceGroup.java:45)
at com.sun.enterprise.server.ondemand.ServerEntryListenerImpl.notifyEntry(ServerEntryListenerImpl.java:72)
at com.sun.enterprise.server.ondemand.entry.ServerEntryHelper.sendEvent(ServerEntryHelper.java:62)
at com.sun.enterprise.server.ondemand.entry.ServerEntryHelper.generateAppLoaderEntryContext(ServerEntryHelper.java:47)
at com.sun.enterprise.server.AbstractLoader.generateEntryContext(AbstractLoader.java:827)
at com.sun.enterprise.server.AbstractLoader.notifyAppEvent(AbstractLoader.java:833)
at com.sun.enterprise.server.ApplicationLoader.load(ApplicationLoader.java:171)
at com.sun.enterprise.server.TomcatApplicationLoader.load(TomcatApplicationLoader.java:113)
at com.sun.enterprise.server.AbstractManager.load(AbstractManager.java:206)
at com.sun.enterprise.server.ApplicationLifecycle.onStartup(ApplicationLifecycle.java:204)
at com.sun.enterprise.server.ApplicationServer.onStartup(ApplicationServer.java:326)
at com.sun.enterprise.server.ondemand.OnDemandServer.onStartup(OnDemandServer.java:112)
at com.sun.enterprise.server.PEMain.run(PEMain.java:326)
at com.sun.enterprise.server.PEMain.main(PEMain.java:260)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.enterprise.server.PELaunch.main(PELaunch.java:272)
|#]
[#|2006-08-03T09:33:11.203-0600|WARNING|sun-appserver-pe9.0|javax.enterprise.system.stream.err|_ThreadID=10;_ThreadName=main;_RequestID=64f1e0d8-69e2-49b4-8682-cac6c173dc66;|com.sun.appserv.server.ServerLifecycleException: WEB0105: An error occurred while starting the web container
at com.sun.enterprise.web.PEWebContainer.startInstance(PEWebContainer.java:731)
at com.sun.enterprise.web.PEWebContainerLifecycle.onStartup(PEWebContainerLifecycle.java:72)
at com.sun.enterprise.server.ondemand.ServiceGroup.startLifecycleServices(ServiceGroup.java:266)
at com.sun.enterprise.server.ondemand.WebServiceGroup.startLifecycleServices(WebServiceGroup.java:210)
at com.sun.enterprise.server.ondemand.WebServiceGroup.start(WebServiceGroup.java:60)
at com.sun.enterprise.server.ondemand.ServiceGroup$1.run(ServiceGroup.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.server.ondemand.ServiceGroup.startChildren(ServiceGroup.java:177)
at com.sun.enterprise.server.ondemand.MainServiceGroup.start(MainServiceGroup.java:45)
at com.sun.enterprise.server.ondemand.ServerEntryListenerImpl.notifyEntry(ServerEntryListenerImpl.java:72)
at com.sun.enterprise.server.ondemand.entry.ServerEntryHelper.sendEvent(ServerEntryHelper.java:62)
at com.sun.enterprise.server.ondemand.entry.ServerEntryHelper.generateAppLoaderEntryContext(ServerEntryHelper.java:47)
at com.sun.enterprise.server.AbstractLoader.generateEntryContext(AbstractLoader.java:827)
at com.sun.enterprise.server.AbstractLoader.notifyAppEvent(AbstractLoader.java:833)
at com.sun.enterprise.server.ApplicationLoader.load(ApplicationLoader.java:171)
at com.sun.enterprise.server.TomcatApplicationLoader.load(TomcatApplicationLoader.java:113)
at com.sun.enterprise.server.AbstractManager.load(AbstractManager.java:206)
at com.sun.enterprise.server.ApplicationLifecycle.onStartup(ApplicationLifecycle.java:204)
at com.sun.enterprise.server.ApplicationServer.onStartup(ApplicationServer.java:326)
at com.sun.enterprise.server.ondemand.OnDemandServer.onStartup(OnDemandServer.java:112)
at com.sun.enterprise.server.PEMain.run(PEMain.java:326)
at com.sun.enterprise.server.PEMain.main(PEMain.java:260)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.enterprise.server.PELaunch.main(PELaunch.java:272)
Caused by: LifecycleException: Protocol handler initialization failed: java.io.IOException: Alias name mykeyalias does not identify a key entry
at org.apache.coyote.tomcat5.CoyoteConnector.initialize(CoyoteConnector.java:1527)
at com.sun.enterprise.web.connector.coyote.PECoyoteConnector.initialize(PECoyoteConnector.java:760)
at org.apache.catalina.startup.Embedded.start(Embedded.java:925)
at com.sun.enterprise.web.WebContainer.start(WebContainer.java:784)
at com.sun.enterprise.web.PEWebContainer.startInstance(PEWebContainer.java:722)
... 26 more
If I browse the site w/ https://domain or https://domain:8181 it fails...and at this point I can no longer get to the admin console at http://domain:4848 w/o manually removing the SSL entry from domain.xml and restarting.
I'm using the KeyTool IUI found here:
http://yellowcat1.free.fr/keytool_iui.html
Clearly the key & alias exist on the machine and I put the .ks file in C:\glassfish\domains\domain1\config and restarted the server. It is a Verisign certificate so I followed the instructions found here:
http://blogs.sun.com/roller/page/swchan?entry=how_to_use_verisign_cert
In 'http-listener-2' I entered the alias, enabled TLS (since that's what I was using in JBoss, not SSL). I've tried SSL in addition to TLS but it doesn't make any difference.
I'm just not sure what else to do. This may be the final determining factor for moving to Glassfish. I doubt I can convince the boss to pay for another SSL cert (this one was $1800) just to move to another app server.
Can someone help? I'm sure I've done something wrong but the documentation is a little lacking, also.
Thanks!
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Aug 10, 2006 9:54 AM
in response to: zambizzi
|
|
|
From the error message, it indicates that it cannot find a key entry of alias name mykeyalias. Can you double check the following?
1. the alias key password = the keystore password = previous masterpassword which is "changeit" by default. One cannot just change keystore password by keytool. One need to use asadmin change-master-password.
2. the mykeyalias is really corresponding to a key entry
You can verify this by the following keytool command:
cd $AS_ROOT/domains/domain1/config
keytool -list -v -alias mykeyalias -keystore keystore.jks
(I have not tried to gui below. It would be a good idea to use command for debugging purpose.)
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Aug 10, 2006 1:22 PM
in response to: swchan2
|
|
|
I'm starting to understand now, you'll have to forgive my ignorance - this was my first SSL cert done through keytool/Java - in the past I'd only done it with Apache or IIS.
So, what I did was, per Verisign's instructions, create a new keystore and I now have one in JKS format but the file is called "myks.keystore" - this is the one currently used successfully in production on JBoss.
I copied this file into C:\glassfish\domains\domain1\config and I can successfully query as you instructed like so:
C:\glassfish\domains\domain1\config>"C:\Program Files\Java\jdk1.5.0_06\bin\keytool.exe" -list -v -alias mykeyalias -keystore myks.keystore
Enter keystore password: mypassword
........
I get output that looks something like this:
Alias name: mykeyalias
Creation date: May 25, 2006
Entry type: keyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=www.mydomain.com, OU=Terms of use at www.verisign.com/rpa (c)05,
OU=Information Services, O=My Company, L=Boise, ST=Idaho, C=US
Issuer: OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign, OU=
VeriSign International Server CA - Class 3, OU="VeriSign, Inc.", O=VeriSign Trus
t Network
Serial number: asdfasdfasdfasdfasdfasdfasdfasdf
Valid from: Wed May 24 18:00:00 MDT 2006 until: Sat May 26 17:59:59 MDT 2007
Certificate fingerprints:
MD5: 3E:40:3E:C1:DE:61:DA:8F:F0:A0:47:FE:5E:88:17:0B
SHA1: 3E:40:3E:C1:DE:61:DA:8F:F0:A0:47:FE:5E:88:17:0B:95:A1:CA:CF
Certificate[2]:
Owner: OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign, OU=V
eriSign International Server CA - Class 3, OU="VeriSign, Inc.", O=VeriSign Trust
Network
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C
=US
Serial number: asdfasdfasdfasdfasdfasdfasdfasdf
Valid from: Wed Apr 16 18:00:00 MDT 1997 until: Mon Oct 24 17:59:59 MDT 2011
Certificate fingerprints:
MD5: 3E:40:3E:C1:DE:61:DA:8F:F0:A0:47:FE:5E:88:17:0B
SHA1: 3E:40:3E:C1:DE:61:DA:8F:F0:A0:47:FE:5E:88:17:0B:65:C2:CC:4F
Certificate[3]:
Owner: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=
US
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C
=US
Serial number: asdfasdfasdfasdfasdfasdfasdfasdf
Valid from: Sun Jan 28 17:00:00 MST 1996 until: Tue Aug 01 17:59:59 MDT 2028
Certificate fingerprints:
MD5: 3E:40:3E:C1:DE:61:DA:8F:F0:A0:47:FE:5E:88:17:0B
SHA1: 3E:40:3E:C1:DE:61:DA:8F:F0:A0:47:FE:5E:88:17:0B:3E:61:74:E2
Soooo...it's obviously good? I may not have done it right (or maybe I did?) but it works currently in production on JBoss, as I said before.
Will there be any way to use this cert in Glassfish w/o having to revoke & re-generate it (would cost us $100)??
I'm confused as to how to proceed, I guess.
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Aug 16, 2006 2:09 PM
in response to: zambizzi
|
|
|
boop!
Sorry to bump but I haven't gotten an answer in a long time.
Any ideas how I might proceed here?
Thanks!
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Aug 21, 2006 2:17 PM
in response to: zambizzi
|
|
|
My two cents.
Have you export your certificate from your existing keystore (myks.keystore) and then import to glassfish keystore (keystore.jks)?
Make sure when you are listing the "keystore.jks" file, it contains your certificate alias (mykeyalias)?
List of the default self-signed certificate from Glassfish keystore. ( It is in the keystore.jks file.) (Default certificate alias is "s1as" which is in the domain.xml)
# keytool -list -keystore keystore.jks -storepass changeit
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
s1as, Aug 21, 2006, keyEntry,
Certificate fingerprint (MD5): 3C:04:02:AA:F5:AE:89:B2:F3:25:C6:0E:19:0E:AD:62
Listing of all the trusted CA in GlassFish Trusted CA cert. (in cacerts.jks)(you will see selfsign CA. "s1as")
# keytool -list -keystore cacerts.jks -storepass changeit
Keystore type: jks
Keystore provider: SUN
Your keystore contains 11 entries
verisignc1g3, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): B1:47:BC:18:57:D1:18:A0:78:2D:EC:71:E8:2A:95:73
verisignc1g2, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): DB:23:3D:F9:69:FA:4B:B9:95:80:44:73:5E:7D:41:83
verisignc1g1, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): 97:60:E8:57:5F:D3:50:47:E5:43:0C:94:36:8A:B0:62
verisignc2g3, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): F8:BE:C4:63:22:C9:A8:46:74:8B:B8:1D:1E:4A:2B:F6
verisignc2g2, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): 2D:BB:E5:25:D3:D1:65:82:3A:B7:0E:FA:E6:EB:E2:E1
verisignc2g1, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): B3:9C:25:B1:C3:2E:32:53:80:15:30:9D:4D:02:77:3E
verisignc3g3, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): CD:68:B6:A7:C7:C4:CE:75:E0:1D:4F:57:44:61:92:09
verisignc3g2, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): A2:33:9B:4C:74:78:73:D4:6C:E7:C1:F3:8D:CB:5C:E9
verisignc3g1, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): 10:FC:63:5D:F6:26:3E:0D:F3:25:BE:5F:79:CD:67:67
s1as, Aug 21, 2006, trustedCertEntry,
Certificate fingerprint (MD5): 3C:04:02:AA:F5:AE:89:B2:F3:25:C6:0E:19:0E:AD:62
verisignsecureserver, Apr 8, 2004, trustedCertEntry,
Certificate fingerprint (MD5): 74:7B:82:03:43:F0:00:9E:6B:B3:EC:47:BF:85:A5:93
Command to export you key to a file
===================================
# keytool -export -alias mykeycert -keystore myks.keystore -rfc -file /tmp/mycertkeyfile
Enter keystore password: changeit
Certificate stored in file </tmp/m
Command to import keyfile to keystore.jks
=========================================
# keytool -import -file /tmp/mycertkeyfile -keystore keystore.jks -alias mynewkeycert
Enter keystore password: changeit
Certificate was added to keystore
Hope it helps.
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Sep 9, 2006 12:11 AM
in response to: hyau
|
|
|
I was hopeful...I really was...however after following these instructions it still does not work and cannot find the alias.
I'll retrace my steps and you can tell me where, if anywhere, I goofed it up.
1. Installed new Glassfish v1 b48 from jar installer.
2. cd domains\domain1\config
3. keytool -list -keystore keystore.jks -storepass changeit
The output from this:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
s1as, Sep 9, 2006, keyEntry,
Certificate fingerprint (MD5): C9:31:FD:D1:02:59:40:AC:4C:E5:76:99:D6:E2:E7:C5
4. keytool -list -keystore cacerts.jks -storepass changeit
The output from this:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 33 entries
equifaxsecureebusinessca1, Jul 18, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 64:9C:EF:2E:44:FC:C6:8F:52:07:D0:51:73:8F:CB:3D
verisignclass1g3ca, Mar 25, 2004, trustedCertEntry,
Certificate fingerprint (MD5): B1:47:BC:18:57:D1:18:A0:78:2D:EC:71:E8:2A:95:73
verisignclass2g2ca, Mar 25, 2004, trustedCertEntry,
Certificate fingerprint (MD5): 2D:BB:E5:25:D3:D1:65:82:3A:B7:0E:FA:E6:EB:E2:E1
verisignclass3g3ca, Mar 25, 2004, trustedCertEntry,
....and many more....
5. keytool -export -alias tomcat -keystore "C:\Program Files\Java\jdk1.5.0_06\bin\myexisting.keystore" -rfc -file C:\mycertexport
Enter keystore password: myexistingpassword
Certificate stored in file <C:\mycertexport>
6. keytool -import -file C:\mycertexport -keystore keystore.jks -alias mynewalias
Enter keystore password: changeit
Owner: CN=secure.mysite.com, OU=Terms of use at www.verisign.com/rpa (c)05,
OU=Information Services, O=My Company, L=Boise, ST=Idaho, C=US
Issuer: OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign, OU=
VeriSign International Server CA - Class 3, OU="VeriSign, Inc.", O=VeriSign Trus
t Network
Serial number: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Valid from: Wed May 24 18:00:00 MDT 2006 until: Sat May 26 17:59:59 MDT 2007
Certificate fingerprints:
MD5: 3E:30:3A:C1:DE:61:DA:7F:F0:A0:47:E1:5E:21:17:9B
SHA1: AB:23:27:CE:D2:6D:E5:51:62:0C:A2:50:FD:C3:5F:20:95:A1:CA:CF
Trust this certificate? [no]: yes
Certificate was added to keystore
I then went into the Glassfish admin console and changed http-listener-2 to have an alias of "mynewalias", enabled SSL3, TLS, and checked the box to allow cipher suites (but did not choose any specific suites from the list.)
...and finally, I start the server and get this exception:
[#|2006-09-09T00:35:47.613-0600|SEVERE|sun-appserver-pe9.0|javax.enterprise.system.container.web|_ThreadID=11;_ThreadName=Thread-5;_RequestID=19c43a71-9e9f-4224-8999-601fcba26a25;|WEB0701: Error initializing endpoint
java.io.IOException: Alias name mynewalias does not identify a key entry
I have to remove the tag for this alias manually from domain.xml in order to get the server to run correctly again.
Bummer...big big bummer. This has been a major setback for me...I doubt I'll get Glassfish into production in our shop if I can't get this cert to work.
Anyhow, thanks again!
EDIT 1:
I thought I also should include that I can "-list" the keys after importing (as described above) and it is definitely there in the list. I'm confused by the IOException telling me it can't find the alias!? I even put both the export file I created *and* the .keystore file I *created* the new export file from into the /domains/domain1/config folder. ugh.
Message was edited by: zambizzi
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 4, 2006 5:55 AM
in response to: zambizzi
|
|
|
I'm trying to get this to work also. Check to see if the below lines are in your jvm options. In some Glassfish installs this is not there. (install-dir/domain/domain1/config is where this resolves to on my computer)
-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks
-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks
I hope you get it to work. I've been pulling my hair out over this!
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 4, 2006 9:40 AM
in response to: bmorton
|
|
|
I'm sorry to rant because I *do* realize that this is an open source project and I can't expect everything I want, when I want it. However, I was pulled from this project due to the lack of a reasonable solution for this problem (and a few others, i.e. Toplink) and have been told to abandon the use of Glassfish altogether. We're now in the process of re-evaluating our use of Java EE 5 due to the lack of availability of a reasonably stable and complete open source application server. I was basically told that if we're having such problems w/ the open source implementation, there's no way I'd get approval to purchase a service contract for support on the commercial product based on Glassfish.
I will, however, probably continue using it for my own personal projects once a new build is released, finally wrapping up some of the issues I've experienced w/ Toplink.
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 5, 2006 1:34 AM
in response to: zambizzi
|
|
|
It's not really Glassfish's fault. Notice that the top of the stack trace is actually an Apache Tomcat method. Anyway, you need to also import the PRIVATE key into your keystore, and it can't be done by keytool alone. Let me know if it works.
See this page: http://www.agentbob.info/agentbob/79.html
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 5, 2006 5:34 AM
in response to: benupsavs
|
|
|
Sure, you and I understand that but try using that explanation when talking to management when asked why two weeks of labor yielded no results. I was given a certain amount of time to determine if we could move our storefront off of JBoss and onto Glassfish, the SSL was the *only* hang up...after two weeks my boss didn't care if it was the candyman, the three little bears, or Apache Tomcat...it was just time to call it quits.
Anyhow, herein lies the problem - I've now got three different sets of instructions on how this should be done and all of them are coming from different sources of "documentation".
Perhaps I'll give this a shot sometime in the future on my own time just to satisfy my own curiosity. However, it would still be unfortunate as two weeks of attempts and heavy googling for answers was fruitless for me.
Thanks for the info, anyhow!
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 8, 2006 1:42 AM
in response to: zambizzi
|
|
|
So, riddle me this:
If I were to just go to VeriSign and cancel/re-issue my SSL cert, could I just start from scratch w/ Glassfish and have a much easier time that trying to import an existing cert?
Could I avoid all of these problems by starting fresh?
It would cost us $100 but that's not going to break the bank, I've already spent much more than that trying to get it to work as it is!
When prompted for what *type* of key at VeriSign, should I go ahead an do this, would I answer "tomcat"??
Thanks!!!
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 9, 2006 9:49 AM
in response to: zambizzi
|
|
|
I think before purchase a new certificate from Verisign, I would suggest you to try the free trial certificate that Verisign has provided.
I believe you should use jks type of ceriticate, it should be RSA type for default.
Quote from Java keytool documentation.
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html
"The signature algorithm is derived from the algorithm of the underlying private key: If the underlying private key is of type "DSA", the default signature algorithm is "SHA1withDSA", and if the underlying private key is of type "RSA", the default signature algorithm is "MD5withRSA"."
The default type is "RSA".
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 11, 2006 2:59 PM
in response to: zambizzi
|
|
|
So did you ever try to import the private key into your keystore using the instructions on that website or what? It would probably be even easier than buying and a new cert, submitting a CSR, waiting, etc.
If you're able to manipulate the public and private keys using OpenSSL, it will work.
Anyway, if you're really going to buy a new certificate, you can use the Tomcat instructions and here is the link:
http://www.verisign.com/support/ssl-certificates-support/page_dev020184.html
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 12, 2006 8:45 AM
in response to: benupsavs
|
|
|
I have tried absolutely *everything* recommended in this forum and the documentation linked to it - and if you actually read through this thread, you'll see that I tried them all to exact instructions and posted detailed results on my attempts.
My next step is to try it from scratch w/ a temporary cert...which I've created but have not had time to test yet.
I am *not* able to do anything w/ OpenSSL - this is a Windows shop and I don't want to use cygwin and all of that stuff just to be able to use OpenSSL. I'm a long-time Gentoo Linux user outside of the office but that doesn't do me any good here.
The original cert I created *was* created w/ Tomcat instructions - I believe I also mentioned that somewhere in this thread.
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 12, 2006 8:59 AM
in response to: zambizzi
|
|
|
Now that Glassfish has a Wiki, is there any chance of a Sun engineer or someone else "in the know" of posting some very _complete_ and simple instructions on getting a Verisign cert working?
You'll notice throughout this thread that there are three or four external resources referenced which, I'd assume would be working instructions (if I could get it to actually work.) A mixture of blogs, forums posts, and 3rd. party hacks is not, IMO, a very good set of instructions for a task such as this.
I'm willing to cancel and re-issue my cert to move to Glassfish in our production environment (when V1 UR1 is released) - if I knew that I had correct and complete instructions.
I would gladly do this myself if I had even a slight indication that I was doing it correctly.
Thanks all!
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 13, 2006 7:04 PM
in response to: zambizzi
|
|
|
Steps in using verisign certificate with Glassfish appserver (I tried these steps and worked fine with trial ssl cert from verisign):
1. Generate the key pair
delete mykeystore.jks if already exists
keytool -genkey -alias test-server -keysize 1024 -keyalg RSA -keystore mykeystore.jks -dname "CN=mytest.myorg.com, OU=MyGroup, O=My Org, L=MyCity, S=MyState, C=MyCountry"
2. Generate the certificate request
keytool -certreq -alias test-server -sigalg SHA1withRSA -keystore mykeystore.jks -file testserver.cer
3. Sign the certificate with CA
Goto www.verisign.com
Try with Free Trial SSL -->
cat testserver.cer and cut & paste in the certificate area.
You may receive the mail with instructions.
4. Import the replied certificate into keystore
Save the given reply certificate (from your email) to a file, say - signed_test_server.cer and save verisign CA certs in files. I got 2 . One intermediate and another Test Trial CA (say copied to verisign_test_ca.cer and verisign_intermediate_ca.cer) .
Import into mykeystore.jks (same keystore as used in the first step) and assume
keytool -import -alias verisigncert -keystore mykeystore.jks -trustcacerts -file verisign_test_ca.cer -v
keytool -import -alias verisigninter -keystore mykeystore.jks -trustcacerts -file verisign_intermediate_ca.cer
keytool -import -alias test-server -keystore mykeystore.jks -trustcacerts -file signed_test_server.cer
If the above steps were not correct, you may face certificate chain issue during import.
Double check the subject and issuer of the certificate (test-server). [ keytool -list -keystore mykeystore.jks -alias test-server -v ]
Now your server certificate is ready to use.
In glassfish server environment:
1. Add the SSL to http-listener-2 with "test-server" (same as above) alias using admin console . Stop the server.
2. Copy mykeystore.jks to keystore.jks (under domain1/config)
3. Import the CA certs in trust store (domain1/config/cacerts.jks):
keytool -import -alias verisigncert -keystore cacerts.jks -trustcacerts -file verisign_test_ca.cer -v
keytool -import -alias verisigninter -keystore cacerts.jks -trustcacerts -file verisign_intermediate_ca.cer
4. Start the server
At this point you should able to access https://localhost:8181/ with new test-server certificate.
Tried to give you some level of information before I take more time in creating a doc and later I will have wiki page with screenshots.
Hope this helps.
Thanks.
|
|
|
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 14, 2006 9:23 AM
in response to: jagadesh
|
|
|
Thank you very much! I will *definitely* do a trial run this weekend and then simply revoke and regenerate my existing full cert on Monday if all goes well...since I have had no success importing my existing cert, for whatever reason.
One question: What will be the process of keeping the cert from breaking when I upgraded from one version of Glassfish to the next.
For example, I will do this now w/ Glassfish V1 but what happens when I upgraded to V1 UR1...and then V2, and so on?
Perhaps this information could also be added to the wiki? I'll be more than happy to provide any insight into my experience once I'm actually successful in pulling it off!
This is _much_ appreciated!
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 15, 2006 11:38 AM
in response to: zambizzi
|
|
|
Did you ever try to copy your keystore from JBoss into Glassfish's domains/domain1/config/ and REMOVE Glassfish's default key (that is generated when you run setup.xml) and then RENAME your old keystore to keystore.jks? From reading all of your posts again, I noticed a lot of importing and even moving your old keystore into the config directory but never renaming it over the default Glassfish one. After you do that, you'll have to change the alias name and password in Glassfish's config, obviously.
After reading the second sentence in your last post, I want to throw you a slew of profanities but all I'll say is that the people in this thread aren't trying to write general SSL/VeriSign/Glassfish docs - they're trying to help you.
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Oct 16, 2006 8:22 AM
in response to: benupsavs
|
|
|
Yes, I did try that, the server won't start http-listener-2 at all if I do that...and I have to shut down and manually remove the cert from domain.xml in order to get it to run again.
A slew of profanities? That sounds a little bit angry, don't ya think? The second sentence of my last reply to this forum was "One question: What will be the process of keeping the cert from breaking when I upgraded from one version of Glassfish to the next."
This causes you to go into an uncontrollable Tourette's episode? I won't pretend to understand, so do what you must!
Anyhow, sorry if there was some sort of misunderstanding somewhere along the line of communication here? I never said people here weren't helpful...I think I've said that several times over...everyone's been great!
So...thanks again all!
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Sep 14, 2007 4:54 AM
in response to: zambizzi
|
|
|
I'm a "little" late with this. But, I was having the same problem.
The alias must be a (private) key entry. When you do a keytool -list -keystore litoral-keystore.jks
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 3 entries
litoral-private-key, 13/09/2007, PrivateKeyEntry,
Certificate fingerprint (MD5): 84:65:0A:B0:D3:CC:D6:51:74:25:FA:32:A6:EF:A2:9D
litoral-cert, 13/09/2007, trustedCertEntry,
Certificate fingerprint (MD5): C0:BF:9C:D3:28:55:C3:95:64:72:C2:56:35:3D:01:B8
certisign-trial, 13/09/2007, trustedCertEntry,
Certificate fingerprint (MD5): E4:B4:3A:0E:98:E3:03:0D:2E:65:EA:1D:9D:6F:3C:EF
In this case the alias must be litoral-private-key.
To transfer the private key of one keystore to another do the follow command:
keytool -importkeystore -srckeystore litoral-keystore.jks -destkeystore domains/domain1/config/keystore.jks -srcalias litoral-private-key
After this, reestart Glassfish and use the alias that refers to the private key. But, don't forget the password of the private key must be the same of the keystore on Glassfish.
Hope this can help you.
Regards,
Felipe M Cypriano
Vitoria - ES - Brasil
|
|
|
|
|
|
|
|
|
Re: Problems w/ SSL for https:// access
Posted:
Dec 1, 2007 6:30 PM
in response to: fmcypriano
|
|
|
I was having the same problem as the original poster and though some time has passed, I am posting this for the benefit of the next person who may be having this problem.
My problem was that I used keytool to import a certificate that was generated from a private key NOT in the keystore. Glassfish (Sun Java System Application Server 9.0, to be exact) stopped responding to web requests and the solution required having the certificate reissued and editing domain.xml manually to replace the reference (the "alias") to the old certificate and replace it with the name of the alias of the new certificate.
Now first, I want to say that my limited experience with Glassfish has been great, and I'm planning to keep using it by all means.
I installed Glassfish, which went extremely smoothly and with the management web interface, was really easy to configure. It took minutes as opposed to the normal hours of download/install/fix that usually happens (I do not do this often enough.)
My problems started when I tried to install an SSL certificate that I had obtained for a plain Apache configuration.
I used keytool to import the existing certificate, and when I restarted Glassfish, and tried to access the secure site, it never completed the response and left the browser hanging. Ditto with the web interface - it was no longer usable.
I saw the same exceptions in the logfile that the first poster did. It seemed that the private key had to be in the keystore along with the certificate. But the keytool app does not provide a means of inserting the private key into the keystore.
My certificate was a (relatively) inexpensive SSL123 cert from Thawte, which will let you "start over' if you need to. For free, you can have them reissue a certificate (which invalidates the old one) from their website.
So I followed various instructions I found for generating a key in the keystore Glassfish would use, generating a certificate request, using Thawte's service to reissue my cert, approved it, downloaded it afte waiting about a half hour, and installed it with keytool.
(I must point out that this was not as easy as it sounds. You have to get the commands exactly right because when you don't, the error messages often are for problems unrelated to what really went wrong. Also, I would advise everyone to be super careful when cutting and pasting the cert as I spent 8 hours on this particular problem, with at least three of them caused by an extra empty line at the top of the certificate file (I had not noticed it when pasting.) Thawte warns to eliminate extraneous whitespace at the end of each line after pasting. The bottom line is, make sure the alias (basically, a name so you can easily identify the certificate lately and which Glassfish uses to refer to it) is the same AND specified with the -alias parameter every time; make sure you're using the same keystore you generated the request from (the documentation in one case made it seem otherwise), and go over the certificate file with a fine tooth comb to be sure there is no extra whitespace or newline preceding the header line, at the beginning or end of each line, or following the footer.)
Once you have the key installed, you might try using keytool to delete the old key (hope you used a different alias for the reissued key than the key that did not work!). Not that it matters much but if you go poking around the keystore later you might wonder why it's there and whether or not you still need it - or worse, you might try to use it and lock up your app server again.
Finally, you need to get the app server out of its locked state. Restarting it did not help me. Perhaps deleting the old key from the keystore would help; I did not try this. What I did was edit the domain.xml file manually, searched for and found the alias for the old key, and replaced it with the alias for the new key.
Then I used the command line app server admin tool (asadmin, found in the bin directory of the app server's root) to restart the app server, and everything worked.
To summarize:
- Don't try to import a certificate whose private key isn't in the keystore.
- Make very sure that the certificate has no extraneous whitespace.
- Be sure you understand what the "alias" is (just a simple name that the app server uses to find the cert in the keystore) and make sure you include it when using any keytool commands.
- Do not trust the keytool or openssl command error text to be relevant to the problem you're having.
Let me tell you, while I was trying to figure this out, it was a real pain in the keystore.
=========
Some extra stuff for the benefit of other people who might have similar issues:
keytool gave me this error when I tried to import my newly reissued certificate. I spent hours going down the wrong track because it was not relevant to the problem (an extra blank line at the beginning of the certificate, that had found its way in while I was copying it from the Thawte website into a text editor):
keytool error: java.lang.Exception: Input not an X.509 certificate
Others have report that keystore will generate the same error if the alias is not specified with the -alias keyword in the keytool command.
This led me to mistakenly believe that somehow I had to convert my PKCS #7 certificate into an X.509 certificate (not knowing if that was even possible, since I don't spend much time in this space.) openssl gave me errors like this when encountering my certificate with the extra carriage return at the beginning:
unable to load PKCS7 object
14492:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:644:Expecting: PKCS7
and
unable to load PKCS7 object
14480:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1296:
14480:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=PKCS7
|
|
|
|
|
|
|
|
java.net RSS
