Creating an SSL certificate to secure SEE Client Communication with the Symantec Endpoint Encryption Management Server (SEE)

search cancel

Creating an SSL certificate to secure SEE Client Communication with the Symantec Endpoint Encryption Management Server (SEE)

book

Article ID: 178609

calendar_today

Updated On:

Products

Endpoint Encryption Drive Encryption Encryption Management Server File Share Encryption Gateway Email Encryption PGP Command Line PGP Key Management Server PGP Key Mgmt Client Access and CLI API PGP SDK Desktop Email Encryption

Issue/Introduction

How to create an SSL certificate to be used to secure SEE Client Communication with the Symantec Endpoint Encryption Management Server

TIP: For information on how to Troubleshoot SEE Client Creation and SEE Client communication, see the following article:

155127 - Symantec Endpoint Encryption Client communication and SEE Client Creation troubleshooting steps

Resolution

Symantec recommends using the HTTPS protocol to secure communications between the Symantec Endpoint Encryption Management Server and deployed SEE clients. In order to secure these communications an SSL Certificate is needed.

Section 1: Creating and Completing the CSR with OpenSSL
Section 2: Troubleshooting

This article covers the basic process for creating an SSL Certificate suitable for use with Symantec Endpoint Encryption (SEE) version 11.x

NOTE: The same process can be used with previous versions of SEE as well. The user interfaces and exact steps may differ slightly depending on the OS hosting the SEE Management Server, but the general steps are the same.

Skip to the bottom of this article for Troubleshooting

The protocol used for communication can be configured using the SEEMS Configuration Manager. The Web Server Configuration page will allow you to choose from HTTP or HTTPS. If HTTPS is chosen a CA Certificate and a Server Certificate will need to be configured. This article will include instructions for creating the files needed for this configuration.

When the SEE client is built from the SEE Management Server, the Root\Signing certificate is embedded in the client. Because of this, it is very important to choose the proper certificate strategy as this is the certificate that will be used to communicate with the SEE Management Server. When the Signing certificate or Server certificate expires, the SEE client will stop communicating, so it is important to ensure these certificates are replaced prior to expiration. If the Root\Signing certificate is going to expire, either a new SEE Client should be re-deployed after the new certificates are assigned to the management server, or the "Server commands" are used prior to the certificates expiring.

This article will go over two sections, one for OpenSSL and the second for CSR via IIS.

Section 1: Creating and Completing the CSR with OpenSSL

If you would like to use OpenSSL to create the CSR process, run the following command:

openssl req -newkey rsa:2048 -keyout New-Server-Keypair.key -out CSR-to-give-to-CA.crt

This will prompt you for all the applicable fields for the certificate, including a passphrase. Be sure to remember the passphrase and to keep it secure for later.

The New-Server-Keypair.key contains the private key. Do **not** provide this to your Certificate Authority.

The CSR-to-give-to-CA.crt file is only a public portion of the cert and this **is** what you provide to your Certificate Authority. They will provide a fully signed certificate back in .cer format, which will include the CA signed portion along with the full chain.

In order to then bundle the signed CSR to your private key, run the following openssl command:



openssl pkcs12 -export -in signed-CSR-from-CA.crt -inkey New-Server-Keypair.key -out certificate.pfx

The signed-CSR-from-CA.crt file is what you received back from the CA and is the signed request.

The New-Server-Keypair.key file is the keypair you generated from the previous steps.

The certificate.pfx will be the result of combining the signed .crt file and the .key file into a bundled certificate that can then be used.

Once you have the .pfx file, you can then take this to your SEE Management Server, import to the certificate store. Next, export the public portion of this newly-signed certificate and you can then assign to the SEE Management Server.

TIP: Read through the rest of this document for other general best practices.

Section 2: Using IIS to Generate a CSR

1. Decide which kind of Certificate Authority (CA) will sign your certificate

Certificate Authorities such as Digicert.
Internal Microsoft Certificate Authority.

