Jump to content

Install - Unable to contact license validation servers


Recommended Posts

I have recently purchased and am trying to install the Malwarebytes Management Server and am receiving the error "Unable to contact license validation servers (https://keystone.mwbsys.com).  Please check your connection.

The server I'm on has access to the internet.  It appears that there is a certificate mismatch on the AWS systems licensing redirects to, specifically https://ec2-54-175-208-50.compute-1.amazonaws.com/ which has a mismatched certificate address for a wildcard cert issued to *.mwbsys.com.  

Please advise.

cert2.jpg

cert1.jpg

Link to post
Share on other sites

  • 2 weeks later...

Negative... that was my first thought but I validated this server is part of our WCCP bypass ACL, the whole VLAN is and is rather just blocked on outbound 80/443 unless an exception is granted and the firewall opened which in this case it is.  It's also easy enough to see from the browser because when you are getting SSL inspection you get the intermediate certificate in the chain visiting any SSL site which is also not the case here.  I set up the Triton system doing the inspection so I always start with that if I'm having any issues with an SSL communication.

I still don't get why Malwarebytes would have a mismatched certificate on the AWS hosts the licensing is calling?  Why not just fix that?

Link to post
Share on other sites

I imported all those into the local machine trusted root store... same error.  I still think this is somehow related to the fact that when I run this doing an netstat I see that redirection to the AWS hosts by the installer, not a proxy... and that those AWS hosts have the keystone.mwbsys.com certs applied which is mismatched with the AWS hostname.  This is true from the server host I'm attempting to install on, and from any other host or network I've tried including my house.  If you go to  https://ec2-54-175-208-50.compute-1.amazonaws.com/  I imagine you will see this as well?

Thanks...

cert3.jpg

Link to post
Share on other sites

I'm gonna get extra eyes on this, I hope the AWS service isn't dropping the ball here. May I also have a copy of the install log? You can find it in C:\Windows\Temp, you're going to be looking for an MSIxXXXX.LOG containing a reference to managementsystemsetup.msi, organize it by date modified to get the newest one from the install attempts, open it and check for the msi reference, if it is the right one, attach here. 

Link to post
Share on other sites

Ok... found the log file... here's what looks like the pertinent part of it:

