cannot get HTTPS / SSL webconsole to work

[JSbtg 0]

I am new in the IT field, and I have built a windows 2016 server VM, I used the all-in-one installer to get this guy going, and have 400 clients connecting properly. I have been tasked with getting our webconsole to go to HTTPS://era.******.com without the "your connection is not private" warning on chrome. I have spent an embarrassing amount of time trying to rectify this. I am not sure which end I have is wrong, I feel it is either the certificate I am using is wrong, or I can not get the commands processed properly to get a properly configured .keystore going. I have been following:

https://support.eset.com/kb3724/?locale=en_US

https://support.eset.com/kb5695/#signed

https://forum.eset.com/topic/9027-correct-procedure-to-install-a-commercial-wildcard-cert-into-era-64/

https://forum.eset.com/topic/9027-correct-procedure-to-install-a-commercial-wildcard-cert-into-era-64

https://forum.eset.com/topic/4986-era-v6-webconsole-ssl-certificate/

and a translated version of https://servis.eset.cz/knowledgebase/article/View/497/60/jak-do-era-web-console-nahrat-vlastni-ssl-certifikat

I need some assistance. 

 

What I have is a ***.PFX cert supplied from my company, which has the desired ERA.*****.com entry in it. 

Where I belive I download the cert file from, I have the following version options: Apache, exchange, IIS, MAC OS X, Tomcat, other

I am not sure where to start, but would seriously appreciate some assistance on this please. 

Edited September 26, 2017 by JSbtg

[MartinK 378]

Technically what you have to do is convert .pfx to .jks (Java keystore) format. This is standard procedure and you do not have to rely on ESET articles -> you can search for any help regarding importing custom certificate into Apache Tomcat -> there are many articles for different SSL certificate providers.

