I tested this on jBoss EAP4.3CP03 (which according to jBoss it is the same basic codebase as 4.2.x). Now that I understand the underlying principles involved, I *suspect* that it will work on 5.0 and other versions of jBoss.
The issue, as with many open source projects, was lack of 'usable' documentation. jBoss docs are pretty much written for someone who already knows a lot about jBoss' design and configuration - if you just want to use it... you call support or suffer through it. I encountered a lot of problems before I was finally able to find a procedure that worked. A few key factors to making this work: - Using a single keystore (conf/server.keystore). - Explicitly telling jBoss to use it as both the keystore AND the truststore. - Binding to -b 0.0.0.0 so that it recognized ALL of the network cards!!! - The server.keystore is being created as part of this process - there was no pre-existing keystore by that name... so the resulting keystore contains ONLY the private and public keys. - I started with a virgin install of jBoss. No prior configurations. Made things simpler to trouble-shoot. - I used JDK 1.6. I noticed that on a Windows server that defaulted to an old JDK 1.5 I had problems running keytool. Not sure why. When I updated JAVA_HOME and PATH, the problem went away. - Because of jBoss' way of organizing things, it is very easy to make a mistake and edit the right file in the wrong folder... I caught myself doing this a few times. Obviously, when you do this, the change has no effect :P I heard great things about openSSL and its ability to create a trusted Certificate Authority (and therefore pseudo-real certificates) for an enterprise. bruno ________________________________ From: Griffith, Michael * [mailto:[email protected]] Sent: Monday, March 02, 2009 1:51 PM To: [email protected] Subject: RE: [cas-user] CAS, jBoss and self-signed certificates Bruno, Maybe you could clarify what version of Jboss you are specifying? Should it matter? I followed a similar process for creating a self signed certificate for Jboss 4.2.1, which did not work for JBoss 4.2.3. I had to recreate the certificate, as Jboss through an Invalid keystoreType exception. I had to create the certificate using OpenSSL. MG ________________________________ From: Bruno Melloni [mailto:[email protected]] Sent: Monday, March 02, 2009 1:36 PM To: [email protected] Subject: RE: [cas-user] CAS, jBoss and self-signed certificates As promised, here are detailed configuration instructions for using self-signed certificates in jBoss. I recommend including them (or a modified version) in the CAS documentation. It would also be nice to provide a link in step 2 of the DEMO document (http://www.ja-sig.org/wiki/display/CASUM/Demo). jBoss HTTPS configuration using a self-signed certificate (Do not use for PROD servers - use trusted certificates from a Certificate Authority instead) (1) Browsers may access applications on the server via HTTPS. Browser will warn that server certificate is self-signed and allow user to choose to access. (2) Applications on the server may call each other via HTTPS. The certificate will not be rejected by applications even though it is self-signed. Steps: (1) These instructions assume a virgin jBoss install. (2) Identify the hostname for the computer hosting the server. Will use 'myHostname' in these instructions. (3) Identify the jBoss server type being used (all/default/prod). Will use 'default' in these instructions. (4) jBoss comes configured to only allow access for hostname = 'localhost'. Reconfigure to 'myHostname'. If the server happens to have more than one network card (and IP address) and both must be recognized as valid by jBoss, use -b 0.0.0.0 instead of -b <hostname or IP>. All zeroes will allow the IPs for all network cards to be acknowledged. (5) Assuming there is no default/conf/server.keystore. If there is one, rename it, delete it, or use a different keystore name. (6) Create server.keystore and private key. server.keystore will be used as both a keystore and truststore. a. In a unix shell or windows command prompt go to the folder default/conf. b. keytool -genkey -alias jbosskey -keypass changeit -keyalg RSA -keystore server.keystore c. Use 'myHostname' as the first/last name. This is critical. d. The file server.keystore is generated. e. keytool -list -keystore server.keystore f. The just generated PrivateKeyEntry for jbosskey is shown. (7) The above step, plus the server.xml configuration described farther down are all that is needed for browsers to access your applications via HTTPS. The other steps below allow HTTPS calls between applications (like between an app and the CAS single sign on webapp) to trust the self-signed certificates. (8) Export and import the server certificate. a. keytool -export -alias jbosskey -keypass changeit -file server.crt -keystore server.keystore b. The file server.crt is created. c. keytool -import -alias jbosscert -keypass changeit -file server.crt -keystore server.keystore d. You are given a warning that jbosskey already exists in the keystore. That is OK... you are storing the public certificate as jbosscert. e. keytool -list -keystore server.keystore f. You now see jbosscert (trustedCertEntry) in addition to jbosskey. (9) Configure jBoss to listen to HTTPS by modifying default/jboss-web.deployer/server.xml a. Uncomment the block near the top that starts with <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"... b. Add the following lines to the block: i. keystoreFile="${jboss.server.home.dir}/conf/server.keystore" ii. keystorePass="changeit" (10) Pass -Djavax.net.ssl.trustStore="<...>/server/default/conf/server.keystore" to your server start, so that it knows to use the keystore file as its truststore. a. In Windows, you may pass it as a parameter in the shortcut you use for jboss-as/bin/run.bat. b. In Eclipse (or any of its variants like RAD and myEclipse) using jBossTools, you may go to your jBossServer view, double click on the server, (take the opportunity to verify your hostname), click OpenLaunchConfiguration and add it to the program arguments. c. Or if you use a script to start jboss, add it there. (11) Tests. a. Vanilla access to jBoss' home page: http://<hostname>:8080/ b. HTTPS access to jBoss' home page: https://<hostname>:8443/ c. Vanilla access to one an application: http://<hostname>:8080/myApp i. If this failed, your server is grossly misconfigured. d. HTTPS access to the same application: https://<hostname>:8443/myApp i. If this failed, you have not achieved basic HTTPS connectivity. e. Access CAS: http://<hostname>:8080/cas i. f. Now, the final test. Access an application that has been enabled for Single Sign On through CAS. i. Once you hit a protected page, you are redirected to the CAS login page using HTTPS. ii. After login you are returned to your application. If you did not configure the trust correctly, this will fail. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
