Signing and certificates used in the Spotfire Package Builder.

All certificates are built on the chain-of-trust principle. If you do not have access to a certificate signed by an authorized root CA, it may be better not to sign the packages at all. If the signing breaks the chain, e.g., trust from the root CA to the company certificate, there is a possibility that the package will not be considered trusted in the end. 

 

Any self-signed certificates will eventually encounter these types of problems. The signing chain must go from the root CA all the way down to your own certificate.

 

Common questions and answers regarding the signing of packages: 

 

Q). What is the exact usage/role of digital certificate on .spk files created by the Package Builder?

 

A). The role of certificates is to make sure that the package originates from the source that signed it. This is standard practice and based on trust of root certificates (the chain of certificates that your certificate is signed with).

 

Q). What types of certificates does the Spotfire Package Builder support?

 

A). The Package Builder only supports .pfx license certificate files. The .pfx file format is the only file format that can be used to export a certificate and its private key. Most types of certificate files can be converted into other types. More information about .pfx files can be found at: https://blogs.msdn.microsoft.com/kaushal/2010/11/04/various-ssltls-certificate-file-typesextensions/

 

 - When signing a package you will need the private key, since that is what is used to identify yourself. The p7b file format, for instance, does not include the private key, and can therefore not be used to sign the package. Without the private key, the only function of the certificate is to verify that a signed package comes from the person/organization that signed it in the first place.

 

Q). How does the Package Builder handle signing timestamps and how are they used? What happens when a signed package expires?

 

A). Trusted timestamping is done to add information about when the package was signed. The timestamps itself is signed with the certificate authority that supplies the timestamps and cannot be manipulated. The timestamp is used to verify that the certificate was valid when the package was signed.

 

 - A timestamped and signed package will never expire, even if the certificate expires. If the certificate was valid when the package was signed it cannot later be revoked since the certificate was actually valid when the package was signed.

 

 - A signed package that is not timestamped will probably result in an expired package since the check done will return that the certificate is invalid and we cannot provide a point in time when it actually was valid. 

 

 

Certificates are used to verify that the package has not been modified, and is from the specified source. This is accomplished by signing the certificate with a private key and a timestamp. The private key is used to identify the organization and the chain of certificate authorities that supplied the certificate. The timestamp is used to identify when the package was signed. It is itself signed by the certificate authority that supplies the timestamp. Given the chain of certificates and the timestamps, someone can reasonably be sure that the signed package comes from the source that it advertises it is coming from.

 

Package Builder: