Creating New Certificates for Data Center Security
search cancel

Creating New Certificates for Data Center Security

book

Article ID: 216431

calendar_today

Updated On:

Products

Data Center Security Monitoring Edition Data Center Security Server Data Center Security Server Advanced

Issue/Introduction

Creating new certificates for Data Center Security

Environment

Data Center Security (DCS)
Data Center Security: Server
Data Center Security: Server Advanced
Data Center Security: Monitoring Edition

Resolution

If your certificates are available to third parties for viewing, then you must generate new certificates and explicitly provide the Common Name (CN), Organizational Unit and Subject Alternative Name (SAN) record details. Some organizations may be required to use corporate-provided or Certificate Authority (CA)-provided certificates, in which case you would also need to customize the certificates after installation.

You may also want to check out The Data Center Security (DCS) 6.9.x Certificate Utility.

To create new encryption keys (certs) for Data Center Security: Server

1.  Save a backup copy of server.xml available at:

C:\Program Files (x86)\Symantec\Data Center Security Server\Server\tomcat\conf

If you are upgrading from a previous version to Data Center Security: Server 6.6 and later, then the server.xml file is available at:

%programfiles%\Symantec\Critical System Protection\server\tomcat\conf from the server.xml file.

2.  Open the Server.xml file in a text editor from the following file location:

 C:\Program Files (x86)\Symantec\Data Center Security Server\Server\tomcat\conf\server.xml

3.  Search for port='4443' to find the Console (port 4443) connector and SSL configuration, or search on port='443' for a new Agent (port 443) SSL configuration. Make a note of the keystoreFile path specified for the connector as this is the file you will be replacing.

Make a backup of the keystoreFile(s) before proceeding

Record the value for storePass and keystorePass values. They will be an alphanumeric string of 40 characters and possibly the same value. Also make a note of the storetype

4.  Edit the keystoreFile path(s) and change the keystoreFile name to a new keystore file ".ssl" extension. For a new Console (port 4443) certificate or a new Agent (port 443) certificate, you would want to name your new keystore accordingly

If you choose to update the Agent certificate, all agent certificates on all agents connecting to this management server must also be updated. You must consider this carefully before proceeding, as going forward with Agent connection changes may prevent all communications with existing or configured agents until each is updated accordingly.

5.  Save your edits to the server.xml file

6.  Update command line session file path to include JRE and tools directory:

Add %programfiles%\Symantect\Data Center Security Server\Server\jre to the front of your environment PATH variable.
Also add %programfiles%\Symantec\Data Center Security Server\tools to the front of your environment PATH variable (this will only be a temporary change and you may need to close and restart command line sessions for your PATH variable update to take effect).
Open a command line session and test that both the keytool.exe and openssl.exe commands are available in your session's PATH.

7.  Download and copy the openssl.exe to the following location:

%programfiles%\Symantec\Data Center Security Server\Server\tools\

To generate new 2048-bit RSA keys for console and/or agent communications

1.  If you are reusing an existing keystore that was used for either the Agent (port 443) or Console (port 4443) connector, you must first delete the existing key in the keystore by referencing its alias:

keytool.exe -delete -keystore [keystoreFile path] -alias sss -storepass [40 character alpha-numeric string found in server.xml] -storetype PKCS12

2. Ensure that the Common Name (CN) should be the Hostname of the server if that hostname is DNS resolvable. Otherwise, you must use the servers IP address

3. Record the hostname of the management server, this will be used to fill in the OU parameter

4.  Using the command line, enter the following:

keytool.exe -genkey -keystore [keystoreFile path] -alias sss -validity 5000 - keyalg RSA -sigalg SHA256withRSA -keysize 2048 -storetype PKCS12 
- storepass [40 character alpha-numeric string found in server.xml] - keypass [40 character alpha-numeric string found in server.xml] - dname "CN=[Management server hostname or IP address]"
- ext "SAN=DNS:[Management server hostname],IP:[Management server IP address]"

For both the " - dname" and " - ext" parameters, the string [management server hostname] should be replaced with a fully qualified domain name (FQDN). The FQDN should appear similar to as it appears when specified from a client program. If using the management server hostname (as opposed to a static IP address), please verify that the hostname is DNS-routable from the client program's server. Also, if you are planning to use the key you are generating for CA-provided (for example, Verisign) certificates, you must also provide the - dname parameter with valid "C" country and "S" state values. Verisign or other CA-providers may have additional key generation requirements. Lastly, your keytool command should include the "-ext" parameter to allow compliance with RFC 6125, using the Subject Alternative Name (SAN) record (as in: -ext "SAN=DNS:www.purple.com"). For the "-ext" parameter, you can use a DNS or a static IP address, but not both.

5.  Using the command line, enter the following:

keytool.exe -export -v -keystore [keystoreFile path] -alias sss -rfc -file exported-cert.crt -storepass [40 character alpha-numeric string found in server.xml] - storetype PKCS12

6  Using the command line, enter the following from [DCS install path]\server\tools:

openssl x509 -out exported-cert.der -outform DER -in exported-cert.crt

When running this command, a WARNING message may be generated, you can ignore this message.

7.  Using the command line, enter the following:

openssl x509 -in exported-cert.der -inform DER -text -out exported-cert.pem -outform PEM

When running this command, a WARNING message may be generated. You can ignore this message

8.  For agent updates, rename exported-cert.pem to agent-cert.ssl

Replacing Existing Certificates with new 2048-bit Certificates for Data Center Security: Server

1.  Stop the Symantec Data Center Security Server Manager service

2.  Restart the Symantec Data Center Security Server Manager service

3.  Replace the original agent-cert.ssl with the renamed agent-cert.ssl created by openssl. The agent-cert.ssl is located at:

%programfiles%\Symantec\Data Center Security Server\Server

4.  Restart the SCSP management service

Assuming server.xml is not changed, and the new keystore, cert and keystore passwords match what's already in the server.xml, then the new certificate will automatically be used with the console and you should be asked at next console login to accept the new certificate. If not asked, then remove the siscerts file from the console's certificate store:

[INSTALLDIR]\Console\certs\siscerts which is usually:%programfiles%\Symantec\Data Center Security Server\Console\certs\siscerts

5.  Open Unified Management Console and accept the new certificate that you generated.

Replacing Existing Certificates with new 2048-bit Certificates for Agent on Primary Data Center Security: Server

1.  Copy the newly created agent-cert.ssl to:

%programfiles%\Symantec\Data Center Security Server\Server

2.  Update Agent to use new agent-cert.ssl with this command (forces use of new agent-cert.ssl file):

sisipsconfig -c agent-cert.ssl

3.  Test connection from command prompt:

sisipsconfig - t 

sisipsconfig works as follows: 

On Windows systems, sisipsconfig works from: %programfiles%\Symantec\Data Center Security Server\agent, and on UNIX systems, sisipsconfig works from: /opt/Symantec/scspagent/ips

Additional Information

For RHEL 7.3 and lower, please ensure openssl is updated to version 1.0.2k (or higher) with the following command:
yum update openssl
Ref: https://access.redhat.com/articles/1462343