Having a Trusted Certificate Authority is the best option to use as these are all internally trusted automatically. Having an Internal Microsoft Certificate Authority also works well as long as the signing certificate is trusted on an enterprise level by machines joined to the domain.

WARNING: Using Self-Signed certificates is highly discouraged due to the loss of communication that occurs when the certificate expires and no option to renew. It is handy to use a self-signed certificate for testing purposes only, but once you move to production, ensure the self-signed certificate is not used. When the certificate expires, the SEE clients will no longer communicate with the SEE Management Server.

2. Open the Server Certificates section in Internet Information Services (IIS) on the server hosting the Symantec Endpoint Encryption Management Server

After opening IIS, select your server in the left pane, and double-click Server Certificates in the center pane

3. Skip to the appropriate section depending on which type of Certificate Authority was chosen

Skip to step 3A if a Third Party CA or an Internal Microsoft Stand-alone Certificate authority was chosen
Skip to step 3B if using an Internal Microsoft Enterprise Certificate Authority (tied into Active Directory)
Skip to step 3C if using a self-signed certificate

3A. If using a Third party Certificate Authority or an Internal Microsoft Stand-alone Certificate Authority:

Select "Create Certificate Request" in the right pane
Complete the Distinguished Name Properties form
1. Ensure that the "Common name" matches either the NetBIOS name, the FQDN, or DNS alias that is used for the SEE Management Server
Complete the rest of the certificate request wizard and choose a location to store the Certificate Signing Request
Send the Certificate Signing Request (CSR) to your Certificate Authority of choice using a method that is determined by the CA
Once the Certificate Authority has returned the signed certificate request, you must then complete the request within IIS
1. From the Server Certificates Section of IIS, select "Complete Certificate Request"
2. In the wizard, browse to the .cer file that was returned by the Certificate Authority
3. Give the Certificate a friendly name
4. Ensure that the certificate is being stored in the Personal store
The Server Certificates section of IIS will now list your new certificate

Proceed to step 4

3B. If using an Internal Microsoft Enterprise level Certificate Authority

Some environments have an Enterprise level Certificate Authority that is tied into Active Directory
The Enterprise CA will need to be properly configured to allow a certificate to be created.
NOTE: Symantec does not assist with the configuration of a Certificate Authority

Select "Create Domain Certificate" in the right pane
Complete the Distinguished Name Properties form
1. Ensure that the "Common name" matches either the NetBIOS name, the FQDN, or DNS alias that is used for the SEE Management Server
Complete the rest of the certificate request wizard and select an online Certificate Authority to approve your certificate
The Server Certificates section of IIS will now list your new certificate

Proceed to step 4

3C. If using a Self-Signed Certificate

Select "Create Self-Signed Certificate" in the right pane
Choose a friendly name for the certificate
Note: The FQDN will automatically be assigned as the Common Name
Ensure that the certificate is being stored in the Personal store
The Server Certificates section of IIS will now list your new certificate

Proceed to step 4

4. Export the new certificate for use in the SEEMS Configuration Manager

From within the Server Certificates section of IIS, Double-click on the newly created certificate, this will open the Certificate properties window
Click the Details tab
On the Certificate Details tab, Click "Copy to File."
This will open the Certificate Export Wizard, Click Next on the intro screen
Choose "No, do not export the private key" and Click Next
Choose "DER encoded binary x.509 (.CER)" and click Next
Click Browse, choose a path and name for the Certificate file, Click Save, then Click Next
Click Finish

5. Configure the Web Server in the SEEMS Configuration Manager
NOTE: Depending on which version you are using, the User Interface may appear different, but the steps will remain the same

