2022-01-31 10:03:29.554 [0944.42a0] I: Checking for updates from https://F-secure.dist.local:443/guts2
2022-01-31 10:03:29.602 [0944.42a0] I: Update check failed, error=216 (untrusted root ca)
We would propose to try these workaround one by one and check if it helps.
1. Check the client device system date and time
2. Restart the client device and try to reproduce the issue
3. Adding needed CA certificate:
a) There may be some problems adding the needed certificate from third party Root Certification Authorities store. F-Secure currently uses the Digicert Root CA.
You can try to install the certificate manually from here
b) If you are using a third-party Certificate Authority (e.g. Starfield, GlobalSign), ensure this certificates are valid and installed in the host.
c) If choosing the local machine (all users) option doesn't fix it, try to add the certificate to the user's profile option instead.
d) DNS can also be the reason, so try using Google DNS 188.8.131.52 (and 184.108.40.206) and see if it solves the issue. You can check this by using ping to guts2.sp.f-secure.com if it times out, change to Google DNS.
Also the installation can fail in multiple ways if you have the Enabled the "Turn off Automatic Root Certificate Update" and don't have the latest root certificates available.
This problem can be fixed by enabling the automatic root certificate updates via Group Policy: Computer Configuration / Administrative Templates / System / Internet Communication Management / Internet Communication settings / Turn off Automatic Root Certificate Update, which need to be set as Not Configured or Disabled.
Note: The name of the feature starts with "Turn off" so when it is enabled, it prevents the Windows from automatically downloading the needed new root certificates.
We get this warning against our internal Policy Server - updates from F-Secure (as fall back allowed) are working.
So the mentioned steps do not work for us
I have a ticket opend # and also provides a FSDiag from my client system.
Also the F-Secure Server Security on the Policy Manager Server throws the same error message (Untrusted root CA) when searching for updates against the internal Policy Server.
Note: Clients & Servers receive their policy settings without any problems - only update check is not successful
we are facing the same problem:
"2022-03-18 10:17:47.515 [1f2c.0344] I: Checking for updates from https : //de-do-admin2.ads.wilo.de : 443 / guts2
2022-03-18 10:17:50.671 [1f2c.0344] I: Update check failed, error=216 (untrusted root ca)"
We are using our internal CA, which all internal clients and servers trust (windows devcie certificate store - trusted root ca).
Web-Reporting by Edge, F-Secure Console have no problem with this certificate but it seems, new policy setting "Use HTTPS to download updates (15.x hosts only) is not correctly implemented on V15 installations?!
Do Clients/Servers use their own lists of tusted Root CAs?
All documentation i found for using our own certificates mention changes just on Policy Manager Server, but not on any F-Secure on clients/servers?!
We are having the same issue. The Policy Manager (v15.30) certificate has been replaced with one issued by a CA that via a intermediate CA is connected to a trusted root CA. The P12 certificate included the chain: intermediate CA - CA- certificate. The public root CA is listed in the Windows "Trusted Root Certification Authorities". When accessing our Policy Server using a web browser, everything looks fine and the https certificate is trusted. However, switching to HTTPS to download updates is not working.
As this might be important: We configured "additional_java_args = -DforbidDownloadingPublicKey=true -DenableVistaInteroperability=false" to disable TLS 1.0 and 1.1 as described at https://community.f-secure.com/business-suite-en/kb/articles/5839-how-to-disable-tls1-0-and-tls1-0-in-policy-manager-server-on-windows
Assume that you have:
Steps to replace the default Policy Manager certificate:
"C:\Program Files (x86)\F-Secure\Management Server 5\jre\bin\keytool" -importkeystore
-destkeystore fspms.jks -deststorepass superPASSWORD -destalias fspms -destkeypass superPASSWORD
-srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass srcpassword -srcalias server
Existing entry alias server exists, overwrite? [no]:
NOTE: When you execute the importkeystore command pay attention to "-destkeypass", it should be the same as "-deststorepass". If you forget to insert proper "-destkeypass", the command can complete successfully but problems on Policy Manager server startup may occur.
Thank you very much for your reply!
I tried to follow this procedure but it failed. What I did was first copying fspms.jks to my computer. Here I used Keystore Explorer (keystore[minus]explorer[dot]org) to replace the certificate. I made sure to use the same name and and the same passwords as given in your description. Also the full chain was included in my PKCS12 file.
As said, accessing the Policy Manager WebUI works well and my certificate is used properly. So I guess the replacement worked well.
What is not working is switching the update process from http to https. We also see the error message "untrusted root ca" in our logs. My guess is that the F-Secure update process (or maybe the underlying Java) relies on its own root CAs and does not use the ones provided by the operating system.
Can you try this other step ?
Based on data from the Java KeyStore (.jks) files, the certificates on the Policy Manager Proxy was renewed, however, it was not included in the logs. The CA certificate was updated, however, SCEP certificates were not.
You can delete the SCEP certificates from fspms-ca.jks to fix the issue.
For Policy Manager installed on a Linux host: :
For Policy Manager installed on a Windows host:
Once the steps above are completed, the definiton updates should work as expected.
I just checked "C:\Program Files (x86)\F-Secure\Management Server 5\jre\lib\security\cacerts". Our root CA is listed. So the Java shouldn't be the issue.
I would suggest to open a support ticket with the PMS FSDiag.
Just to summarize in case someone else comes accross this page:
I replaced the certificate in fspms.jks with a one signed by our own CA. This CA is signed by an intermediate CA which is signed by a trusted root CA.
I removed fspm-ra-encryption and fspm-ra-signing from fspms-ca.jks (leaving only fspm-ca behind) from fspms-ca.jks while the F-Secure Policy Manager Server was stopped and the Policy Manager Console was closed.
When starting the Policy Manager Console again, I was NOT asked to accept a new certificate.
"C:\Program Files (x86)\F-Secure\Management Server 5\bin\fspmp-enroll-tls-certificate.bat" does NOT exist on the Windows Server 2019 machine where Policy Manager v15.30 is installed. We are not using a Policy Manager Proxy.
"Use HTTPS to download updates" is still "not successful".
I will file a support ticket with F-Secure now.
Best regards, Erika
I have the same issue, anyone has a solution ?
Best regards, Romain.
Have you tried the suggested Answers posted in this thread ?
Yes i tried all off suggested Answers posted.
I opened a support ticket, but it's complicated, i added our CA in database unsusscefully...
So i tried my chance here, hoping someone has find solution since january.
If the mentioned solutions does not work, I suggest you to continue with the investigation via support ticket as we need to check the FSDiag.