Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

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

Created: 07 Mar 2013 • Updated: 25 Mar 2013 | 7 comments
Language Translations
SMLatCST's picture
+13 13 Votes
Login to vote

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.

Comments 7 CommentsJump to latest comment

Mithun Sanghavi's picture

+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.

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

0
Login to vote
Chetan Savade's picture

Nice Article !!

Chetan Savade
Sr.Technical Support Engineer, Endpoint Security
Enterprise Technical Support
CCNA | CCNP | MCSE | SCTS |

Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.<

0
Login to vote
SUPPORT-2-SUPPORT's picture

Thumbs Up for nice article.

Regards,

S2S

Please don't forget to mark your thread solved with whatever answer helped you.

-1
Login to vote
Stan3's picture
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
0
Login to vote
Ambesh_444's picture

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

Thank& Regards,

Ambesh

"Your satisfaction is very important to us. If you find above information helpful or it has resolved your issue. Please don't forget to mark the thread as solved."

-1
Login to vote