When you are creating your own keystore (.jks), it is possible to use tool "KeyStore Explorer" (http://keystore-explorer.org/) which provides GUI for manipulating keystores. It even supports import key-pairs from pfx files, which may be what you want. When you import key-pair (certificate and private key part) into jks, you have to:

• choose some human-readable alias for imported key-pair, I would recommend default "tomcat" alias.
• choose password for protecting imported key and certstore as a whole. Not sure it is actually required, but I would recommend to use the same, and strong password.

One your new keystore is ready, you have to re-configure Apache Tomcat to use it. Technically you have to search for active SSL connector part, where this settings will be most probably present in your ERA installation:

keystoreFile="/etc/tomcat/keystore.jks"
keystorePass="dfARqwunc651aAW15dAWE5dwef1"
keyAlias="tomcat"

where first one will be different in your case. You have to adapt these settings (in server.xml) to your newly created keystore file.

I would also recommend to open existing keystore in mentioned KeyStore Explorer, so that you understand its content before creating your own - use path and password from server.xml tomcat configuration file.

Seems that it is even possible to configure Apache Tomcat to use pfx certificate directly (https://support.globalsign.com/customer/en/portal/articles/1223425-tomcat---install-ssl-certificate), but we have not tested this -> it is possible it is platform dependent and there may be problem with configuration.

[JSbtg 0]

Thank you for the information. 

A few questions: 

Am I supposed to just be converting my certificate to the .keystore type? or am I also supposed to combine it with a cert on the machine / tomcat / eset? 

I converted my cert, edited the three fields at the end of the server.XML and restarted tomcat services as well as ESET remote administrator server, without success to login via HTTPS. A theory as to why, is the alias that I enter in the XML, supposed to be what is shown with the

"keytool -v -list -storetype pkcs12 -keystore KEYSTORE_FILE" 

command?

or is the alias a string I entered somewhere? 

 

I question the cert that I am using. when I have it converted, what is an acceptable chain length? Mine says 1. 

[JSbtg 0]

I have tried again, this time with the keystore explorer tool you kindly recommend. I changed the alias and password, and edited the three respective fields in the XML. I then started the tomcat service, and got the warning of "not secure site" 

This makes me feel I have the process working, but the certificate, either is wrong, or I missed a step with that. 

I appreciate the assistance on this. 

Please let me know if there is any  more helpful information I can supply. 

[MartinK 378]

In case Apache Tomcat started, it is highly probable that you new certificate is in use.

Just to be sure, I would recommend to check that SSL/TLS is actually used. IT should be indicated by your browser. Most, if not all, browser also is able to show you certificate actually used by site / ERA WebConsole -> this can be used to verify correct certificate is used.

Regarding insecure site problem, it will be most probably caused by certificate. There are multiple possibilities, for example CA certificate used to sign this certificate is not trusted by browser, or weak cryptography was used to create this certificate, or certificate was signed for different hostname than your are using to access ERA WebConsole.

[JSbtg 0]

So I checked, and sure enough my browser IS using the certificate. under view details, I have an error red triangle next to "certificate error", a green square next to secure connection ( says it is using TLS 1.2 with a strong key exchange (ECDHE_RSA), and a strong cipher (AES_128_GCM)). I also have a green square next to Secure resources. 

 

I feel like this means I am using an inappropriate cert for this function? 

when I select "view certificate", I get a viewable chain length of three. 

 

not sure what to do, in the mean time I am researching "net::ERR_CERT_COMMON_NAME_INVALID" which is the error message next to the red triangle for certificate error. 

[MartinK 378]

1 hour ago, JSbtg said:

not sure what to do, in the mean time I am researching "net::ERR_CERT_COMMON_NAME_INVALID" which is the error message next to the red triangle for certificate error. 

It means, that certificate it not meant to be used for hostname you are yousing to access ERA.

For example, if you are accessing ERA using https://era.yourcompany.com , this exact hostname "era.yourcompany.com" or wildcard alternatives must be either in common name (CN) of certificate, or in it's extension called subject alternative names.

I would recommend to check what hostnames are present in certificate itself (you will get to it when viewing certificate in browser) and either use one of those to access ERA, or ask for new created for proper hostname.

[JSbtg 0]

I am an idiot, but still no great progress. This whole time I have been using the internal IP of the server, to access the ERA webconsole, at https://10.0.x.x,  obviously I will get a cert error for that, and there is no entry in the cert or the firewall, to route the internal address of that server, to the public request. 

the entries we do have, show an inbound from anywhere, requesting https://era.xxxx.com, will take the default 443, and forward to the internal IP of the ERA server. we also sho the DNS record for our cert, to show that era.xxx.com goes to the public IP associated with that server. 

Regardless, from either internal, or external, if I type in the era.xxxx.com OR https://era.xxxx.com, neither loads up, or connects whatsoever. I had some (but not enough) time with a coworker who understands our sonicwall vastly better than I do, he reviewed all of the settings, policies, and entries, and he believes that it all looks like it should be working. he thinks we either need to reboot the sonicwall, or rebuild the entries into it for this. 

I do not know how to test any of this. 

[JSbtg 0]

SO! I have news! I did not want to give up on this yesterday, I looked at it as, I know my cert is being used, and everything looks correct. My coworker mentioned this to our boss, and my boss checked our DNS server, there was either an error in the / or a missing PTR record. He showed me that https://era.xxxx.com/era works. Now the challenge is two items: 

1. Get a hxxp://era.xxxx.com to auto-redirect to https://era.xxxx.com

2. Not have to append the additional "era" at the end of https://era.xxxx.com/era, and have just https://era.xxxx.com either work, or auto-redirect to https://era.xxxx.com/era

 

[JSbtg 0]

according to the documentation, the appending of the additional /era is normal? I tried accessing the tomcat GUI, but I found the "root" folder and entries in the tomcat webapps folder are not there. I suspect this is intentional to raise security of the era against malicious people. 

[MartinK 378]

3 hours ago, JSbtg said:

1. Get a hxxp://era.xxxx.com to auto-redirect to https://era.xxxx.com

Redirecting HTTP to HTTP should be possible by changing Apache Tomcat configuration, see for example this article. I would recommend also to block HTTP access for security reasons.

3 hours ago, JSbtg said:

2. Not have to append the additional "era" at the end of https://era.xxxx.com/era, and have just https://era.xxxx.com either work, or auto-redirect to https://era.xxxx.com/era

Yes, is normal that ERA Webconsole is deployed in "/era", but is is possible to use redirector so that console is accessible from root or different subdirectory. For example placing index.html file into Apache Tomcat's ROOT directory (webapps/ROOT/) with this content:

<!DOCTYPE HTML>
<html lang="en-US">
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="0;url=era/" />
        <script type="text/javascript">
            window.location.href = "era/"
        </script>
        <title>Page Redirection</title>
    </head>
    <body>
        If you are not redirected automatically, follow the <a href='era/'>link to ERA</a>
    </body>
</html>

should redirect you automatically to ERA.

[JSbtg 0]

Funny, I literally just found that!

 

[JSbtg 0]

I have it all fixed, I am elated with joy. I have http > https, AND era.xxxx.com > era.xxxx.com/era automatically. I did skip the step of:

2. Add the following to the Tomcat conf/web.xml file above "</web-app>"

 <!-- Require HTTPS for everything. -->
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>HTTPSOnly</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

I skipped this, As I think the HTTPS forcing is handled already by the other steps I have done, and I wonder if this would block / affect the ability to automatically redirect HTTP > HTTPS?

 

Should I go back and add this, or is my hunch right? 

[MartinK 378]

14 minutes ago, JSbtg said:

Should I go back and add this, or is my hunch right? 

I don't think it is necessary in case HTTP is disabled by global configuration. Changes would also require to modify content of era/ subdirectory, which could cause problems during upgrade.

[JSbtg 0]

Thank you! I believe I may have all my requested tasks on this completed! I will run this for a little bit and document odd things noted if I have to follow up with anything. 

 

There is a possibility my boss on an apple device was unable to access it, to view and demonstrate the changes.