"***MEEServer*** 2017-11-21 10:43:53.488: Testing Keystone connectivity
MSI (s) (D0!8C) [10:43:53:488]: Closing MSIHANDLE (24) of type 790531 for thread 3212
MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (25) of type 790531 for thread 3212
***MEEServer*** 2017-11-21 10:43:53.816: Exception thrown while testing Keystone connectivity: 
System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
   at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)
   at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential)
   at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte& thumbPrint)
   at System.Net.Security.SecureChannel.GenerateToken(Byte input, Int32 offset, Int32 count, Byte& output)
   at System.Net.Security.SecureChannel.NextMessage(Byte incoming, Int32 offset, Int32 count)
   at System.Net.Security.SslState.StartSendBlob(Byte incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Net.TlsStream.CallProcessAuthentication(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
   at System.Net.TlsStream.Write(Byte buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Write(Byte buffer, Int32 offset, Int32 size)
   at System.Net.ConnectStream.WriteHeaders(Boolean async)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetResponse()
   at SC.Server.Setup.CustomAction.CustomActions.TestKeystone(Session session)
MSI (s) (D0!8C) [10:43:53:816]: Closing MSIHANDLE (25) of type 790531 for thread 3212
MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (26) of type 790531 for thread 3212
***MEEServer*** 2017-11-21 10:43:53.816: Done with Keystone test. Result: Failure"

 

I would normally associate this with an SSL connection that is trying to negotiate an unsupported protocol or cipher.  So for example TLS 1.0 which has been deprecated and we disable via Group Policy.  Here are are the supported protocols and ciphers on the system this install is failing on... but I also see that the licensing systems allow for our supported protocols and ciphers so not sure why this is failing just yet...

 

 

ciphers.jpg

Link to post
Share on other sites

Ok... found the log file... here's what looks like the pertinent part of it:

"***MEEServer*** 2017-11-21 10:43:53.488: Testing Keystone connectivity
MSI (s) (D0!8C) [10:43:53:488]: Closing MSIHANDLE (24) of type 790531 for thread 3212
MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (25) of type 790531 for thread 3212
***MEEServer*** 2017-11-21 10:43:53.816: Exception thrown while testing Keystone connectivity: 
System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
   at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)
   at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential)
   at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte& thumbPrint)
   at System.Net.Security.SecureChannel.GenerateToken(Byte input, Int32 offset, Int32 count, Byte& output)
   at System.Net.Security.SecureChannel.NextMessage(Byte incoming, Int32 offset, Int32 count)
   at System.Net.Security.SslState.StartSendBlob(Byte incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Net.TlsStream.CallProcessAuthentication(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
   at System.Net.TlsStream.Write(Byte buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Write(Byte buffer, Int32 offset, Int32 size)
   at System.Net.ConnectStream.WriteHeaders(Boolean async)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetResponse()
   at SC.Server.Setup.CustomAction.CustomActions.TestKeystone(Session session)
MSI (s) (D0!8C) [10:43:53:816]: Closing MSIHANDLE (25) of type 790531 for thread 3212
MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (26) of type 790531 for thread 3212
***MEEServer*** 2017-11-21 10:43:53.816: Done with Keystone test. Result: Failure"

 

I would probably associate this with an SSL connection that is trying to negotiate an unsupported protocol or cipher.  So for example TLS 1.0 which has been deprecated and we disable via Group Policy.  Here are are the supported protocols and ciphers on the system this install is failing on... do you kno

Link to post
Share on other sites

Yeah in fact I just enabled TLS 1.0 on this server to test and was able to run through the installer... so you're licensing servers are trying to negotiate TLS 1.0 with the registering server and anyone who doesn't have TLS 1.0 negotiation enabled on their system will fail.  I'm surprised I'm the first one to find this since TLS 1.0 has been a security issue for some time now.

https://www.nist.gov/oism/tls-10-being-turned-wwwnistgov

I'm going to have to turn this back off due to our policy here... but I got the product installed.  I think you guys need to make sure TLS 1.1 or 1.2 is getting negotiated by those licensing servers in order to ensure licensing continues to work and so that other clients are able to register.

 

 

Link to post
Share on other sites

I read that document and it is kind of unrelated... I'm running Windows Server 2016 DataCenter and there isn't any problem with the SQL connection... the problem was on the contacting of the Malwarebytes servers during the installation process, for which I had to downgrade the security on the server to support TLS 1.0... the server once installed may support TLS 1.1 and 1.2 and the SQL connection looks fine... but you can't actually install the product without TLS 1.0 being supported because the licensing mechanism during installation in the installation package itself didn't seem support TLS 1.1 or 1.2 even though the licensing servers themselves do when I checked them with Qualys.  I think you're missing the TLS 1.1 and 1.2 support in the actual installation package but maybe not the product once installed...

 

Thanks!

Link to post
Share on other sites

No, I understood you just fine. We have our own MITM protection to safely use these protocols during install, turning TLS 1 or SSL 2 or 3 back on is what the workaround is. The installer only has those to fail over to and was where I was going by asking for the MSI setup log.

Remember, MBMC is built on older .Net tech, you will need to complete those steps, where applicable (I know 2016 has some of this already built-in, skip the KB's you don't need) according to what SQL you are using for the application - embedded or external, to manage your clients while under TLS 1.1 and 1.2. If you're already on an external SQL that's patched, then you're good there but that very last section has your upcoming solution for the deployment part of your setup after MBMC's installation.

You found the protocol to be the problem, temporarily re-enabled your older protocols and got the product installed, I was trying to give you what you will need from that point onward for your future push of the agent software, and subsequent management of the clients.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.