In 2024.2+, certificate validation will now be required by the Flex client (see https://cmsosnow.service-now.com/kb?id=kb_article_view&sysparm_article=KB0024219)

This guide will help to troubleshoot why a workstation cannot login to Flex after an upgrade to this version.

This is intended to be a living document, and helpful information should be added once it is discovered.

TlsFatalAlert Error:

If you run into a TlsFatalAlert: certificate_unknown(46) it means the certificate can’t be validated/verified or is just an invalid/bad certificate.

This has been discovered for both Go Daddy and DigiCert at the time of publishing. Other certificate vendors could ship their certificates in a similar fashion.

If your browser when hitting the https://(Server Name):4443 shows this “Not secure” (Left half image) then it is likely the certificate is just bad, or its a self signed cert, so the browser can’t reach out to verify the certificate with any Certificate Authority.



If the browser is ok with the certificate and NOT complaining that it is insecure (Right half image) but Flex is still rejecting it, and you have a Go Daddy/Digicert Cert. your cert likely looks something like the example below.

In this example certificate above, you can see the agency’s name, but above that the host and root path. In the Certification Path, the certificate is offering its own name and certificate, and also the chain of certificate owners who you can verify the authenticity of this certificate with. Both the Go Daddy Secure Certificate Authority and the Root Certificate Authority.

At this point, download/export a copy of the certificate from chrome or certificate manager, right click on it and tell it to “Open in Notepad++ or some text editor. (or if your on the server you can go to /app/tomcat/certs/generated/ and open it there)

If your certificate from Go Daddy looks like this, then that is why Flex is failing to accept it.

Above we saw three certificates referenced in the Certification Path, here inside the actual cert, the information between the
—--BEGIN CERTIFICATE—--- and
—--END CERTIFICATE—-- is one cert.

This gd_bundle-g2.crt is the Secure and Root certificates for godaddy.com acquired from https://certs.godaddy.com/repository.

If your certificate is also lacking those two Certificate Path certificates, download this bundle. Open it just like you did the agency cert with Notepad++ or another text editor. See how it has two sections encased by the begin and end certificate text. The upper one is the Secure certificate for Go Daddy, and the lower one is the Root. You’ll notice they get progressively smaller, this is due to that path above. The agency's cert is the largest, because it also has the information referencing the two certs above it. The Secure is smaller than the agency cert as it only references the Root, and the Root is the smallest as it references nothing.

Simply copy and paste the Go Daddy path certs below the agency cert in your text editor like so. Make sure you don’t have any unnecessary spaces hidden in there at the end of any of the “BEGIN” or “END” lines, then save the certificate.

If you are editing it directly on the server in the /app/tomcat/certs/generated/ folder, re-read nginx via the 4080 webapp manager and then you are done. Try logging in to flex again and it should be good.

If you are editing it in another location you can either replace the cert in /app/tomcat/certs/generated/ or simply re-deploy it with the Certificate Manager in the Tomcat Spillman webapp.

Certificate is Not Trusted Error:

If you have:

- A trusted CA certificate OR

- A self-signed certificate added to the trusted root store on your workstation

- Verified that DNS can resolve the hostname

- Verified that your hostname/IP is part of the Common name OR Subject Alternative Names on the certificate

and find that you are still getting an error message that your certificate cannot be trusted when logging into Flex, you may have an issue with the Revocation URL.

Verify this by going to the %localappdata%\Spillman\Spillman\launcher.log, you may see a similar error to this:

8/14/2024 4:27:46 PM: SSL policy error: RemoteCertificateChainErrors
8/14/2024 4:27:46 PM: Chain error: RevocationStatusUnknown
8/14/2024 4:27:46 PM: Chain error information: The revocation function was unable to check revocation for the certificate.

8/14/2024 4:27:46 PM: Chain error: OfflineRevocation
8/14/2024 4:27:46 PM: Chain error information: The revocation function was unable to check revocation because the revocation server was offline.

This can be resolved by whitelisting the Revocation URL on your VPN. If you are having trouble finding your Revocation URL, it can often be found under the CRL Distribution Points section under your certificate details tab:

Once this URL has been whitelisted, you should now be able to login to the Flex client successfully.