Understanding keystores, truststores, and certificates

Keystores and truststores are secure files that store keys and certificates that are used for SSL authentication, encryption, decryption, and digital signing and verification. Learn how to work with keystores, truststores, and certificates in webMethods Integration.

Keystores and truststores are secure files with industry-standard file formats. These files provide added layers of security and easier management than storing keys and certificates separately. You can store private keys and SSL certificates in keystore files. Truststore files store trusted root certificates (public keys of certificate authorities).

Note:
  • If you have read-only permission, then you cannot view certificates in the project. Only administrators have access to these keystore and truststore files.
  • The JKS file format certificates are not supported in the Federal Information Processing Standards (FIPS) mode environments.
File location and access
Keystores and truststores files exist in your operating system’s file system. You must store them in a secure directory because they are critical for secure communication. If the system cannot find these files, authentication fails and the server cannot connect.
Usage in HTTPS communication
When your server sends HTTPS requests, it acts as a client and receives certificates from external resources. To complete these transactions, your server must have the public keys and CA certificates of those resources.
Aliases for management
To identify a particular keystore or truststore file, or private key within a keystore, webMethods Integration uses aliases. The use of aliases simplifies keystore and truststore management because you do not need to enter the path information when you specify a keystore, truststore, or the private key.
SSL authentication requirements
For a webMethods Integration component to be SSL authenticated, it must have a valid, authorized X.509 certificate that is installed in a keystore file. The private key and signing certificate for the certificate issuer (CA) in a truststore is also required for SSL authentication.

A truststore can contain multiple trusted root certificates (public keys for the signing CAs), which can support several keystores. A keystore file can contain the key pairs for multiple webMethods Integration components, and the entire certificate chain necessary for a component's authentication. With a certificate chain, it is necessary to validate each subsequent signature in the list until a trusted CA certificate is reached. For webMethods Integration, you must include the entire chain of certificates in a keystore and truststore. Also, any root CA certificates in use by clients must be in the webMethods Integration truststore.

Extended Key Usage (EKU) attribute requirements

Digital certificates specify their allowed uses through EKU attributes. The two relevant EKUs are as follows:

  • Server Authentication is required for all standard TLS connections, for example, browsing HTTPS websites.
  • Client Authentication is required when a client must present its own certificate, such as in mutual TLS (mTLS).

A certificate might include only Server Authentication, only Client Authentication, both, or neither. If publicly issued certificates include only the Server Authentication EKU attribute by default, they cannot be used for mTLS. Existing certificates continue to function until they expire.

When you configure mTLS connection accounts, you must use certificates that explicitly include the Client Authentication EKU attribute. If this attribute is missing, the connection might result in authentication failures, unsuccessful mTLS handshakes, or service disruptions, depending on the endpoint server’s EKU requirements.

CAUTION:

Before you upload the certificate, validate it by using OCSP or a similar method to help ensure that it is not revoked. Uploading a revoked or invalid certificate can compromise the security and integrity of your environment. This step is crucial to align with security best practices and to protect your deployment from potential vulnerabilities.

You can manage keystore and truststore aliases from the Certificates page and use them to secure your accounts.