Example Script to automate keytool commands

Products

Data Loss Prevention Data Loss Prevention Core Package Data Loss Prevention Enterprise Suite Data Loss Prevention Enforce Data Loss Prevention Plus Suite Data Loss Prevention Plus Suite

Issue/Introduction

This script is only an EXAMPLE that is used to automate the Java Keytool commands. This does not replace Java Keytool, this script simply demonstrates how you can make Java Keytool easier to access and use.

Environment

Windows Only

Cause

The primary purpose of this script is to help update the Enforce Console Certificate, though it will work for any scenario where you need to use the Java Keytool.

Resolution

DISCLAIMER:
- Should this example not function as intended, or cease functioning all together, please note that this will NOT be supported by Broadcom.
- This example is provided as-is, for your convenience, but is NOT supported by Broadcom.
- Please note that by using this example, you are doing so at your own risk. Broadcom is not liable for any damages that may be caused by the use of this example script.

CREATE A NEW ENFORCE CONSOLE CERTIFICATE
- Right-click and run the "certificates.bat" as Administrator
- If you have not set your JAVA_HOME environment variable, you will be prompted to enter in your JAVA_HOME directory.

- Next you will be prompted for the "Target Keystore", it is recommended that you simply hit "Enter" to use the default value which will look for a ".keystore" in the same directory you are running the certificates.bat script from. This will be our "working" keystore, all work should be done in this keystore, and then once the keystore has been prepped, you can simply swap out the production keystore without ever directly modifying the production keystore.

- Next you will be taken to the Menu.
- At the top of the Menu, you will see the values being used for your "JAVA_HOME" directory, and for your "Target Keystore"

- The "Target Keystore" should show a path to the same location that you are running the script from with the .keystore file. Note that while this is the target keystore, it does not actually exist at this time.
- The next step is to enter #3 to "Generate a new Certificate"

- This will walk you through each step to creating the Certificate. Each entry does have a default value, you can simply hit the "Enter" button to use the default value mentioned. In most cases the default values would be appropriate.

- Next you will be prompted for your DNAME information. Please note that the Syntax must match the example provided.

**Note: after each entry is a comma followed by a space, if you forget the spaces it will not work correctly.
**Note: CN is the only required field, the other fields can be added/removed by the customer if required.
CN(Common Name): This should be the FQDN for the server
OU(Organizational Unit): Can be anything
O(Organization): Can be anything
L(Location): This should be the City
ST(State): This should be the State
C(Country): This should be the Country
- Next you will be prompted for your SAN information

**Note: after each entry is a comma, but this time without a space. Again, this must be formatted correctly or it will fail.
**Note: Your server MUST be listed here in order to show as trusted, if the server as defined in the URL does not exist in the SAN information, then it will not be trusted.

SAN: Is only used at the start of data.
DNS: This is used to represent a servername or FQDN for example.
IP: This is used only if you are using an IP Address.
- Finally you will be prompted to enter in the keystore password. By default this password is "protect". Please note that this can also be changed at any time if required.

- At this point your "Self-Signed" certificate has been created.
- To create a CSR simply return to the Menu and enter #4 to "Generate a CSR"
- It is important to note that the script will save your Certificate data while the session is open. So you will not need to re-enter any of the information you already provided.

**Note at the bottom of the page it will provide the full filename and path for where the CSR was created.
- If you entered incorrect data, please simply close out the session and open a new session in order to clear the memory.
- You can now send this CSR to your CA, they will sign the CSR and send back a Certificate for you to import.
- Once you receive the signed Certificate, you simply need to import it into the same keystore.
**Note: The Certificate MUST be imported into the SAME keystore that the CSR was generated from. This is because it must have both the Public and Private portions of the certificate.
**Note: When you import the Certificate you MUST import it as the same name as the original Certificate (default: tomcat). This is because the certificate MUST contain both the public and private portions of the certificate. The self-signed portion of the certificate contains the private key, while the CA Signed portion that was sent back will contain the public key to be used.
- To import the Certificate go back to the Main Menu and select the appropriate option for importing your specific certificate type (most will fall under #7 Import Certificate).
- You will be prompted for the full filename and path for the Certificate.

- You will then be prompted for the "Alias" name. As mentioned this alias name by default should be "tomcat".
- You will then be prompted for the .keystore password (default: protect)
That's it, your keystore should now be ready.

APPLY THE CERTIFICATE TO YOUR ENVIRONMENT
To apply the new keystore we should go through the following steps...
- Stop the DLP Services (specifically the Manager Service)
- Backup your existing(production) keystore
Default: C:\Program Files\Symantec\DataLossPrevention\EnforceServer\16.0.10000\Protect\tomcat\conf\.keystore
- Replace your production .keystore with your working .keystore
Production: C:\Program Files\Symantec\DataLossPrevention\EnforceServer\16.0.10000\Protect\tomcat\conf\.keystore
Working: C:\Users\Administrator\Desktop\Server_Batch_Files\.keystore
**Note: The working keystore should exist wherever you ran the certificates.bat file from. The above example is where mine was run from, but yours may exist in a different location.
- Once the production .keystore has been replaced with the working .keystore, you simply need to restart the DLP Services in order for the new certificate to take effect.
**Note: If you run into any problems with the new keystore, simply restore your original production .keystore which you should have backed up before replacing. You must restart the services again before the original certificates will be restored.

CONFIRM THE CERTIFICATE IS BEING PRESENTED APPROPRIATELY
- When the login screen loads (this usually takes roughly 60 seconds after a service restart) you should see a lock icon in your browser just to the left of your URL

**Note: this may vary slightly depending on the browser used.
- First, if the lock is showing as locked like it is in the above screenshot, then the certificate is trusted which is a good sign.
- If the lock is showing as unlocked, then the certificate is not trusted.
- Click on the lock, and you should see an option to View/Open the certificate being presented.

- You can then confirm the details of the certificate match your new certificate.
- If you need more specific confirmation you can match the SHA256 value from your new certificate to the one being presented in the browser.
From the Browser Certificate:

From the .keystore Certificate:

- Here we can see that both the SHA1 and SHA256 match with the two certificates, which confirms the certificate being presented in the browser is the same one that we added in the .keystore.