Seeking Clarification from the SSL Certificate Experts --- Setting up Agent HTTPS to Beacon Communication

[bruce_giles]

Hi Everyone, let me start off by declaring I know enough to be dangerous in terms of how the SSL certificate process works. I think I understand how the web browser to web site process works when trying to connect to a secured website. Basically, the certificate details get sent back and forth to ensure both sides trust the certificate and then the secured communication takes place.

I am investigating what needs to take place in our environment (Cloud North America) to introduce HTTPS  TLS  for the Agent to Beacon communication. As we know in the Cloud environment, the Beacon is required to use https over TLS 1.1 or 1.2 to communication to the Cloud Application Server by default so that piece already exists.

My confusion starts when I read in the Knowledge Article (https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/How-to-setup-https-SSL-TLS-to-secure-and-encrypt-internal-FNMS/ta-p/2085) on how to setup the Agent. I have pasted that section below to make things a little easier. It refers to either copying the  Root Certificate of your SSL Certificate Authority used on all Beacon Servers to all servers where the agent is running or if I understand correctly, making some registry key additions.

This is where I am lost of sorts on both scenarios .. 

In the certificate solution, is it as easy as .. due to the fact that the server where the agent is running now has the same certificate as the Beacon, it automatically uses HTTPS as the first choice since the certificate exists ?

For the registry key scenario, I am really confused because if I understand correctly we are adding 2 keys to tell the agent process NOT to check the server certificate or check the certificate revocation. So if its not checking for those things it will complain about the Beacon certificate not being accepted.

Perhaps someone could straighten me out on how the agent will know to use https vs http when sending the file to the Beacon in these 2 solutions. Obviously I am missing some basic fundamentals on how the certificate process in the Flexera environment operates.  I know when I built the Beacon servers, I also added those 2 registry keys along with a few other registry keys to enforce TLS 1.2 but didn't really understand why.

Thanks in Advance

Bruce

Windows Agents:

For Windows Agents to communicate to the Beacons over https, you can either:

• Distribute the Root Certificate of your SSL Certificate Authority used on all Beacon Servers or the self-signed Certificate itself through Active Directory Group Policy. If the Agent is already installed and failed to download its policy, you need to re-run the policy download using the mgspolicy -t machine command and then check the end of the installation.log file to review the results.
• As a non-recommended workaround (less secure) before the Agent is installed, you can add the following lines under [Common] in your bootstrap mgssetup.ini file. Please make sure you don't have duplicate desc0 and desc1 lines already in your current file under [Common].

desc0 = CheckCertificateRevocation
val0 = False
desc1 = CheckServerCertificate
val1 = False

• As a non-recommended workaround (less secure) after the Agent is installed, you can disable the Certificate Check and Revocation Check by adding the following Strings with the value of False under this Registry Key "HKLM\SOFTWARE\Wow6432Node\ManageSoft Corp\ManageSoft\Common" for 64-bit devices (remove \Wow6432Node for 32-bit devices):

CheckServerCertificate
CheckCertificateRevocation
You would need to re-run the policy download with the mgspolicy -t machine command if the initial Agent install failed.

• Another option to distribute the above registry keys is creating a SkipCertificateCheck.reg file with notepad and copy the content below. You can then apply this registry setting file through any third-party tool to your environment, or apply it manually by double-clicking the file on the Managed Device when needed. There is no harm for distributing this on devices that have no Flexera Agents on them as well. If you don't have 32-bit Operating Systems in your environment, you can remove the last three lines if desired.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ManageSoft Corp\ManageSoft\Common]
"CheckServerCertificate"="false"
"CheckCertificateRevocation"="false"

[HKEY_LOCAL_MACHINE\SOFTWARE\ManageSoft Corp\ManageSoft\Common]
"CheckServerCertificate"="false"
"CheckCertificateRevocation"="false"

[adrian_ritz1]

Hello,

1st you need to install the IIS on the beacon server, according to documentation.

Then you need to order a certificate from your internal PKI or Internal RootCA, this certificate which is specific to your beacon server will be installed.

Then from beacon application software, on local webserver you choose to use the https option with IIS

On the agent side, you modify your mgssetup.ini file and put the new address in form of https

CheckServcerCertificate and CheckRevocationServer you don't need to put on false as long as your internal RootCA is properly configured and the revocation server is available

In windows environment should be an easy tasks, the things get complicated on linux/unix part because they are not working by default with SSL, you can the documentation on how to do it on unix part.

IF the environment is properly set up, for windows devices you should not have any issues.  

[cdubs76]

HI Bruce,

I've been fighting with the agents and SSL to the beacons for the better part of the last year in various scenarios for our use cases.   Here's what i've learned.

Windows servers---communication should be fine as long as the Root CA cert is in the remote system's Trusted Root authorities.  with that...there is trust.  You don't need to disable the "CheckServerCertificate" check.  That defeats the purpose if you don't validate the certificate you're handshaking with.   The second one however, the certificate revocation check, i have disabled.  We have some cloud environments where the OSCP URL is inaccessible to the agent, so it can't reach the address it needs to check--and it will fail the whole thing for that reason.  I find it less of an issue in our environments by disabling that with keeping the actual cert validation still in check.  

Now---the issue i also had---when we push the agents, we configured them to reach out to the beacon with HTTPS b/c of firewalls, but when it goes and retrieves policies--since our various beacons were set to use HTTP, they will still attempt uploads to HTTP b/c that's what the policy is giving the uploader/tracker as an upload location b/c of how the beacon was initially deployed.   

in those instances, you can force it to upload to a certain location by passing the argument -o UploadLocation=https://server.x.com/ManagesoftRL

I think you can just set that using registry settings if you want to override what's being sent down from the beacon via policy.  In the "Gathering FlexNet Inventory Guide"--it shows you where to shove the settings.  I found this:

Command line

Tool	Upload component (ndupload) or inventory component (ndtrack)
Example	-o UploadLocation=http://server/ManageSoftRL

Registry

Installed by	Manual configuration
Computer preference	[Registry]\ManageSoft\Uploader\CurrentVersion [Registry]\ManageSoft\Tracker\CurrentVersion [Registry]\ManageSoft\Common

[bruce_giles]

Hi There, thanks so much for the advice that has been posted thus far  .. really appreciate it !! As alluded to, it's not as straight forward as we think.

Thx Again

Bruce