Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
SOLVED

Using MSATA Center with a 3rd Party Certificate

Copper Contributor

I started using MSATA at v1.7. I created a 3rd Party certificate so that the Center and Light Gateways could communicate securely, because I replace the Center server every 3 months - so I needed an external certificate, not one generated on the Center server, so that I could import the certificate to the rebuilt Center server without having to redistribute the public cert to all the Light Gateways.

 

In the "What's new in v1.8" docs, is states "Starting with ATA version 1.8 the ATA Gateways and Lightweight Gateways are managing their own certificates and need no administrator interaction to manage them."

 

The task I want to perform is that I want to distribute the public Center cert to the servers that run the Light Gateways using Group Policy. This will reduce my admin since I rebuild these servers every 3 months too, and if I distribute the public certificate using GPO, I don't need to download and install this cert manually to each of those servers when I rebuild them.

 

I've created a new GPO and imported the certificate chain into it. To test that a Light Gateway would stop being able to communicate with the Center server if it didn't have the correct cert installed, I deleted my cert from the Light Gateway, then restarted the Light Gateway service. But it connected, and the logs all show it's communicating with the Center server just fine. The logs contain, in the initialization phase, the thumbprint of my 3rd Party Center cert, and if I access my Center url in my browser, I watched the Light Gateway change from Starting to Running, and in the configuration my 3rd Party cert is selected (and there's another one in the dropdown called "ATACenter").

 

