Trust File
A secure realm server automatically generates a trust file. The content of the trust file instructs clients to trust the realm server's certificate. Administrators and developers coordinate to supply the trust file to application programs.
A secure realm server 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 kilobytes 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 Servers and the Trust File
An affiliated realm server uses the same trust file as its primary realm server. That is, although a backup or satellite server generates its own keystore file, nonetheless the trust file it generates is an exact copy of the primary server's trust file. As a consequence, you do not need to 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 server 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 server generates new TLS data files, you must redistribute the new trust file to all clients, including affiliated realm servers, other TIBCO FTL components, application programs, and browsers that access the realm server GUI.
- No Access: A primary realm server 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 server, supplying a different password. The server cannot decrypt the existing keystore file using the new password.
If a secondary realm server generates new TLS data files, you need not redistribute its trust file.