Background: What is on offer by default SEP12.1 includes, by default, a self-signed 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 )
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.
As the UK’s only provider that is endorsed by Symantec as “Master Partner” for Enterprise security solutions, we are able to offer an array of services that range from health checks to design, along with complete managed services for SEP. Call us for more information.
I’d also be keen to hear if you have suggestions for us to create another tech-tip - what do you think needs a greater explanation? | 
