This page is still a work-in-progress. Please forward feedback and
corrections to the author. Thank you!
Federico Lucifredi - flucifredi@novell.com
Starting point: SLES-9 installed; Birdman-050606-b build installed and running; logged in as root;
For the sake of precision, we check just what version of Tomcat we are actually poking at:
rc-qa-client-408:~ # rpm -qa | grep tomcat jakarta-tomcat-5.0.19-29.1 novell-zenworks-jakarta-tomcat-5.0.28-2.novell.1.14
I am the paranoid type, so I stopped *all* novell-* services existing in /etc/init.d/, but at a very minimum you should stop zenserver.
rc-qa-client-408:~ # /etc/init.d/novell-zenserver stop Shutting down Novell ZENworks done
Create a private RSA key for your tomcat server:
keytool -genkey -alias tomcat -keyalg RSA
Enter keystore password: foo's secret
What is your first and last name?
[Unknown]: rc-qa-client-408
What is the name of your organizational unit?
[Unknown]: irrelevant
What is the name of your organization?
[Unknown]: Novell, INC
What is the name of your City or Locality?
[Unknown]: Cambridge
What is the name of your State or Province?
[Unknown]: Massachusetts
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=rc-qa-client-408, OU=irrelevant, O="Novell, INC", L=Cambridge, ST=Massachusetts, C=US correct? (type "yes" or "no")
[no]: yes
Enter key password for <tomcat>
(RETURN if same as keystore password):
rc-qa-client-408:
important points: We did not specify a keystore (the -keystore <keystore-filename> option), which means that we are working on .keystore in root's home directory, which is fine and dandy, just keep it in mind. Further, you want to enter the fully qualified hostname of the server, also known as hostname+domain, in the "first and last name" field, and resist the temptation of typing funny stuff in the other fields, because Verisign's prescience will see through your lies and inconsistencies -- In particular, fill the "State or Province" field with the full name of your state, not the two letter code, as it will not pass Verisign's filters -- "People's Republic of Cambridge" won't cut it, I am afraid. Additionally, when prompted for a <tomcat> password, you *MUST* default to the one you originally provided for the keystore, you can conveniently do so by pressing enter. Finally, when Verisign *does* reject your signature request (you silly monkey!), you can use keytool -delete -alias tomcat and then generate a new key.
Now we need to create a CSR (certificate signing request):
mkdir -p -m go= /etc/ssl/private keytool -certreq -keyalg RSA -alias tomcat -file /etc/ssl/private/certreq.csr
We are using the Verisign trial certificate for this. Go to their homepage, click on the "Free SSL Trial" link, they are too smart to design a website that allows a direct link ;)
The first page is irrelevant, all that they really want is a way to spam you, which unfortunately you must give them as your precious certificate will come in your email -- but the other fields don't matter for the certificate itself.
The second form (technical contact) likely does not matter also, but you do not want to wind up refilling Verisign forms all day, so enter information that matches *both* what you entered in your RSA key and in the previos page.
The Third form (CSR) is the one that really matters. Select "other" as your server platform, and using a proper text editor that does not murk up your key (vi), cut and paste the contents of your certreq.csr. Now, if you followed my suggestion and typed a first and last name that matches your machine+domain name, your state or province's full name and "US" as your country code, Verisign just might sign you over a trial certificate. If they complain about something, go back to step one, generate another RSA key, and go at it again, if not, just wait for the email with your preciousssss signed certificate, which you will save in /etc/ssl/Verisign-signed-cert.txt. Make damn sure that you get only the certificate in your text files, with no trailing whitespaces or line feeds, because keytool is very sensitive to trailing garbage and you might wind up wondering what's going on at two o'clock in the morning...
While you wait, you can spend your time productively by installing the test CA root in EVERY browser you plan to use as part of your testing. Go to this page and download the "Secure Site Trial Root CA Certificate", (save it into /etc/ssl/Verisign-trial-root.txt), and the "Secure Site Trial Intermediate CA Certificate" (/etc/ssl/Verisign-trial-intermediate.txt). Now, it is beyond me why Verisign is issuing these intermediate certificates, but as it does not hurt we will just install both. Go to your web browser, and import Verisign-trial-root.txt among the trusted certificate authorities. It is probably not necessary to include the intermediate certificate as well (it is suposed to be a chain of trust, after all), but I did so anyway.
Now, we will similarly include these certs into the system keychain:
rc-qa-client-408:~ # keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts -alias verisign-trial-root -trustcacerts -file /etc/ssl/Verisign-trial-root.txt
Enter keystore password: changeit
Owner: CN=VeriSign Trial Secure Server Test Root CA, OU="For Test Purposes Only. No assurances.", O="VeriSign, Inc.", C=US
Issuer: CN=VeriSign Trial Secure Server Test Root CA, OU="For Test Purposes Only. No assurances.", O="VeriSign, Inc.", C=US
Serial number: 20a897aedb8202dec136a04e26bd8773
Valid from: 2/8/05 7:00 PM until: 2/8/25 6:59 PM
Certificate fingerprints:
MD5: B6:9D:A4:40:52:02:50:0D:D5:9C:E1:B8:4B:66:C4:AC
SHA1: 81:A7:B1:CA:51:66:D1:2D:CB:32:CA:00:21:C3:9E:49:54:73:56:65
Trust this certificate? [no]: yes
Certificate was added to keystore
rc-qa-client-408:~ # keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts -alias verisign-trial-intermediate -trustcacerts -file /etc/ssl/Verisign-trial-intermediate.txt
Enter keystore password: changeit
Certificate was added to keystore
rc-qa-client-408:~ #
Note that the system does not ask you wether the intermediate certificate should be trusted, as it is automagically because of the trust placed in the root cert (and further showing that we can really throw the intermediate away!). Do note, however, that the default password for the Java system-wide keystore is "changeit".
Now we include the signed certificate in our own keystore (~/.keystore), so that it forms a chain of trust between the CA and the original keypair we generated:
rc-qa-client-408:~ # keytool -list Enter keystore password: foo's secret Keystore type: jks Keystore provider: IBMJCE Your keystore contains 1 entry tomcat, Jun 9, 2005, keyEntry, Certificate fingerprint (MD5): 4B:E0:15:1D:05:46:D3:6C:45:4D:CE:E3:B2:95:92:6A rc-qa-client-408:~ # keytool -import -alias tomcat -trustcacerts -file /etc/ssl/Verisign-signed-cert.txt Enter keystore password: foo's secret Certificate reply was installed in keystore
We can use verbose (-v) to verify that <tomcat> now has a chained, certified response on top of the original keypair.
rc-qa-client-408:~ # keytool -list
Enter keystore password: foo's secret
Keystore type: jks
Keystore provider: IBMJCE
Your keystore contains 1 entry
tomcat, Jun 10, 2005, keyEntry,
Certificate fingerprint (MD5): 6E:87:FE:51:CC:5C:75:9F:B3:99:FD:7F:FC:2A:89:D5
rc-qa-client-408:~ # keytool -list -v
Enter keystore password: foo's secret
Keystore type: jks
Keystore provider: IBMJCE
Your keystore contains 1 entry
Alias name: tomcat
Creation date: Jun 10, 2005
Entry type: keyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=rc-qa-client-408, OU=Terms of use at www.verisign.com/cps/testca (c)05, OU=irrelevant, O="Novell, INC", L=Cambridge, ST=Massachusetts, C=us
Issuer: CN=VeriSign Trial Secure Server Test Root CA, OU="For Test Purposes Only. No assurances.", O="VeriSign, Inc.", C=US
Serial number: 67a0594c7bfe8947d4616ab825af987c
Valid from: 6/9/05 8:00 PM until: 6/24/05 7:59 PM
Certificate fingerprints:
MD5: 6E:87:FE:51:CC:5C:75:9F:B3:99:FD:7F:FC:2A:89:D5
SHA1: 76:37:84:4C:5E:E5:BC:67:19:98:8E:3A:29:44:42:6D:68:22:E7:02
Certificate[2]:
Owner: CN=VeriSign Trial Secure Server Test Root CA, OU="For Test Purposes Only. No assurances.", O="VeriSign, Inc.", C=US
Issuer: CN=VeriSign Trial Secure Server Test Root CA, OU="For Test Purposes Only. No assurances.", O="VeriSign, Inc.", C=US
Serial number: 20a897aedb8202dec136a04e26bd8773
Valid from: 2/8/05 7:00 PM until: 2/8/25 6:59 PM
Certificate fingerprints:
MD5: B6:9D:A4:40:52:02:50:0D:D5:9C:E1:B8:4B:66:C4:AC
SHA1: 81:A7:B1:CA:51:66:D1:2D:CB:32:CA:00:21:C3:9E:49:54:73:56:65
*******************************************
*******************************************
rc-qa-client-408:~ #
We are done. Now we just install the damn thing:
rc-qa-client-408:~ # mv ~/.keystore /opt/novell/zenworks/share/keystore rc-qa-client-408:~ # chown zenworks:zenworks /opt/novell/zenworks/share/keystore
The change of ownership is because zenserver is suposed to run as user zenworks (-Peter). As I see all files in that directory still owned by root, maybe that is not the case yet, but it certainly doesn't hurt (and people tend to forget about permissions *later*) to do it anyway. Finally, edit /opt/novell/zenworks/share/tomcat/conf/server.xml and make sure that the SSL <connector> entry (port 443) has a keystorePass attribute matching your keystore and certificate password, in this case, "foo's secret".
Before you start thinking something is awfully wrong, restart the Novell service(s) you shut down, or reboot and take a coffee break :)
Installing a real certificate is done the same way, except that you don't need to import the CA root certificate in the system-wide keystore, as it is already there (or deriving authority from one that is).
NOTES:
a) If anyone can explain the need (or absolute lack thereof) for intermediate certs, I would be happy to know.
created 2005-06-09 - last modified 2005-06-10 - http://primates.ximian.com/~flucifredi/