If you run Trend Micro business products you should really consider running a Smart Protection Server (SPS) appliance in your datacenter. In a previous post I stepped through the process of deploying an SPS appliance in a VMware environment. It is possible to deploy to Hyper-V as well so don’t worry if you aren’t running ESXi. For reference here is the link to my deployment guide –
Once deployed the appliance will generate a self-signed SSL/TLS certificate for the web management interface. Personally I believe that all certificates should be issued from a trusted certificate authority (CA) so you will often find me working out how to get into an appliance to replace whatever it created. Some of them are easy and have an actual menu/wizard to let you do this while others make life difficult. Thankfully the Trend SPS replacement isn’t difficult so with that being said let us move on to the process of replacing the SSL/TLS certificate used for the web management interface on Trend SPS appliances.
Before we start let’s take a look at the web interface after a default installation –
As you can see the SPS appliance creates a self-signed certificate which will generate alerts for any browser connection. Time to change that!
The first we we need to do is enable secure shell (SSH) on the appliance – by default it is disabled which is fine for normal use (and minimising attack surface).
With the virtual machine console open logon using the admin credentials setup when deploying the appliance.
Next we will run the enable command to enter the privileged administrative command mode (similar to a Cisco switch). We can then run the enable ssh command to turn on secure shell. If it is the first time the secure shell daemon has been activated the system will generate a new set of keys as indicated in the screenshot below.
Now that we have SSH access we can move on to creating our replacement certificate and private key and uploading to the appliance.
Create Certificate Signing Request (CSR)
Here is an example template, there are a couple of things which aren’t really required for this deployment but I use the same template for various systems so it’s just easier for me to stick to one that covers all bases. Obviously you need to replace the data within the [alt_names] and [req_distinguished_name] sections with your own values. Take note that I have added a number of subject alternate name (SAN) attributes. No doubt some will argue against the use of an IP address in the certificate and I fully understand those arguments, we have an internal reason for doing this but feel free to make up your own mind or ask in the comments below. Do make sure any certificate issued has (when using RSA) a minimum key size of 2048 bits and a minimum hash of SHA256.
[ CA_default ] default_md = sha256 [ req ] default_bits = 2048 default_keyfile = rui.key distinguished_name = req_distinguished_name encrypt_key = no prompt = no string_mask = nombstr req_extensions = v3_req [ v3_req ] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = BSA-TSPS01 DNS.2 = BSA-TSPS01.ad.bytesizedalex.com DNS.3 = 172.16.1.34 IP.1 = 172.16.1.34 [ req_distinguished_name ] countryName = GB stateOrProvinceName = Lancashire localityName = Preston 0.organizationName = ByteSizedAlex Corporation organizationalUnitName = IT Services commonName = BSA-TSPS01.ad.bytesizedalex.com emailAddress = [email protected]
It is also necessary to create a private key to combine with the template as part of our certificate signing request (CSR). This can be done with OpenSSL. An example is shown below –
openssl.exe genrsa 2048 > spsprivate.key
Finally we combine the configuration file and private key to create our CSR. When doing this you will need to ensure you provide the full path to the files if they are not in the same directory. As an example I will call the files from C:\Temp.
The command requires a number of properties be defined. To start we call openssl.exe and inform it we are creating a new CSR and provide a path for that CSR file to be written to. Next we need to provide the path for the private key and finally we give the location of the configuration file we wrote.
openssl.exe req -out C:\Temp\request.csr -key C:\Temp\spsprivate.key -new -config C:\Temp\certificate.cfg
Submit CSR To Certificate Authority (CA)
At this point you should have a CSR file ready to submit to your Certificate Authority (CA). In my case I am submitting the CSR to a Microsoft CA, this step varies for everyone so I’m assuming you have the relevant knowledge to complete a CSR submission. If not put a comment below and I will attempt to help. In my example I define the certificate template on the CA I wish to use. The configuration file we created does not include this information so it is necessary to declare it. My certificate template is named BSA-WebServer-RSA, replace this with your own.
certreq -attrib "CertificateTemplate:BSA-WebServer-RSA"
We now have the necessary files to drop on the SPS appliance so it’s time to copy these onto the box. In my case the certificate file we just created, the config file, request file and finally the private key.
Format Certificate PEM File
Now that we have our signed certificate we need to complete one last task to get it ready for the appliance. It is necessary to create a single PEM file. If you want more information on this process then DigiCert provide a good article – https://www.digicert.com/ssl-support/pem-ssl-creation.htm
Essentially a PEM file in this case contains the private key, server certificate and the chain of intermediate (if any) servers up to the root certificate authority. Again as with other parts of the process this depends on your environment. In my case there is a single CA which issued the certificate so my PEM file will have this structure –
[ROOT CA CERTIFICATE]
It is important that you save the final file with a name of server.pem. I have provided an example screenshot below, note that I have stripped a lot of the text out to get it into one screen. It is also important to ensure there are no ‘special’ characters or formatting hidden in the document as I have seen this cause issues for people.
Install Certificate and Private Key
It’s taken a bit of work but we are now ready to copy the certificate and private key to the Trend Smart Protection Server and say goodbye to that annoying self-signed certificate.
I chose to use WinSCP to copy the server.pem file to my appliance. You can see my local directory on the left and side of the screenshot, this includes all of the files I have created during this process. On the right hand side we have the SPS appliance directory, specifically /etc/lighttpd. You can see another server.pem file, we are going to replace this – my advice is to rename this file first so we have it as a backup. Next copy the newly created server.pem file.
Having copied the required file over we can either SSH onto the box and restart services or just restart the virtual machine.
To restart the required service via SSH use the following command once logged on –
service lighttpd restart
Well now would you look at that, my certificate alert has fled the building! Also note I have connected once with the fully qualified domain name (FQDN) and once with the IP address to demonstrate the subject alternate name (SAN) attributes configured into the certificate work.
Note the complete path to my certificate authority.
Depending on your preference you could now disable SSH on the appliance however I leave this decision up to you.
I finally got round to writing this post, it’s been sat in my drafts for a while – I do hope you have found the information useful. If you have any questions please drop them in the comments section below and feel free to point others to this article if it will help them.