Trust File
A secure realm service in TIBCO FTL 5.4.1 automatically generates a trust file. With TIBCO FTL 6.0 or later, a trust file is generated using the --init-security command line option of tibftlserver. The content of the trust file instructs clients to trust the realm service's certificate. Administrators and developers coordinate to supply the trust file to application programs.
A secure realm service generates the trust file in its data directory. The trust file is named ftl-trust.pem. The file contains one or more PEM-encoded public certificates, each of which is typically 1 - 2 KB of data.
Realm administrators give the trust file to the clients: that is, developers and application administrators coordinate so that client programs can access the trust file at run time.
Administrators also supply the trust file directly to ActiveSpaces processes such as tibdgnode, tibdgkeeper, tibdgproxy, and tibdgadmind.
Users can load the trust file into a web browser’s trust store.
Affiliated Realm Services and the Trust File
An affiliated realm service uses the same trust file as its primary realm service. That is, even if you create a different private key for a backup or satellite realm service, a primary server signs that key, so the primary's trust file is still valid for satellites and their clients. As a consequence, you do not distribute separate trust files to clients of a family of affiliated servers: one trust file suffices for the whole family.
Regeneration and Redistribution of the Trust File
If a realm service cannot access its TLS data files, or it cannot decrypt the keystore file, then it generates new TLS data files. The newly generated data files replace any existing data files.
If a primary realm service generates new TLS data files, you must redistribute the new trust file to all clients, including affiliated realm services, other TIBCO FTL components, application programs, and browsers that access the realm service GUI.
- No Access: A primary realm service restarts and cannot access its TLS data files: for example, they have been deleted or moved, or their file access permissions have changed.
- New Password: An administrator restarts the primary realm service, supplying a different password. The server cannot decrypt the existing keystore file using the new password.
If a secondary realm service generates new TLS data files, you need not redistribute its trust file.