Endpoint Protection

 View Only

SEP12.1: Creating and using a 3rd Party CA signed Cert for Client Communications 

Mar 07, 2013 09:30 AM

Disclaimer:  Follow these steps at your own risk.  This lot worked for me, I can't guarantee the same for you (or even that it won't break your SEPM), but hopefully it will help someone out smiley

 

Background: What is on offer by default

SEP12.1 includes, by default, a self-sgned certificate for use with client communications.  This is enough for most circumstances and customer, as using it will encrypt the client communications correctly.  The below article describes how to use this inbuilt self-signed cert:

http://www.symantec.com/docs/TECH162326

However, some customers mandate the use of certificates signed by 3rd party CAs.  In this case, follow the below steps to create and use such a certificate.

These steps assume you have already followed the parts of the article to enable sslForClients.conf and have a MSL ready to tell clients to communicate over HTTPS (which will be able to use the "Verify Certificate..." option after the certificate swap is complete).

Step 1: Creating a Certificate Signing Request

In order to create a signed cerrt, we first need the CSR to submit to the 3rd party CA.

This is done by opening a command prompt and navigating to the directory: "%\ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\bin" and entering the command below:

openssl req -config ..\conf\ssl\openssl.cnf -new -out newcertificate.csr -key ..\conf\ssl\server.key

On running this command, you will be prompted for the usual certificate details (Common Name, Organisation Name, blah, blah blah wink)

This results in a CSR file called "newcertificate.csr" in the "%ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\bin" directory.  This command uses SEP's inbuilt private key for the generation of this request.

Step 2: 3rd Party CA Signing

Hand this "newcertificate.csr" to your 3rd Party CA, who should come back to you with a signed certificate.  The resultant certificate file should end with the ".crt" file extension.

Step 3: Making SEPM use the new certificate

This is generally quite easy and is just the renaming of a couple of files.  Copy the brand new certificate into the "%ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\conf\ssl" directory.  Locate the old self-signed certificate server.crt and rename it to "server.crt.backup" (or whatever you like) and rename the new certificate to "server.crt".

Restart the SEPM Webserver Service (and by extension the SEPM service too) and you're away!

Notes:

Step 1 - While it is possible to create a new private key as well during this stage, I found it easier to use the existing one because it does not require a password, and I've not found an easy way to supply a password for starting Apache/OpenSSL/SEPM WebServer Service (the builtin method is meant to prompt, but doesn't in my testing).

Step 2 - If you have an internal CA, I'd recommend testing out the CSR so you know everything is entered correctly.

Step 3 - The reason we are renaming the certificate files is because the client comms aren't the only parts using the cert.  Access to the Reporting component of the SEPM (https://<SEPM>:8445/reporting/index.php) is also protected with this certificate, so it's easier all round to change a couple of file names than messing with the .conf files.  If you'd prefer to change entries within the .conf files, then you need to look for the below files:

  • ssl.conf (used to manage the Reporting part of the SEPM)
  • sslforclients.conf (used for the client communications)

And find the below entries within these files:

  • SSLCertificateFile "conf/ssl/server.crt"
  • SSLCertificateKeyFile conf/ssl/server.key

And change these to use the new certificate file(s); or even just update one of the .conf files to use the new certificate if you want.

Rolling back - If you encounter any issues, it's just a matter of changing the file names or (file changes) back around to use the original self-signed cert.

 

Addendum: Using an Existing Certificate

Some of you may already have a trusted and signed 3rd party certificate that you want to reuse for SEP.  If so, you can use the below steps to split a .pfx file into the two files required by the SEPM (.crt and .key).  Obviously, if using an existing cert, it's up to you to make sure the address in the MSL matches the name on the cert.

Step 1: Generating the Certificate files

First up, open a command prompt and navigate to the directory: "%\ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\bin", then enter the two separate commands below:

 

openssl pkcs12 -in <path>\sourcecert.pfx -nokeys -clcerts -out <path>\output.crt
openssl pkcs12 -in <path>\sourcecert.pfx -nocerts -nodes  -out <path>\output.key

 

Just replace <path> with the directory where your .pfx file resides and where you want the new files to be saved.

On hitting <ENTER> after each command, you should be asked to provide the password protecting the .pfx file.

Step 2: Making SEPM use the new certificate and key

Now that we have the certificate files in the correct format, we just need to get the SEPM to use them.  This step is very similar to "Step 3: Making SEPM use the new certificate" above, but as we have a new private key (the output.key file) we have to changes the filenames of both files involved.

