This morning I updated the firewall certificate, for Portal/VPN.
After I disconnected my Windows 11 Capsule VPN computer I could no longer connect. We had this once before, and the fix was to delete the site, then re-create it. The first time I did this that did not work. So I deleted the site, then rebooted, then re-created it. This time it worked, and I was asked an additional question about the site, and also now have additional options like "Network profile type" that were not there before. I suspect because my computer was a Windows 10 to 11 upgrade, and the site existed on Win10.
For Endpoint users they receive a report that the certificate has changed, and should they trust the new one. That seems to be okay.
But we have a lot of problem with SNX users, both on Mac, and a Win7 machine which I am currently looking at, where Capsule VPN is not an issue.
If I stop the SNX service from running, then from an elevated command prompt I run "slimsvc.exe debug" so I can see logs reported to the console, I see the following:
[ 9680 8572]@AZATHOTH[16 May 11:20:41][ssl_tunnel] ssl_link_fwasync_client_handler: state: << SSL_NEGOTIATION >> - negotiation ended and succeeded
[ 9680 8572]@AZATHOTH[16 May 11:20:41][ssl_tunnel] ssl_link_fwasync_client_handler: server_cn = portal.mrc-cbu.cam.ac.uk, server_fingerprint = BUT RACY JAR FISH BATE TOWN LIT LAND KATE ADD PAY DES
[ 9680 8572]@AZATHOTH[16 May 11:20:41][verify_CN] lookup_gw: Fingerprints match (BUT RACY JAR FISH BATE TOWN LIT LAND KATE ADD PAY DES)
[ 9680 8572]@AZATHOTH[16 May 11:20:41][ssl_tunnel] ssl_link_fwasync_client_handler: (termination code #303) Gateway was successfully verified by the user. Proceeding with connect...
[ 9680 8572]@AZATHOTH[16 May 11:20:41][ssl_tunnel] ssl_link_fwasync_client_handler: server_fingerprint_for_verification = BOGY INTO RAIL AIM FEET INN CAIN WHEE JAN GINA AMID VERB does not match gw_fingerprint = BUT RACY JAR FISH BATE TOWN LIT LAND KATE ADD PAY DES
At first it reports the the site is okay, and then says there is a cert. mismatch. It looks like a local caching issue, but have not had much luck in resolving this so far.
As a workaround, years back CP provided us with a very old version of the SNX software which is command line enabled. I can then use "snx -s <server> -u <user>" to connect, and this works.
I'm running through a few things with the Win7 user, including a complete uninstall of SNX, and related software, then reboot, with a view to re-install from scratch.
Has anyone come across this before?
Howard