To configure TLS communications, create TLS certificates and create data stores to hold those certificates. A server certificate represents the CA Automation Point/Tomcat server. Depending on your security needs you can also choose to create a client certificate.
The Apache Tomcat server and the optional CA RequestService client both understand Java keystore files, therefore this document only describes the use of Java keystore files and certificates. When not using the RequestService client, Tomcat PKCS11 or PKCS12 format keystores can be configured. These two additional options are beyond the scope of this manual.
A server in a TLS conversation (in this case Tomcat) has a keystore in which it stores the certificates that authenticate the server. The server sends its certificate to a client during TLS negotiation. A client has a truststore, in which it stores certificates that it is willing to trust. The client confirms the certificate that is sent by the server during TLS negotiations against the client’s truststore.
Certificate Authorities, like VeriSign, Entrust, and DigiCert can be used to sign a given server’s certificate. With a signed certificate, a client does not need a certificate from every server in the world stored in its truststore. If the client trusts the Certificate Authority, it knows that it can trust a signed certificate that it receives from an otherwise unknown server. Public web server applications often use this type of approach, because of the sheer volume of clients and servers. Obtaining a certificate that is signed by a Certificate Authority is beyond the scope of this document.
A CA Automation Point server is typically deployed into a more confined corporate intranet. The time and cost of obtaining a certificate that is signed by a Certificate Authority may not be warranted for this more restricted deployment. Create a self-signed certificate for your server, place it into the server’s keystore and into the client’s truststore. This procedure configures a secure encrypted communication channel. Such a deployment remains practical as long as the number of AP clients and servers is no more than a few dozen computers.
When using the CA RequestService client, you can configure RequestService to ignore server certificates. By so doing, the client loses its ability to authenticate the server, however all data is securely encrypted. When you are confident that no rogue server exists behind your corporate firewall that can impersonate an AP server for destructive purposes, this configuration has the advantage that you only configure a server certificate into Tomcat’s keystore. You do not need to deploy any server certificates into any client truststores. This is the minimal configuration that can be used to create a TLS connection between a remote client and the CA Automation Point/Tomcat server.
Each client web service request contains a user ID and password and can be sufficient client authentication for your site. However, you can also optionally configure the additional TLS security of client-side certificates. Client certificates are signed by a Certificate Authority or the client certificates are self-signed just like server certificates. In this scenario, set up Tomcat’s TLS configuration to demand a client certificate. Create a client certificate and store it into the client’s keystore and into the Tomcat truststore. This technique is essentially the reverse of the procedure that is used to deploy a server certificate. Do this procedure for every remote client in your environment. During TLS negotiation, Tomcat asks the client for its certificate. The client retrieves its certificate from its keystore and sends it to Tomcat. Tomcat verifies the certificate against the Tomcat truststore. Through this procedure, Tomcat verifies that the client application can be trusted.
Note: CA Technologies web service will still perform its user ID and password verification on the request.
You can create keystores and truststores (both of which are formatted as Java keystore files) with a program named keytool from your Java Runtime environment. That program can be found in YourJavaInstallationDirectory\bin\keytool. Keytool can also create a self-signed certificate, place a certificate into a keystore, import a Certificate Authority signed certificate, export a certificate from a keystore, and import a certificate into a truststore. Using these capabilities of keytool, you can create the various scenarios described in this section. Read the documentation for keytool to understand the details that are required to accomplish those steps.
Copyright © 2012 CA. All rights reserved. |
|