Open the SEEMS Configuration Manager. If this is an initial install, the Configuration Manager should open automatically after installing the Management Server.
Click on the Web Server configuration tab
Ensure that the Web Server Name in the SEEMS Configuration Manager matches the "Issued To" field of the new certificate
- The "Issued To" field should have been set to either the NetBIOS name, FQDN, or DNS alias for the Management Server in Step 3 above
- By Default, the Web Server Name field in the SEEMS Configuration Manager will have the NetBIOS name filled in
- Edit the Web Server name field as needed, failure to do so will cause issues when generating client packages
Choose the HTTPS Protocol, and enter available port numbers for both TCP Port and SSL Port
- Port numbers should not be used by any other applications
- Ports will need to be opened in the Windows firewall if enabled
Click Browse next to "CA Certificate." Browse to the .cer file that was created in Step 4 and select it
-The certificate hash will appear

Important Note: The screenshot above shows "CA certificate" and "Server certificate". These two certificates are different certificates and have different purposes.
CA certificate: This is the "Root" or Signing certificate for the Server Certificate. This could potentially be an intermediate certificate or even an Internal Root certificate. The CA certificate is the actual certificate that is included in the SEE client upon client creation.
It is important that this CA certificate not expire, as it will cause the client to stop communicating with the SEE Management Server.
Server certificate: This is the certificate that is associated to the hostname of the actual SEE Management Server. When the TLS session is established, part of the verification will be for the server cert. Make sure the Keypair resides on the SEE management server that are communicating with the SEE clients.
If this certificate expires, while not recommended to allow this certificate to expire, it is possible to still communicate with the SEE Management server. Fix this certificate as soon as possible.
Self-signed certificates should never be used for Symantec Endpoint Encryption for TLS communications. This is because both the CA certificate and the Server certificate are the same. If this expires, this means the clients will no longer be able to communicate with the server and re-building and redeploying a new SEE Client *will* be necessary.
Click Browse next to "Server Certificate"
-This will open a window with a list of Certificates that are in the Personal Certificate Store on the machine
-Select the newly created certificate from the list, Click OK
-The certificate hash will appear
Verify there are no Red Exclamation marks indicating an issue with the information provided, Click Save

NOTE: If using a Self-Signed Certificate, the hash for the CA Certificate and the Server Certificate should match.
WARNING: Self-Signed Certificates are highly discouraged. Due to the nature of self-signed certificates, when the certificate expires, the clients will stop communicating with the Management Server and the client will need to be re-deployed with a new certificate. When a CA Certificate is used, and the server certificate expires, you can renew the server certificate and leave the Root and clients will continue to communicate to the SEEMS. Using an internal CA is completely acceptable. Avoid using self-signed certificates, and if this is absolutely necessary, ensure the expiration date is for many years to minimize communication issues.

TIP: When using a trusted certificate authority such as Digicert when attempting to browse to the "CA certificate", or signing certificate, it may be possible to browse to the CA-signed server cert instead of directly to the root/intermediate, and the configuration manager will automatically resolve which certificate should be assigned here. If attempting to assign the Root/Intermediate cert directly produces an error, try to browse to the server cert instead.

6. Create and Deploy Client software

You have now configured SSL Communication between the Symantec Endpoint Encryption Management Server and it's Managed Clients
When creating the Management Agent Client installer, the SSL information will be included
NOTE: If existing clients have been deployed while SSL communication was NOT enabled, you will need to redeploy the Management Agent Client to those machines to include the certificate information.

Load Balancers and TLS Termination

Normally when the Server certificate assigned to the SEE Management Server expires, the SEE Clients will stop communicating, this is why it is important to renew the server certificate so the SEE Clients will continue to check in. The exception to this is when Load Balancers are used performing TLS Termination. The following can be configured in order to allow clients to communicate even when a new Root\Signing certificate or Server certificate has expired:

TLS termination happening at the Load Balancer.
No passthrough happening on the Load Balancer.
Load Balancer can have a completely different certificate to handle TLS communication performing re-negotiation\re-encryption to the SEE Management Server.
The SEE client has a completely different cert than the Load Balancer and SEE Management Server currently assigned.

