Safeguard Enterprise server over Internet not via VPN

Can you route to the website in a browser? 

If you can - does the page display properly?

On the SGN server - do an invoke test and see what it returns.

We renewed a certificate on our secondary server, would that effect it?

Yes it would Dan - Did you use a public cert or is it an internal one? Public ones will require that the intermediary certs (if needed) are accessible. We do this via GPO to all the AD bound machines, but if it's an internal cert the clients will need a copy of the certs. Creating a new configuration file and applying this to the clients would resolve as the config file contains the certs needed-  but you then have the hassle of applying the new config file to every client.....

It was an internal one, but surely just renewing, why does it cause this issue, because then we have to change something every time it expires. What do we have to change to the config file? This is for domain users

The SSL cert secures communication between the host and client so it's critical. I understand your frustration - I had exactly this challenge last year and despite Support suggesting otherwise, I was able to get away with it as I used an externally minted cert - so the clients picked up the change straight away as soon as I switched the cert over and restarted IIS. You have a few options though since they're domain bound but this would HAVE to have access to your AD/GPO. This works for physical PC's on site but if you have laptops and don't have an always on VPN then it's more of a challenge! When you create a config file on the server, it creates an MSI file. This contains some XML/config AND the certs. This is the easiest method of doing it to be honest - but as I said...needs installing/running on every client. 

This is common though for certs and not a fault of Sophos as such . I do though wish there was better functionality for this, but also appreciate the security constraints of this. If the client could update itself/update certs in the same way it can do policies....we'd be onto a winner! This is made worse by the recent validity period being reduced for certs too-  most are only a year now so this is a more common event than it was!

So - Push out the certs with AD/GPO to the domain bound clients (is the SSG server not bound to the same domain?) or create a new config file and apply it to the client.

Personally - I'd create a new config file anyway - apply it to the one client you've pictured - reboot and then test all works again?

Yes the SGS Server is on the same domain

Then you could push out all the certs from the DC? How many PC's are there?

About 200 plus, it's fine when connected via our vpn for domain users, but it's more of an issue with the WORKGROUPS now not able to sync

Ah ha, you have domain bound AND Workgroup? Obviously you'll not be able to use the DC to push out to those and as it's an internal cert your easy options are limited. I would create a new configuration file and install that. Unless the WG PC's are managed by some sort of MDM?

No unfortunately, our Domains will be fine as the certs gets pushed out but it was more for our workgroups, but because we found that when our domains weren't connected via the vpn it was erroring when syncing but that's because our secondary server which is setup for that the cert expired and was renewed.

One of the reasons my secondary is in the DMZ and has a public cert! I'm afraid your options are...config file....or install the certs manually. How many WG PC's are there - it that the 200 plus figure or is that the whole estate?

Probably the same if not more, however we will hopefully be moving away from workgroups in the future, so with this in mind it's not that urgent, but can I ask what issues we will stumble across if we leave it? I presume from a support side we can still recover Bitlocker codes via the helpdesk etc?

Probably the same if not more, however we will hopefully be moving away from workgroups in the future, so with this in mind it's not that urgent, but can I ask what issues we will stumble across if we leave it? I presume from a support side we can still recover Bitlocker codes via the helpdesk etc?

If there's a primary server that still works - no real issues at all. Your secondary is there purely as a failover to the primary should that become unavailable. Yes - as long as the primary remains up and there's a server to communicate with every X minutes (what's ever set as your policy). I would personally resolve it - but appreciate it's hassle. 

Hi Michael

Thanks for all the advice you've given Dan P already, much appreciated.

We had this secondary server set up to allow all our Citrix users' computers to sync with SGS. These computers are remote (no direct connection to our network, no VPN, etc) and they are workgroup only.

What that in mind I just have a couple of follow-up questions I wonder if you could clarify please?

1) Our secondary server is in the DMZ (or port-forwarded, strictly speaking). Given what you said above, about keeping your server in a DMZ and using a public cert, if we purchased a public cert for this server, to replace the one from our CA, would that allow these remote workgroup clients to start synchronising again?

2) If we don't resolve this, what's the implication for these clients? Is it basically just that they won't be able to sync any new policies or changes to existing ones? We don't really ever change the policies that we created at the beginning, so we could probably live with that until we eventually move away from Citrix.

many thanks

Dan W

Hi other Dan!

1 - In theory this should work. Assuming the public CA AND the supporting intermediaries are publicly accessible so the chain doesnt break down. Is this secondary server ONLY for the workgroup devices, or do the domain devices use this as their secondary too? Do the workgroup devices ever use the primary?

2 - If the clients fail to report back to the server then they'll fail to report back any BL changes. This could mean the server does not have a copy of the current recovery key if the key rotates after use. It also means no policies as you pointed out. Something you could possibly live with IF you're running the very latest client and backend. If you're not and you need to change the backend or client - You will have to assume the server doesn't change the behaviour of the client. This has happened before where an update for me personally caused OneDrive to really mess up. It turned out the File Encryption policy had to be modified - even though I wasnt using it. 

I'm not sure of your own timeline but you're probably aware that SSG has been declared EOL now and won't be any new versions as such. How much effort you want to put into this, combined with a planned move away from Citrix I don't know. As I said, I would resolve this mainly for rhe issue of outdated RK's on the server. It's only going to take one user to kick off if their drive needs a RK and helpdesk can't produce one (or at least a current one that works!)

Hi Michael

Thanks for the reply.

In answer to your question, from memory all endpoints are configured to try the primary first, and then the secondary if they can't reach the primary. So although the workgroup devices will attempt to contact the primary first, they'll never find it and will always fail over to the secondary. This was how it was set up by our Sophos partner a couple of years ago.

Dan