So, it looks like I no longer need to install my 3rd Party certificate on the Light Gateways (I'm currently running ATA v1.9)? Or is there a hidden process as part of the Light Gateway install/initialization that needs to use the 3rd Party Center cert for something, for example for generating the local "ATAGateway" certificate?

 

Any help appreciated.

11 Replies
best response confirmed by R B (Copper Contributor)
Solution

The only cert you need to manage from now on is the Center Cert (which you also did for prior versions).

The communication between the Center and Gateways is now done with auto created self signed certs,

which will also auto renew.

You don't need to do ANYTHING for these certs, everything is done automatically.

 

So when I create a new Center server, all I need to do is ensure the 3rd Party Center cert is installed on the new Center server before I import the database from the old server, and the existing Light Gateways will all reconnect to the new Center server without any further config needed?

True, giving that you also restored the DB configuration using a proper json file backup.

Exact steps are in this guide:

https://docs.microsoft.com/en-us/advanced-threat-analytics/disaster-recovery

 

make sure you back up all the needed data (cert + up to date json backup)

Out of curiosity, what induces the need to rebuilt the center every 3 months?

Yes that's right, the rebuild needs to use the latest backup of the SystemProfile.json with matching database backup. I used the Disaster Recovery link you gave as a basis for my restore scripts (and the script which does the regular backups).

 

Company Policy is to rebuild all servers at least every 3 months.

 

Hi Eli,

 

"The communication between the Center and Gateways is now done with auto created self signed certs, which will also auto renew. You don't need to do ANYTHING for these certs, everything is done automatically."

 

My 3rd Party cert is due to expire soon on one of my Center servers, so I created a new one with the same CN. I imported the certificate with private key and full cert chain onto my Center server, and shortly after it showed up in the Center Console in the Configuration > Center > Certificate dropdown box. I selected it and clicked "Save", then waited for the message at the top of the screen to say that all 5 of my Light Gateways has synched the latest config. Then, I clicked to Apply the new certificate.

 

I waited for 15 minutes and the Gateways were all showing as Running in the Gateways screen still. When I looked in the Console a few hours later, it said 4 of the Gateways were not responding ... but 1 of them was Running. When I RDP'd onto a couple of the unresponsive Gateways and looked at the logs, I had the following: error:

2018-10-18 14:06:59.3164 5388 18 Error [WebClient+<InvokeAsync>d__8`1] System.Net.Http.HttpRequestException: PostAsync failed [requestTypeName=UpsertGatewayMonitoringAlertRequest] ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IdentityModel.Tokens.SecurityTokenValidationException: Failed to validate certificate [Subject=CN=<my cert details>, SERIALNUMBER=<a number> Thumbprint=<the new thumbprint>]
at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)
--- End of inner exception stack trace ---
at async Microsoft.Tri.Common.Communication.WebClient.PostAsync[](?)
at async Microsoft.Tri.Common.Communication.WebClient.InvokeAsync[](?)
--- End of inner exception stack trace ---
at async Microsoft.Tri.Common.Communication.WebClient.InvokeAsync[](?)
at async Microsoft.Tri.Common.Communication.WebClient.InvokeAsync[](?)
at async Microsoft.Tri.Gateway.Communication.CenterMonitoringEngineProxy.UpsertGatewayMonitoringAlertAsync(?)
at async Microsoft.Tri.Gateway.Collection.Events.EventActivityTranslators.EventActivityTranslator`2.UpsertMonitoringAlertAsync[](?)
at async Microsoft.Tri.Infrastructure.Framework.Module.<>c__DisplayClass30_0.<RegisterPeriodicTask>b__1(?)
at async Microsoft.Tri.Infrastructure.Extensions.TaskExtension.<>c__DisplayClass33_0.<RunPeriodic>b__0(?)

...but when I checked on the Gateway that was Running, the service was running. I restarted the Gateway service and it was still Running and the log showed it was successfully communicating with the Center server. I rebooted the server that the Gateway was running on, and the Gateway service started up perfectly and started sending traffic to the Center server. So, on this one server, the LGateway service was running perfectly.

 

I had the same error as above on all 4 of my domain controllers that are running the Light Gateways. I then imported the certificate + chain (but not private key) into a Group Policy that I applied to the domain controllers and within a few seconds a green message appeared in the Center console saying all the Gateways had successfully synched the latest changes and then within a couple of minutes, they'd all changed to Running in the console.

 

My question is, why did one Light Gateway work fine and the other 4 didn't, when I changed the certificate on the Center server? Didn't the other 4 download the new certificate from the Center server after I changed it, so even thought they synched the config change, they didn't fully "synch the change" because they hadn't yet downloaded the certificate?

 

I checked the LGateway that was working and it didn't have my new cert on, it just had the "ATACenter" cert.

 

I need to know what happened because I need to know if I need to change the cert in the GPO for the Light Gateways every time we change the cert (because I have multiple Center servers for different domains).

 

Thanks.

I am not sure what went wrong in this case, but if you are sure you waited for all gateways to fully sync before activating the new cert on the console, they only thing I can think of is that for some reason for some time (or until the reboot) the machines were not able to validate this new cert against the certificate store chain...

Hi Eli,

 

I did reboot two of the problem machines 15 minutes after I made the change, in case this was required, but it made no difference.

 

I have had problems in the past where I've selected a different cert or changed the Center URL on the same screen, clicked Save, waited for the green "all gateways have synchronised" message, then clicked "Activate", and the Gateways all immediately stop connecting because they hadn't all synchronised - and when I check the GatewayConfiguration.json on one of those machines, it doesn't contain the change to the new URL. When I make a change like this, I usually wait about 5 minutes after receiving the "everything is synchronised" message before I set it as active. So, maybe it's a problem with the synchronisation process, where the Center console says that the changes are synched to everywhere when they're not.

 

Thanks.

Weird, Never heard about this message reporting all sync is complete while it is not yet,

 I will open a bug to research it. Do  yo happen to know if just the green message was wrong, or in the list of Gateways page also every GW was marked as synced but yet it wasn't ?


@R B wrote:

Hi Eli,

 

I did reboot two of the problem machines 15 minutes after I made the change, in case this was required, but it made no difference.

 

I have had problems in the past where I've selected a different cert or changed the Center URL on the same screen, clicked Save, waited for the green "all gateways have synchronised" message, then clicked "Activate", and the Gateways all immediately stop connecting because they hadn't all synchronised - and when I check the GatewayConfiguration.json on one of those machines, it doesn't contain the change to the new URL. When I make a change like this, I usually wait about 5 minutes after receiving the "everything is synchronised" message before I set it as active. So, maybe it's a problem with the synchronisation process, where the Center console says that the changes are synched to everywhere when they're not.

 

Thanks.


 

Hi Eli, last time I did this was months ago so I don't fully remember what the status was on the Gateways page. The message appears after I click Save, first as a red message, which then turns green after only about 5-10 seconds. I only have 5 light gateways and they're all on a fast network in the same location as the Center server.

Just to confirm, I've built a new Domain Controller and I was able to successfully get a new Light Gateway running when I installed the 3rd Party Center certificate public key certificate + intermediate chain into the Domain Controller. The easiest way is just to add the certs into a Group Policy to install them into the Trusted Root cert store, and attach the GPO to the standard "Domain Controllers" OU. This means that any new machines that get promoted to Domain Controller will have the cert installed automatically so you don't need to worry about how to get the certs onto a new DC.

1 best response

Accepted Solutions
best response confirmed by R B (Copper Contributor)
Solution

The only cert you need to manage from now on is the Center Cert (which you also did for prior versions).

The communication between the Center and Gateways is now done with auto created self signed certs,

which will also auto renew.

You don't need to do ANYTHING for these certs, everything is done automatically.

 

View solution in original post