When the above applies, even if the signing server certificate, or server certificate has been replaced, communication should continue to happen. If the Root\Signing certificate on the client expires, the client should be re-deployed.

To check which the thumbprint configured on a current SEE install, check the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Encryption Anywhere\Framework\Client Database\CommunicationCertificateID

The above can be compared with the CA certificate on the SEE Management Server.

^Back to Top

Section 2: Troubleshooting

Scenario 1 of 3: Connection issue with TLS Certificate Binding

Once a certificate has been assigned, if there are errors such as the following, check to ensure the binding is correct within IIS for the certificate being assigned.

"ERR_CONNECTION_RESET"

"Turn on TLS 1.0, 1.1, and TLS 1.2"

Caveat: for this example, we will be using a self-signed certificate. This is HIGHLY discouraged, and is provided only as an example, when using certificates, use only certificates signed by Internal Certificate Authorities, or Trusted Certificate Authorities, such as Digicert.

It is always a good idea to make note of the Thumbprint of the certificate in question so that you know you are working with the correct certificates. When there is a Root certificate, make note of its Thumbprint, if there is an Intermediate Certificate, make note of that so it is very clear as to which certificates you will be using to assign. In this case, the Thumbprint is "9b 83...df b8" for both the CA certificate and Server certificate:

Next, when you assign the certificates to the SEEMS Configuration Manager, you will browse to the Root certificate and the Server certificate. When you do this, the Thumbprint will also be populated. Ensure these match. Because we are using the same certificate for both CA certificate an Server certificate, the same Thumbprint is listed here:

Now that you have determined you are working with the correct certificates, open up IIS and click on the top-level domain, then on the right side, open up "Server Certificates" and you will be able to view the certificates you are working with. If the certificates you need to use are not listed here, you can import them to the list:

Notice the Certificate Hash above, and that it is the same as the Thumbprint of the certificate we are working with.

Next, in IIS click the Symantec Endpoint Encryption Services website, and to the right you will see the "Bindings...". Open this to view the bindings, there should be a binding for https. You will then see the "https" binding. Click that and click edit to view the certificate assigned to the port:

If you click the dropdown next to the SSL certificate field, you will see available certificates you can assign. Select the cert you believe to be correct, and then click "View..." to again confirm the Thumbprint. If this matches, this should be all that is needed to ensure the certificates are assigned. Again, in this example, we used a self-signed certificate for simplicity, however, in a real-world scenario, use certificates only signed by Internal CAs that are trusted domain wide, or certificates signed by a trusted Certificate Authority such as Digicert.

It's a good idea to restart the IIS services via the command line in order to ensure the configuration will take effect immediately by running the following via admin prompt:

iisreset

When the SEE Client is created, the Root certificate is embedded into the client for client-server communications. The final step to ensure the systems deployed to the organization will trust the root certificate that was embedded into the client is to validate the Root certificate assigned to the "CA certificate" field is same as what is included in the client. Check the Trusted Certificates of some sample machines to ensure the root is also included.

Make sure the hostname assigned to the server certificate matches that of the hostname the SEE client will communicate back with.

On the client machine where SEE is installed, check the Thumbprint for the Root certificate and ensure it is the same. This can be done by looking in the following location in the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Encryption Anywhere\Framework\Client Database\CommunicationCertificateID

Scenario 2 of 3: Dual Root Certificate for each SEE Management Server
If you have two management servers, it is possible to have a separate root certificate on each of the servers. Although this is not recommended, it is possible, but there was an issue where the proper cert was not getting built in to the client properly.
This issue has been resolved in the SEE Client 12.0.1.
EPG-35505

Scenario 3 of 3: TLS 1.0/1.1 VS TLS 1.2
If you are running SEE 11.3.1 or above, it's a good idea to disable HTTPS for your SEE Cients. All SEE Clients will now use TLS 1.2 going forward.
The Root Certificate must be considered when doing this to ensure proper communication going forward.

^Back to Top