The following steps guide you through the X.509 client certificate acquisition process so that you may complete secure a web service.
Within the Java programming framework, X.509 certificates are managed through containers called keystores. Keystores can contain certificates that identify the machine on which the keystore resides (your machine) and that identify other machines, such as machines providing services for your machine when acting as a client.
The following steps will create two separate keystores. One will be used to house and manage the certificate that you will request be created to identify your machine. This keystore may be used by you to house additional certificates that identify your machine, should you wish. The other keystore will be used to house certificates that identify other machines; these other machines are those you will trust by virtue of the placement of their certificates into this special keystore, which henceforth is called a trust store. Note that your Java framework will already have, upon installation, a trust store file named cacerts, and this file contains a few dozen Certificate Authorities' root certificates. One would not want certificates signed by these CAs to be trusted for WIJIS purposes, and this is why this guide steps you through the creation of a new trust store.
So, one keystore and one trust store will be created by the time you complete this guide. The keystore will be used to manage the certificate identifying your machine, and the trust store will be used to manage the trusted certificates of other machines. This trust store shall be used to manage only the WIJIS certificate authority's (CA) certificates. It is through this trust you place in the WIJIS CA that one critical facet is accomplished of authenticating the identity of another machine when its certificate is signed by the WIJIS CA and when it is engaged in a WIJIS Gateway transaction with your machine.
WIJIS requires all certificates for identifying machines in WIJIS transactions to be signed by the WIJIS Certificate Authority (CA). You will create a Certificate Signing Request (CSR) and send it to the WIJIS CA for its signature.
Choose a location in your file directory on a disk volume that will be mounted and available to the services software that is to run on your machine. At this location, create a directory that will serve as the location for the keystore and trust store. When you have completed the steps of this guide, ensure that the resulting keystore and trust store files have the appropriate file permissions set so that your software's run-as context may read them.
Ensure that your operating system's environment variables for 'path', 'java
home', and 'jre home'
are set appropriately to the latest version of the jdk that is supported on your machine. This
way, the following steps that show command line invocations of the keytool will
work for you.
On Unix-variants, you may have any one or more of the following commands available to you for
viewing your enviroment variables: env, printenv, or echo.
In some circumstances, you may have to prefix a dollar sign $ to the variable name.
On Windows, use the echo command for
viewing your enviroment variables, such as echo %JAVA_HOME%.
You have to prefix and postfix a percent sign % to the variable name.
If it turns out that the environment variables are not set appropriately, please follow your
operating system's documentation for setting them (such as set on Windows and
setenv on most Unix variants).
Some users may have already requested a certificate and corresponding private key. An example of this is if you use python as your web services client. In this case you don't need to generate a new certificate request and can import your private key and certificate into a new keystore. Please skip this section if this is not applicable to you.
To import your private key and certificate into a keystore, you will need to have Openssl and Java already installed. The installation of these software products is beyond the scope of this document but WIJIS staff can help you with this.
Convert you existing certificate and private key from PEM format to DER format
openssl pkcs8 -topk8 -nocrypt -in privatekey.key -inform PEM -out privatekey.der -outform DER
openssl x509 -in MyCertificate.cer -inform PEM -out MyCertificate.der -outform DER
If your private key has a passphrase on it, you should remove the passphrase prior to doing this:
openssl rsa -in privatekey.key -out privatekey.key
Run this Java Utility to import your key into a keystore (Here is the source code, if you are interested):
java ImportKey privatekey.der MyCertificate.der
The output should look like this:
Using keystore-file : C:\Documents and Settings\Administrator\keystore.ImportKey
One certificate, no chain.
Key and certificate stored.
Alias:importkey Password:importkey
A Keystore was created with the name 'keystore.ImportKey'. If you desire a different name/location you can rerun the command above with the switch '-Dkeystore=mykeystore'.
We can now change the password for the keystore and the private key. These passwords both default to 'importkey'. To change the password, execute the following commands:
keytool -storepasswd -keystore keystore.ImportKey
Enter keystore password: importkey
New keystore password: changeit
Re-enter new keystore password: changeit
keytool -keypasswd -keystore keystore.ImportKey -alias importKey
Enter keystore password: changeit
Enter key password for <importKey>importkey
New key password for <importKey>: changeit
Re-enter new key password for <importKey>: changeit
You can now proceed to the section 'Installing the Trusted Certificate Authority Chain'.
Ensure your command shell's current directory location is the keystore file directory you created in the first step.
Use the keytool -genkey option.
This command initiates a dialog where you will need to respond to several prompts. Enter values for
YOUR installation and don't use the defaults when prompted. WIJIS can help you determine these
values if assistance is needed.
Again, please use values for YOU, such as the city and machine's hostname that make sense for your environment. The following illustration serves only as an example.
If you enter a keystore filename that does not yet exist, a new keystore will be created for you containing the private key you are generating. The use of 'changeit' as a password is just an example password for keytool operations. If you have changed the password on the keystore,
keytool -storepasswd -keystore /path/to/keystore/filename -storepass current_password -new new_password
Certain environments that use keystores, such as Tomcat, expect and require that the password for the keystore matches the password for the key it needs within the keystore. Therefore, if this situation applies to you, you should ensure that any key your environment is using within the keystore gets its password changed, too, when you change the password on the keystore itself. So, after executing the command line statement above to change the keystore's password, execute the command line statement shown below. Note that the current password of the key may be the same as the old password of the keystore, but that depends on your particular situation.
keytool -keypasswd -keystore /path/to/keystore/filename -alias theAliasOfTheKeyYouWant
Enter keystore password: keystore_current_password
Enter key password for <theAliasOfTheKeyYouWant>current_password_of_the_key
New key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Re-enter new key password for <theAliasOfTheKeyYouWant>: keystore_current_password
keytool -genkey -alias WijisServices -keyalg RSA -keystore ./MyKeystore.key
For the above step, it does not matter what you enter for the common name (the prompt for first & last name) in
development, but in production this should be the fully qualified name of the computer that is in the local
agency's DMZ and whose host name can be resolved on the Internet.
Enter keystore password: changeit
What is your first and last name?
[Unknown]: mymachine.mydomainname.com
What is the name of your organizational unit?
[Unknown]: wijis
What is the name of your organization?
[Unknown]: hometownpolicedept
What is the name of your City or Locality?
[Unknown]: hometown
What is the name of your State or Province?
[Unknown]: wi
What is the two-letter country code for this unit?
[Unknown]: us
Is CN=mymachine.mydomainname.com, OU=wijis, O=hometownpolicedept, L=hometown, ST=wi, C=us correct?
[no]: y
Enter key password for <WijisServices>
(RETURN if same as keystore password):
Use the keytool -list option.
Assuming you created a new keystore in the previous step, you will see results similar to the illustration below,
which displays just one key in the keystore.
keytool -list -v -keystore ./MyKeystore.key
The use of 'changeit' as a password is just an example password for keytool operations.
If you have changed the password on the keystore,
Enter keystore password: changeit
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: wijisservices
Creation date: Dec 7, 2006
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=mymachine.mydomainname.com, OU=wijis, O=hometownpolicedept, L=hometown, ST=wi, C=us
Issuer: CN=mymachine.mydomainname.com, OU=wijis, O=hometownpolicedept, L=hometown, ST=wi, C=us
Serial number: 0578825e
Valid from: Thu Dec 07 15:06:38 CST 2006 until: Wed Mar 07 15:06:38 CST 2007
Certificate fingerprints:
MD5: B0:A2....... etc
SHA1: 3A:ED....... etc
keytool -storepasswd -keystore /path/to/keystore/filename -storepass current_password -new new_password
Certain environments that use keystores, such as Tomcat, expect and require that the password for the keystore matches the password for the key it needs within the keystore. Therefore, if this situation applies to you, you should ensure that any key your environment is using within the keystore gets its password changed, too, when you change the password on the keystore itself. So, after executing the command line statement above to change the keystore's password, execute the command line statement shown below. Note that the current password of the key may be the same as the old password of the keystore, but that depends on your particular situation.
keytool -keypasswd -keystore /path/to/keystore/filename -alias theAliasOfTheKeyYouWant
Enter keystore password: keystore_current_password
Enter key password for <theAliasOfTheKeyYouWant>current_password_of_the_key
New key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Re-enter new key password for <theAliasOfTheKeyYouWant>: keystore_current_password
keytool -certreq -alias WijisServices -keyalg RSA -keystore ./MyKeystore.key -file ./MyCSR.csr
The use of 'changeit' as a password is just an example password for keytool operations.
If you have changed the password on the keystore,
Enter keystore password: changeit
keytool -storepasswd -keystore /path/to/keystore/filename -storepass current_password -new new_password
Certain environments that use keystores, such as Tomcat, expect and require that the password for the keystore matches the password for the key it needs within the keystore. Therefore, if this situation applies to you, you should ensure that any key your environment is using within the keystore gets its password changed, too, when you change the password on the keystore itself. So, after executing the command line statement above to change the keystore's password, execute the command line statement shown below. Note that the current password of the key may be the same as the old password of the keystore, but that depends on your particular situation.
keytool -keypasswd -keystore /path/to/keystore/filename -alias theAliasOfTheKeyYouWant
Enter keystore password: keystore_current_password
Enter key password for <theAliasOfTheKeyYouWant>current_password_of_the_key
New key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Re-enter new key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Take caution. Do not export and send the private key. The private key is to reside only on your local machine. To distribute the private key to any other person or machine would compromise the integrity of the certificate and compromise the overall security of the certificate's use.
Now wait until your CSR gets signed.
Once your CSR is approved with proper authorization, it will be sent back to you compressed as a RAR file.
To a new trust store, first add the root certificate and then add the intermediary certificate.
To a new trust store, add the root certificate.
keytool -import -alias WijisRoot -keystore ./MyTrustStore.key -trustcacerts -file ./WIJIS-CA01_Root.cer
The use of 'changeit' as a password is just an example password for keytool operations.
If you have changed the password on the keystore,
Enter keystore password: changeit
Owner: CN=WIJIS-CA01, OU=WIJISCA, O=Wisconsin Justice Information Sharing, L=Madison, ST=Wisconsin, C=US, EMAILADDRESS=Tech@wijis.state.wi.us
Issuer: CN=WIJIS-CA01, OU=WIJISCA, O=Wisconsin Justice Information Sharing, L=Madison, ST=Wisconsin, C=US, EMAILADDRESS=Tech@wijis.state.wi.us
Serial number: 45a539a1cf9e00ab48491e34dc04f192
Valid from: Thu Oct 10 11:12:33 CDT 2002 until: Sat Aug 07 14:12:12 CDT 2010
Certificate fingerprints:
MD5: CB:D2....... etc
SHA1: 16:58....... etc
Trust this certificate? [no]: y
Certificate was added to keystore
keytool -storepasswd -keystore /path/to/keystore/filename -storepass current_password -new new_password
Certain environments that use keystores, such as Tomcat, expect and require that the password for the keystore matches the password for the key it needs within the keystore. Therefore, if this situation applies to you, you should ensure that any key your environment is using within the keystore gets its password changed, too, when you change the password on the keystore itself. So, after executing the command line statement above to change the keystore's password, execute the command line statement shown below. Note that the current password of the key may be the same as the old password of the keystore, but that depends on your particular situation.
keytool -keypasswd -keystore /path/to/keystore/filename -alias theAliasOfTheKeyYouWant
Enter keystore password: keystore_current_password
Enter key password for <theAliasOfTheKeyYouWant>current_password_of_the_key
New key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Re-enter new key password for <theAliasOfTheKeyYouWant>: keystore_current_password
It is very important that you secure the access to trust store files to only staff who are authorized to make changes to them. The placement of any signing CA certificate into any trust store your software and system may use is a critically important change to your security scheme.
To the same trust store, add the intermediary certificate.
keytool -import -alias WijisIntermediary -keystore ./MyTrustStore.key -trustcacerts -file ./DevCA.cer
The use of 'changeit' as a password is just an example password for keytool operations.
If you have changed the password on the keystore,
Enter keystore password: changeit
Certificate was added to keystore
keytool -storepasswd -keystore /path/to/keystore/filename -storepass current_password -new new_password
Certain environments that use keystores, such as Tomcat, expect and require that the password for the keystore matches the password for the key it needs within the keystore. Therefore, if this situation applies to you, you should ensure that any key your environment is using within the keystore gets its password changed, too, when you change the password on the keystore itself. So, after executing the command line statement above to change the keystore's password, execute the command line statement shown below. Note that the current password of the key may be the same as the old password of the keystore, but that depends on your particular situation.
keytool -keypasswd -keystore /path/to/keystore/filename -alias theAliasOfTheKeyYouWant
Enter keystore password: keystore_current_password
Enter key password for <theAliasOfTheKeyYouWant>current_password_of_the_key
New key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Re-enter new key password for <theAliasOfTheKeyYouWant>: keystore_current_password
To the existing keystore, add the root certificate.
keytool -import -alias WijisRoot -keystore ./MyKeystore.key -trustcacerts -file ./WIJIS-CA01_Root.cer
The use of 'changeit' as a password is just an example password for keytool operations.
If you have changed the password on the keystore,
Enter keystore password: changeit
Owner: CN=WIJIS-CA01, OU=WIJISCA, O=Wisconsin Justice Information Sharing, L=Madison, ST=Wisconsin, C=US, EMAILADDRESS=Tech@wijis.state.wi.us
Issuer: CN=WIJIS-CA01, OU=WIJISCA, O=Wisconsin Justice Information Sharing, L=Madison, ST=Wisconsin, C=US, EMAILADDRESS=Tech@wijis.state.wi.us
Serial number: 45a539a1cf9e00ab48491e34dc04f192
Valid from: Thu Oct 10 11:12:33 CDT 2002 until: Sat Aug 07 14:12:12 CDT 2010
Certificate fingerprints:
MD5: CB:D2....... etc
SHA1: 16:58....... etc
Trust this certificate? [no]: y
Certificate was added to keystore
keytool -storepasswd -keystore /path/to/keystore/filename -storepass current_password -new new_password
Certain environments that use keystores, such as Tomcat, expect and require that the password for the keystore matches the password for the key it needs within the keystore. Therefore, if this situation applies to you, you should ensure that any key your environment is using within the keystore gets its password changed, too, when you change the password on the keystore itself. So, after executing the command line statement above to change the keystore's password, execute the command line statement shown below. Note that the current password of the key may be the same as the old password of the keystore, but that depends on your particular situation.
keytool -keypasswd -keystore /path/to/keystore/filename -alias theAliasOfTheKeyYouWant
Enter keystore password: keystore_current_password
Enter key password for <theAliasOfTheKeyYouWant>current_password_of_the_key
New key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Re-enter new key password for <theAliasOfTheKeyYouWant>: keystore_current_password
It is very important that you secure the access to key store files to only staff who are authorized to make changes to them. The placement of any signing CA certificate into any key store your software and system may use is a critically important change to your security scheme.
To the same key store, add the intermediary certificate.
keytool -import -alias WijisIntermediary -keystore ./MyKeystore.key -trustcacerts -file ./DevCA.cer
The use of 'changeit' as a password is just an example password for keytool operations.
If you have changed the password on the keystore,
Enter keystore password: changeit
Certificate was added to keystore
keytool -storepasswd -keystore /path/to/keystore/filename -storepass current_password -new new_password
Certain environments that use keystores, such as Tomcat, expect and require that the password for the keystore matches the password for the key it needs within the keystore. Therefore, if this situation applies to you, you should ensure that any key your environment is using within the keystore gets its password changed, too, when you change the password on the keystore itself. So, after executing the command line statement above to change the keystore's password, execute the command line statement shown below. Note that the current password of the key may be the same as the old password of the keystore, but that depends on your particular situation.
keytool -keypasswd -keystore /path/to/keystore/filename -alias theAliasOfTheKeyYouWant
Enter keystore password: keystore_current_password
Enter key password for <theAliasOfTheKeyYouWant>current_password_of_the_key
New key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Re-enter new key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Now you will import your machine's signed certificate into your keystore where the private key is housed. Note the result message that is output when you have correctly married up the signed certificate with its private key differs from the message when a signed certificate is imported without any matching private key.
keytool -import -alias WijisServices -keystore ./MyKeystore.key -trustcacerts -file MyCSR.cer
The use of 'changeit' as a password is just an example password for keytool operations.
If you have changed the password on the keystore,
Enter keystore password: changeit
Certificate reply was installed in keystore
keytool -storepasswd -keystore /path/to/keystore/filename -storepass current_password -new new_password
Certain environments that use keystores, such as Tomcat, expect and require that the password for the keystore matches the password for the key it needs within the keystore. Therefore, if this situation applies to you, you should ensure that any key your environment is using within the keystore gets its password changed, too, when you change the password on the keystore itself. So, after executing the command line statement above to change the keystore's password, execute the command line statement shown below. Note that the current password of the key may be the same as the old password of the keystore, but that depends on your particular situation.
keytool -keypasswd -keystore /path/to/keystore/filename -alias theAliasOfTheKeyYouWant
Enter keystore password: keystore_current_password
Enter key password for <theAliasOfTheKeyYouWant>current_password_of_the_key
New key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Re-enter new key password for <theAliasOfTheKeyYouWant>: keystore_current_password
Note: These instructions are subsequent to the initial creation and configuration of your trust store. Read those instructions first, which may be found in this Submitter Developers' Guide. You must monitor the expiration dates of the certificates and revocation lists you have in your stores. Just prior to expiration, you must acquire the replacement and install it following these instructions.
You should follow the steps immediately above that you did previously for installing the Trusted Root CA Cert and Trusted Intermediary CA Cert into the trust store, which you already set up on prior occasion. This time, you will be installing the new, additional CA chain that WIJIS delivered to you. However, you will instead use a new and unique alias to identify each newly added certificate. For example, you may have used an alias before called 'WijisRoot' for the trusted root certificate. This time, use something different. An IMPORTANT Note: If you already have the root CA certificate in your trust store, as would those agencies who already participate in other DOJ or WIJIS data exchanges, then you should not re-import it unless you have been instructed to conduct a replacement of that root CA cert.
If you have been issued a replacement end-entity certificate for your server, then continue by also installing the Trusted Root CA Cert and Trusted Intermediary CA Cert into the keystore, which you already set up on prior occasion, along with your new end-entity certificate. However, you will instead use a new and unique alias to identify each newly added certificate. For example, you may have used an alias before called 'WijisRoot' for the trusted root certificate. This time, use something different. An IMPORTANT Note: If you already have the root CA certificate in your keystore, as would those agencies who already participate in other DOJ or WIJIS data exchanges, then you should not re-import it unless you have been instructed to conduct a replacement of that root CA cert.
In httpd.conf or in httpd-ssl.conf (which ever you are using), you have two options: file or path. For Windows platforms, only one of these two may be used, and that option is file.
Within the appropriate virtual host, such as the one you have set up for RecordRetrieval:
Add or uncomment:
SSLVerifyClient require
Add:
SSLVerifyDepth 2
Using the option you prefer, add or uncomment:
SSLCARevocationFile or SSLCARevocationPath
and assign the correct value.
Using the option you prefer, add or uncomment:
SSLCACertificateFile or SSLCACertificatePath
and assign the correct value.
For the path option, place all root CA and intermediate CA certs along with symlinked hash values, as per Apache's instructions, in the directory you specified. Also, place all root CA and intermediate CA revocation lists along with symlinked hash values, as per Apache's instructions, in the directory you specified.
For the file option, you must use PEM encoded files rather than DER encoded files. When it comes to CRLs that are published on the web as CDP locations, the most frequent format in use is DER. So, if you acquire a CRL in this fashion, you will likely need to convert the format to PEM before proceeding. Start with the certificates. Simply append the PEM encoded certificate files together: all the root CAs and all the intermediate CAs. Take care that lines in the file aren't merged together; try to preserve the line breaks. This master file is then saved to the location you assigned to SSLCACertificateFile. Repeat for the CRLs. Simply append the PEM encoded revocation lists together: all the root CAs and all the intermediate CAs. Take care that lines in the file aren't merged together; try to preserve the line breaks. This master file is then saved to the location you assigned to SSLCARevocationFile.
The PEM encoded data must include the header and footer lines and no other content. But each such PEM encoded data can be appended together. So, such a file will start with one header line, followed by PEM encoded content, followed by its footer line, followed by a header line, followed by PEM encoded content, etc, and will wind up having a single footer line at the end of the file.
Following installation of a new CRL, Apache must be restarted. Alternatively,
you can patch Apache on Unix variants for dynamic reloading of CRLs. For the patch, go
to apache bug 14104 and scroll to the bottom.
For restarting Apache on Unix variants, use:
apachectl -k graceful
On Windows, use
httpd.exe -k restart
Without CRL checking, Tomcat can conduct certificate authentication. Simply follow Tomcat documentation. In the <Connector> configuration (in server.xml), make the appropriate SSL/TLS settings for your environment and set clientAuth to "true". Also include keystoreFile, keystorePass, truststoreFile, and truststorePass. The format of the keystore and truststore both need to be the same (e.g. JKS formatted files). If you have more than one key in your keystore, you will also have to include the keyAlias attribute within the <Connector> configuration to specify the exact key you wish to use. The passwords/passphrases on the various keys within your keystores must be the same as that which you have used for the keystores themselves. You can try to use a CRL, too. This was tested unsuccessfully at WIJIS, however. To include CRL checking, in your <Connector> configuration, define the attribute crlFile="path/to/crl.file". This theoretically could be a file containing a bundle of appended CRLs, but again, this was unsuccessful in testing at WIJIS on Tomcat 6.
Note that it appears Tomcat returns to the client only one SSL/TLS error message no matter what the reason was for denying authentication of the client-submitted certificate. That one message is "sslv3 alert certificate unknown" regardless of whether the cert's CA was untrusted, the cert was expired, or the cert was revoked.
In some cases, it is necessary to export the private key from the keystore. This could be the case if you need to run a test script which required the private key and certificate file in PEM format (most of our python test script examples require this).
To export the private key, you can use this class file (here is the source code).
To run this utility, enter the following:
java ExportPrivateKey MyKeystore.key aliasNameOfKey passphrase
The output should be similar to this:
-----BEGIN PRIVATE KEY----- RIICdwIBADANBgkqhkiG9w0BAQEFAASCAREwggJdAgEAAoGBAI9V1ukXngStWoQVhUD1osCzrotZ j54URLgh5j9nUUGW3+q4UTfPwpcxRrdFESLk3b04yW2N+CsgNcT0GWj97byvAAYON75fT9r8DzX3 WQUG5LcnOKwXHWLhIhYp8GkHwc4H34cPjWP/Rwdt804xltP434OLUgpjQuLTRNPtaTwHDcQldVcoRp pdJnJRNBcjBkCR42NORgPU64YCiubv4ddjcCQQCYiPdRrAS/3pPr/NFIsvj15l/5FStnzeS/LS0w +tLCRfV2PKu+BO2c38H34nFzTX8txcUq5aEer7l7AgxH7EVRxAkEA7gjjTVu/SiPR1OAoxFESA34E0 uGKa8B6xFcOWVARgbBKeRyyvJGRr3457PRwHrcOzi2N2O3z8HSKaa8Rn5NQOzTRvH6Y4HXycqL7EC QBT5/cO4bvEZj2SzOWUORC0bjG56M+uQo7YKGE1BFgTmvovuOi5EkRWlLiMHTW4t2NmU+I7Kc2Xl HPZHQBw0343E= -----END PRIVATE KEY-----
WIJIS has written an Record Retrieval Service reference implementation using JAXB and Xfire. This has already been customized and deployed for some WIJIS submitting agenices. Please contact WIJIS to get the latest source code and dependencies. Due to its size, this has not been included in the developer guide. You can, however, download it from here. Once you get this zip file, please contact WIJIS for instructions on how to build the web service.
Prior to working on the code, please configure your application server using the instructions below.
The WIJIS java reference implementation was built using Apache Tomcat. Tomcat is available for download here. You can probably use other Java Application Servers, however we decided to use tomcat because it is free, reliable, and easy to use.
If you are using windows, tomcat has an installer. Unix/Linux users can untar the distribution. Users on both platforms should set both their JAVA_HOME and CATALINA_HOME system variables. WIJIS staff can assist with tomcat installations.
Here are the steps to configure tomcat to require https and client certificates
To confirm, you can either write a test client which sends a client certificate or use the python script that WIJIS provides. This script requires a private key and certificate in seperate files so you might have to export your private key from your keystore.
After running the script, you should be returned the 'index.jsp' page of the default Tomcat installation. The contents of this page will roughly match this file.