We just installed a fresh root server for a windows server migration. The local console works fine but some remote users get the following error -> "SSL Error (60): Root Server SSL Certificate not valid for the host “our server fqdn”.
The self signed cert that auto-generated on install seems to work fine for web reports and webui. What did we miss? Thanks!
If they were managing a previous deployment using the same server alias name, I’d suspect the cached masthead/certificate from the previous deployment might be conflicting (their console expecting the previous self-signed certificate/masthead).
The first thing I’d try, on their console machine, is to delete or rename their previous console cache/configuration stored at C:\Users\<username>\AppData\Local\BigFix\Enterprise Console and then try re-launching the console.
Please let me know whether that helps, I haven’t actually seen that message before and this is a speculation on my part. If that doesn’t resolve, we can look at registry entries or whether this message is actually coming from a proxy between the console and the root server.
They do manage an existing environment and should be able to switch between the two as needed. Server and console versions are the same, but the server names and mastheads are different. I will have them give that cache/config clear a try and let you know. Thanks!
Ok, if the two deployments have different names that’s less likely to be a problem.
There is another edge-case compatibility worth exploring. I’m aware of an issue where, if the BES client on the Console machine is connected to a deployment that requires Enhanced Security, the console on the same machine can only connect to deployments that also have Enhanced Security enabled.
If Enhanced Security is not required on the new deployment, you might consider turning it on. While I haven’t seen that specific error message associated with this problem, I also can’t say that I tried mixing enhanced and non-enhanced security since…10.0.4 or so and we may have changed the error messages around that.
We did in fact notice that Enhanced Security was enabled on the old environment and not the new one. Now that they match, the users are going to test it and let us know.
Switching the new server to match the Enhanced Security setting of the existing server is what solved the issue. Thanks for the suggestion @JasonWalker!