Listener certificates are those that are used to secure communication through TLS.
Whenever a client initiates TLS negotiation with the server, it presents a certificate chain to the client, and the certificate at the head of that chain will be a listener certificate. The client must decide whether to trust the certificate chain, so it is beneficial to ensure that it is signed by an issuer that the client is likely to trust or at least, that the client can be easily configured to trust.
While you can create self-signed certificates with very long life spans, any certificate that you have signed by a certification authority is likely to have a relatively short life span. Commercial authorities are only likely to issue certificates that are valid for up to one or two years, and some use much shorter validity windows. For example, the nonprofit Let’s Encrypt service, which can be used to obtain trusted certificates for free as long as you can prove that you control the domains for which they are to be issued, only issues certificates that are valid for up to three months.
While short certificate life spans can be inconvenient for administrators who need to replace them, they do offer some security benefits. In particular, because most clients don’t make any attempt to check whether a certificate has been revoked, a relatively short validity window minimizes the time that a compromised certificate can be used. And if the process for replacing certificates is automated or least streamlined, then the inconvenience can be kept to a minimum.
Listener certificates are stored in key stores, and those key stores are referenced by key manager providers, which provide the logic and configuration needed to access the key stores. If a server component, for example, a connection handler, needs to have access to a certificate that it presents to a peer during the TLS negotiation process, then that component should reference the key manager provider that points to the key store containing the desired certificate. If the key store has more than one certificate, and if the component referencing it includes a property that specifies the nickname of the certificate to use, then the certificate with that alias is selected. Otherwise, the server leaves it up to the JVM to select a certificate, and which one it chooses is not well defined.
The server also provides trust manager providers that can determine whether to trust any presented certificate chains. A trust manager provider can reference a specified trust store file, but other options include the JVM-default trust store which uses the Java installation’s default set of trusted issuers and the blind trust manager provider which blindly trusts any certificate chain that is presented to it. Do not use the blind trust manager in a production environment because it leaves the server vulnerable to impersonation and interception attacks, but it can be convenient in test environments to troubleshoot certain types of problems.