When a client initiates TLS negotiation with the server, the server presents a certificate chain to the client, and the certificate at the head of the chain functions as a listener certificate. Because the client decides whether to trust the certificate chain, we recommend that the chain be signed by an issuer whom the client is likely to trust, or that the client can be easily configured to trust.

Although you can create self-signed certificates with long lifespans, a certificate that a certification authority signs is likely to have a relatively short lifespan. Commercial authorities typically issue certificates that are valid for only one or two years, and some authorities use considerably shorter validity windows. For example, the nonprofit Let's Encrypt service, which obtains trusted certificates free of charge as long as you can prove that you control the relevant domains, issues certificates that are valid for up to three months only.

Short certificate lifespans might prove inconvenient for administrators who need to replace them, but they offer some security benefits. In particular, because most clients do not verify whether a certificate has been revoked, a relatively short validity window minimizes the timeframe during which a compromised certificate can be used. If the process for replacing certificates is streamlined or automated, the inconvenience can be kept to a minimum.

Listener certificates are stored in keystores that are referenced by key manager providers, which in turn provide the logic and configuration needed to access the key stores. If a server component like a connection handler requires access to a certificate that it presents to a peer during the TLS-negotiation process, that component must reference the key manager provider that points to the keystore containing the appropriate certificate. If the keystore contains multiple certificates, and if the component that references the keystore includes a property that specifies the certificate's nickname, the certificate with the alias is selected. Otherwise, the server lets the JVM select a certificate, and the one that it chooses might not be well-defined.

The server also provides trust manager providers, which determine whether to trust the certificate chains with which it is presented. A trust manager provider can reference a specified truststore file, but other options include the JVM-default truststore, which uses the Java installation's default set of trusted issuers, and the blind trust manager provider, which automatically trusts every certificate chain that is presented to it.

Note: Never use a blind trust manager in a production environment because it leaves the server vulnerable to impersonation and man-in-the-middle attacks. However, a blind trust manager can be convenient in test environments when troubleshooting certain types of problems.