Copy the output.crt and output.key certificate files into the "%ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\conf\ssl" directory.  Locate the old self-signed certificate server.crt and rename it to "server.crt.backup" (or whatever you like) and rename output.crt to "server.crt", then do the same to server.key (i.e. rename to server.key.backup and rename output.key to server.key).

Restart the SEPM WebServer Service to get it to take effect.

Statistics
0 Favorited
23 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Oct 11, 2019 04:15 PM

Hi everyone,

If I have multiple SEPM servers with a common DB, do I need to do these steps on each server?

Thanks.

 

Jan 31, 2019 11:16 AM

Yup understood

 

It just weird why Symantec & Symantec Support doesn't officially support this method....does it bring any harm to sepm in any way?

 

Hope somebody from their end who is active here can bring more insight on this decision....

 

 

Jan 30, 2019 11:55 AM

Hi,

Worth mentioning if You switching to global CA cert and You have Linux servers in Your environment consider adding SSLCertificateChainFile in apache config. Please take a look in this thread https://www.symantec.com/connect/forums/some-clients-lose-connection-after-upgrade-142 and this https://support.symantec.com/en_US/article.TECH251024.html 

Jan 29, 2019 04:39 AM

No, the steps that I listed above are working fine, as mentioned I have done them on several SEPMs and there is no issue. You are generating the new CSR, sending it to the CA so I don't see issues with that

 

Jan 29, 2019 01:30 AM

Stumped with support, it seems that CSR request is not supported on SEPM

 

CSR generation is not supported on SEPM this is confirmed in the article and has been confirmed with the next level internally. The steps to update a certificate is available in the article mentioned below.
 
 
 
Very stange
 
 
Certificate Authority Signing
 
When replacing the built in self-signed certificate on your manager with a Certificate Authority (CA) signed certificate, work with your Certificate Authority (CA) to generate a new, CA signed certificate with your organization's information instead of exporting a Certificate Signing Request (CSR) from the default self-signed certificate. Be sure you are aware of any organizational or compliancy requirements governing the use of certificates in your environment before generating a CA signed certificate. Some common questions you should be able to answer before generating your certificate(s) are:
 
Are there any specific requirements regarding private key length?
Are there any specific requirements regarding signature algorithms?
Are there any specific requirements regarding signature key algorithms?
Can the Common Name (CN) field contain wildcards (*)?
Can certificates contain IP addresses in the CN field, or as Subject Alternative Name (SAN) entries?
Can certificates be signed by intermediary Certificate Authorities (CAs)?
Are certificates required to be cross-signed?
 

Jan 24, 2019 01:54 AM

Yes, I did it on both, SEP 12 and SEP 14

Jan 23, 2019 09:32 PM

Thanks @S_K !

 

Looks good will test this later, but only want to re-confirm:

 

Does this steps valid for both 12.x and 14.x ?

Jan 18, 2019 02:05 AM

Hi ins007,

Here are the commands that I used on few SEPMs where I have replaced the certificate and its working fine.

Before you update the SEPM certificate, make sure you follow the steps from this article:

      https://support.symantec.com/en_US/article.HOWTO81061.html#v57845489

 

1) Generate a new Private key

a) Open Command prompt as Administrator and browse to (or the location where your SEPM is installed):

 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jre\bin

​​​​​​​b) Run the following command:

keytool.exe -genkey -alias tomcat -keyalg RSA -keystore newkeystore.jks

instead of newkeystore.jks you can just name it keystore.jks

newkeystore.jks will be saved in D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jre\bin

c) fill the necessary information

- put a password for the private key

- for First/Last name I put the FQDN of the SEPM server

- for Organizational usint I put Symantec Endpoint Protection

- then name of your company

- the city where the SEPM server is located

- for Province you can put whatever

- Two letter country code - for example for Germany put DE

- then for Enter keypassword for tomkat I just pressed Enter

 

newkeystore.jks will be saved in D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jre\bin

 

2) Next step is to generate the CSR (Certificate Signing Request) which has to be sent to the Certificate Authority so they can sign and return to you

keytool.exe -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore "D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jre\bin\newkeystore.jks"

 The CSR file will be placed in the same folder as the keytool.exe and in the example below it is called certreq.csr

 

3) Your CA will return you “.cer” file, let’s say in our example it is called cerJKS.cer

You can review the signed certificate with the keytool utility before you import it into the keystore

keytool.exe -printcert -v -file cerJKS.crt

 

4) Before you can import the signed certificate, please ensure that the public root certificate from your CA (Certificate Authority) is imported into the keystore as well (using file name "ca.crt" for this example). You will be prompted for the keystore password.

