Use an SSL/TLS Certificate with ESET Security Management Center Appliance

ESET Security Management Center (ESMC) is the replacement for the ESET Remote Administrator (ERA) Server. You can install ESMC as a “virtual appliance” which will run on hosts such as VMWare or Linux/KVM/QEMU. Under the hood, this appliance is a CentOS 7 server running the Apache Tomcat web server. ESMC is implemented as a Java application that runs as a systemd service. In my experience, ESET is a solid security product, and the free ERA/ESMC provides some rudimentary endpoint management capabilities. Unfortunately, everything about ESET is confusing, from the naming of their products to their documentation. The documentation is thorough…it’s just hard to find what you’re looking for, which is usually in multiple overlapping documents that each contain part of the puzzle.

SSL/TLS on Linux

The ESMC console is a web application, and HTTPS is enabled by default (good). Unfortunately, it comes with a default SSL/TLS certificate that won’t match your domain name. While it used to be acceptable for internal-facing sites to have unsigned or invalid certificates, that’s no longer the case. Your ESMC server will get flagged for an invalid certificate on any internal vulnerability scan. You will need to install an SSL/TLS certificate signed by a known certificate authority. This is not an easy process for ESMC; it would better if you could do it via the web console. Instead, you have to install the new certificate by modifying the Tomcat web server configuration, which is more complex and prone to problems.

2021 Update: The new ESET docs are much better. There is now a page dedicated to Linux-specific docs that even mentions the solution for SELinux issues with the certificate. There’s still an error in the command to restart tomcat. The erroneous command given in the docs is:

sudo systemctl tomcat restart

The command to restart the tomcat web server should be:

sudo systemctl restart tomcat

One thing that’s still potentially confusing in the docs is that they call for the certificate to be a .pfx file. They actually aren’t looking for file in PFX format, which was a predecessor to the current PKCS #12 standard. They actually want a PKCS #12 file. See how to generate a PKCS12 file with free, open-source tools.

ESET provides detailed documentation for installing an SSL/TLS certificate. Like all things ESET, it’s presented in the most confusing possible style. The entire document details the operation on a Windows server, but there are little bullets that say, “Are you a Linux user?,” and you have to expand them to see the Linux version. Why can’t they just have two separate articles??? Anyway, the Linux process is missing a key step. If you follow all the steps in that document correctly, the ESMC web console may not load. If the ESMC console isn’t loading after installing a custom certificate, read on!

The missing step is to restore the SELinux context of the certificate file. In all likelihood, you transferred the certificate to a home directory on the server using scp, and then moved the file to /etc/tomcat/. Surprisingly, Tomcat starts even when it can’t load the certificate, and running systemctl status -l tomcat won’t show an error. You will see errors like this in the Tomcat log, but they may be hard to find amongst all the other output:

/var/log/tomcat/catalina.2020-11-11.log

Nov 11, 2020 8:16:30 PM org.apache.catalina.core.StandardService initInternal
SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/1.1-8443]]
        at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
        at org.apache.catalina.core.StandardService.initInternal(StandardService.java:560)
        at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
        at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:840)
        at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
        at org.apache.catalina.startup.Catalina.load(Catalina.java:642)
        at org.apache.catalina.startup.Catalina.load(Catalina.java:667)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:253)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:427)
Caused by: org.apache.catalina.LifecycleException: Protocol handler initialization failed
        at org.apache.catalina.connector.Connector.initInternal(Connector.java:980)
        at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
        ... 12 more
Caused by: java.io.FileNotFoundException: /etc/tomcat/my_cert_file.pfx (Permission denied)

The problem is that Tomcat doesn’t have permission to open the cert file. Here’s a command to look in the SELinux log, and the relevant entry:

ausearch -m avc --start recent | grep tomcat

type=AVC msg=audit(1605122190.422:69): avc:  denied  { getattr } for  pid=976 comm="java" path="/etc/tomcat/my_cert_file.pfx" dev="dm-0" ino=201328477 scontext=system_u:system_r:tomcat_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0

The problem is that I copied the certificate file from root’s home directory to /etc/tomcat, and it retained the SELinux context from root’s home directory. We can confirm that the certificate’s context is wrong:

ls -lZ /etc/tomcat/my_cert_file.pfx

-rw-r--r--. root   root   unconfined_u:object_r:admin_home_t:s0 my_cert_file.pfx

The fix is simple:

restorecon /etc/tomcat/my_cert_file.pfx

ls -lZ

-rw-r--r--. root root unconfined_u:object_r:etc_t:s0   /etc/tomcat/my_cert_file.pfx

Restart Tomcat, and the ESMC console should now load.