Open topic with navigation

TIBCO Rendezvous® 8.8.0

# Security Factors

## Store Files

Important | The secure daemon store file contains very sensitive information. Store it on the local file system of the secure daemon’s host computer, with tight file access, in a physically secure environment. Ensure timely backup to secure media.

## Core-Dump Files

Important | Secure daemon process storage contains sensitive information in unencrypted form. Similarly, user program storage can contain passwords or private key data. It is essential to deny access to these processes and their core image files. We strongly recommend arranging operating system parameters to prevent creation of core files. To guard against attacks, take these precautions:
| • | Configure the operating environment to avoid making core dumps.
| • | Configure the operating environment to prevent access to process memory (if possible).
| • | Ensure that file system storage is secure.

## Daemon Certificates

Important | Administrators must implement a secure mechanism to distribute the secure daemon’s public certificate to users (that is, either programmers of client programs or end users). Ensure that users verify daemon certificates before using them with client programs. Ensure that users keep daemon certificates in files that are secure from unauthorized modification or tampering. Remember, a false certificate can give a rogue daemon access to user passwords.

## CA-Signed Certificates

Rendezvous does not support separating a leaf certificate from its signing CA certificate. When arranging certificate data, you may supply either a self-signed certificate, or a complete certificate trust chain, including leaf, intermediate (which are optional), and root certificates—all in one certificate data file. In either case, the entire certificate chain is contained in one package, and Rendezvous components verify trust by comparing the entire package.

To better understand the way in which Rendezvous uses certificates and certificate trust chains, compare it to the familiar model of web browser security.

In the familiar model, web browsers generally store a set of certificates representing trusted certificate authorities (CAs), and use them to deduce the authenticity of many certificates—any certificate signed using one of those trusted CA certificates.

In contrast, to authenticate a user (or another daemon), Rendezvous secure daemons require that a client-supplied certificate must exactly match a trusted certificate previously stored with the daemon. Daemons use certificates to verify digital signatures and message integrity, but they do not use CA certificates to authenticate client certificates. Similarly, Rendezvous clients verify certificates from Rendezvous daemons by matching them against trusted certificates previously registered with the client program.

If you require CA-signed certificates, or if your organization already uses CA-signed certificates, you may use them by packaging each one together with its CA root certificate and intermediate certificates—a complete trust chain for each certificate. You can use standard certificate utilities to create certificate files in the appropriate encoding formats.

## Level of Trust—CA-Signed versus Self-Signed Certificates

When client connects to a daemon, both forms of certificate (CA-signed and self-signed) represent equivalent levels of trust.

| • | The daemon accepts the client’s certificate only if the daemon is configured to accept that certificate as the identity of a valid user, or as the identity of another trusted daemon.

| • | The client accepts the daemon’s certificate only if the client has previously registered that certificate as the identity of a trusted daemon.

In these situations, self-signed certificates can be more convenient than CA-signed certificates, with no degradation in security.

However, when a browser connects to a daemon’s browser administration interface, CA-signed daemon certificate chains do represent a stronger level of trust than self-signed daemon certificates. Furthermore, using CA-signed daemon certificates can help avoid browser security warnings.

## Passwords

Important | Private key files use password-encryption for security. Nonetheless, these files are important points of vulnerability. To guard against attacks, ensure that file system storage is secure, and keep all passwords secure.
| • | Do not store passwords in non-secure files or on non-secure file systems.
| • | Control access to sensitive files—even when those files are password-encrypted.
| • | Never hard-code passwords in application programs, nor accept them as command line parameters.
| • | Code programs to erase passwords from process storage before exiting.
| • | Never write passwords in convenient locations.
| • | Never send passwords in plaintext messages.
| • | Choose passwords carefully.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO Rendezvous®

Copyright © 1997-2025. Cloud Software Group, Inc. All Rights Reserved.