keytool.exe -importcert -v -noprompt -trustcacerts -alias cacert -file ca.crt -keystore newkeystore.jks

You may need to repeat this step if you'd like to import multiple intermediate, cross and root certificates. Please note that you need to specify a unique alias with the import of each certificate.

keytool.exe -importcert -v -noprompt -trustcacerts -alias intermediate -file intermediate.crt -keystore newkeystore.jks

 

5) At this point you can import the signed certificate, so it associates them together. You will be prompted for the keystore password.

The alias here must match the alias of the private key in the first command.

keytool.exe -importcert -v -alias tomcat -file cerJKS.crt -keystore newkeystore.jks

The keystore is now complete and can be used for signing code or deploying on a Java based web server depending on the product you ordered

 

6) Now you can import the new certificate in the SEPM console

Go to Admin tab -> Servers -> select the SEPM server and then below select "Manage Server Certificate". Click Next and then "Update the server certificate". It will ask you if you have performed the steps from the article on the top that I mentioned and then you can continue. After that select the type of certificate that you want to import to be JKS. Browse to the new file and put the password that you set at the beginning.

And just in case restart all SEPM services after you finish with this.

But I would advise you first to test this if you have a test environment, for me it worked

Jan 17, 2019 12:43 AM

Thanks @S_K

 

A TSE actually provided below, anyone know what's the CLI command for SEPM keytool?

 

You may install Microsoft Certificate Services on a test computer and test these steps. An experienced administrator may opt to use keytool.exe (command line based utility) instead. A copy of keytool is available on the SEPM in "C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jre\bin".

More information about keytool.exe can be found on the Oracle Web site:
https://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html

The included steps use an open source tool called Keystore Explorer, available via http://keystore-explorer.org/. This tool requires the Java JRE to be installed on the computer used to create a new Java keystore (JKS).

WARNING: Before you proceed with replacing the certificate, please be prepared to either distribute NEW sylink.XML files to all SEP clients when done, OR follow the steps in the following documents before you proceed with the following steps.

Update the server certificate on the management server without breaking communications with the client

 

https://support.symantec.com/en_US/article.HOWTO81059.html

 

 

 

 

Jan 15, 2019 04:04 AM

The certificate is the same for the client-server communication and also the Web console.

Here is also mentioned where the certificate is used: 

https://support.symantec.com/en_US/article.TECH210852.html

Regards

 

Jan 14, 2019 06:17 AM

Thanks for the update.

 

Does the steps in KB cover certificate for SEPM Web console as well?

 

I can see a lot of reference mentioning about SEPM <---> Clients communication, but what if we only cover SEPM Web Console cert only?

 

 

Regards

Jul 23, 2018 07:26 PM

Do not follow these steps. They leave you with a partially functional SEP as the process doesn't do anything to update the SEPM Tomcat server, or the SEPM database, both of which need to be updated. The SEPM's built in Manage Server Certificate Wizard has properly and completely updated a serer certificate since the 12.1 product released in 2012. Use public KB https://www.symantec.com/docs/HOWTO81146 instead.

Apr 21, 2016 07:20 AM

When i run openssl req -config ..\conf\ssl\openssl.cnf -new -out newcertificate.csr -key ..\conf\ssl\server.key i get a message that says: WARNING: can't open config file: /usr/local/ssl/openssl.cnf

and even though it lets me capture all the info required, when I upload the CSR to Symantec SSL site it says it requires a key length of 2048 minimum, how do I changed the key length ?

 

Jan 14, 2016 10:15 AM

Can I use certificate with DSA algorithm. (with public key DSA 2048 Bits) ?

Thanks.

Jul 07, 2013 11:59 PM

Nice artrocle bro..best of luck for next...

Jul 07, 2013 11:30 PM

Now I can access "https://<SEPM>:8445/reporting/index.php" with my cert, 
 
But when i access Symantec Endpoint Protection Manager Web Console (https://<SEPM>:8443/console/apps/sepm), it still stick with own self-sign cert.
 
Anyway to change it?
 
Thanks

Mar 26, 2013 01:08 AM

Thumbs Up for nice article.

Mar 23, 2013 07:14 AM

Nice Article !!

Mar 21, 2013 11:58 AM

Thumbs up Dude.

Regards

Ajin

Mar 21, 2013 07:53 AM

+1. Good one. Awesome.

However, I would recommend all to first TEST this steps on a Test environment and later apply on Production Environment upon successful testing.

 

Mar 21, 2013 07:13 AM

Thumbs up! 

Related Entries and Links

No Related Resource entered.