Spotfire Ideas Portal
The command "config.bat import-code-signing-certificate" can import code signing certificate, root certificate and also intermediate ca certificate.
However, intermediate ca certificate imported by above command isn't used to build certificate chain when verifying the code signing certificate (when trusting it).
To build the certificate chain correctly, the intermediate ca certificate must be imported into either java's truststore(cacerts) or another single jks keystore file and put it under the tomcat\certs folder.
Also, if spotfire server can access the internet, the intermediate ca certificate can be downloaded automatically and used to build the certifiate chain correctly.
Many of our customers don't allow Spotfire Server machine to access the internet, so it's kinda confusing that root certificate can be imported into spotfire server/cacerts/*.jks, and intermediate ca certificate can only be imported into cacerts/*.jks.
Please make the imported intermediate ca certificate be recognized and used to build the certificate chain when verifying code signing certificate.
Thanks.
I have encountered similar behavior.
1. create a mod or load it in via mod-manifest.
2. export the mod
3. sign the mod with Sectigo validated code signing cert
4a. open the mod. and try trust this third party certificate for future use doesn't work
4b. exporting the certificate attached to the mod for importing on group
5. import said certificate to Everyone group fails with path cannot be completed.
6. importing the root certificates in cacerts on JDK level cacerts allows import as the chain can be completed, however assuming these certificates will not be transported when upgrading Spotfire server. so this must be done each update.
So having an option to place a certificate truststore under /tomcat/certs would be great. I found this doesn't work currently.
possibility to turn of the verification of third party certificates doesn't sound like a viable solution in the long-term.
come to think of it, would said exported certificate from mod become a trusted certificate equivalent that allows verification only for third parties certificate so that mods are trusted for groups based on this certificate sounds fair. however, when WP and Analyst validate against the windows (what about linux) certstore it will be hard to tell if this imported mod certificate was the right one.
then you may want to push a truststore along towards a WP/analyst/automation client so that it can be validated based on the imported certs on server.
ps. I'm not an expert in certificate chains though.
It turns out that intermediate certificate CAN NOT be imported in spotfire server with command "config.bat import-code-signing-certificate" at all.
Some intermediate certificates(with extended key usage be 'code signing' only) can be importe with command above however actually it is imported as a entity code siging certificate, spotfire server doesn't treat it as a intermediate certificate.
That's OK to validate in that way, the purpose of this idea is just to take all imported intermediate certificates(by command import-code-signing-certificate) into consideration. Turning off "security.code-trust.validate-uploaded-cert" doesn't "solve" this problem because it disables server side certificate validation completely however that's not what I intend to do.
Right. The purpose of that validation is to give a "fail early" behavior by detecting things that will not be possible to verify later on. In some cases (like this one) it however fails even when it should not. Chaning the configuration property I mentioned should solve the problem (by disabling this server-side validation).
When verification mod's signature, it works exactly as what you said.
The problem is that, when trusting code signing certificate to groups(e.g. Everyone), the code signing certificate is verified on Spotfire Server, i.e. spotfire server tries to build a certificate chain with the uploaded code signing certificate, and all imported root certificates and all certificates stored in cacerts and tomcat/certs/*.jks. Since currently intermediate certificates imported into spotfire server with command import-code-signing-certificate are not used to build this chain so they must be imported into cacerts or put into a tomcat/certs/*.jks file.
Actually this is more like a defect to me.
Would you be able to elaborate a bit on the use case and what problems the current behavior is causing?
The signature validation that is done on the Spotfire Server is only for error detection purposes. The actual validation of the mods to be used is done either within the Spotfire Analyst or within the Web Player service (which is unaffected by any modifications done to the Java trust stores - it uses the local Windows certificate stores, together with the trusted certificates imported using the
import-code-signing-certificatecommand). The validation on the Spotfire Server can be disabled by setting thesecurity.code-trust.validate-uploaded-certconfiguration property tofalse. See https://docs.tibco.com/pub/spotfire_server/11.5.0/doc/html/TIB_sfire_server_tsas_admin_help/server/topics/trusting_custom_content_in_the_spotfire_environment.htmlWhile it would be possible to allow importing intermediate CA certificates Internet access would normally still be required (from the Web Player service or from the Spotfire Analyst) to perform revocation checks.
Also, since certificates imported into spotfire server are stored in the repository database, they will be migrated when upgrading TSS to a newer version, so importing certificate into spotfire server is considered as recommended approach by us.
This also requires this idea to be implemented.