[id='configuring-server-keystores_{context}']
= Configuring {brandname} Server keystores
Add keystores to {brandname} Server and configure it to present SSL/TLS certificates that verify its identity to clients.
If a security realm contains TLS/SSL identities, it encrypts any connections to {brandname} Server endpoints that use that security realm.

.Prerequisites

* Create a keystore that contains certificates, or certificate chains, for {brandname} Server.

{brandname} Server supports the following keystore formats: JKS, JCEKS, PKCS12/PFX and PEM.
BKS, BCFKS, and UBER are also supported if the https://www.bouncycastle.org/[Bouncy Castle] library is present.

Certificates should include the `subjectAltName` extension of type `dNSName` and/or `iPAddress` so that clients can correctly perform
hostname validation, according to the rules defined by the https://datatracker.ietf.org/doc/html/rfc2818[RFC 2818] specification.
The server will issue a warning if it is started with a certificate which does not include such an extension.

[IMPORTANT]
====
In production environments, server certificates should be signed by a trusted Certificate Authority, either Root or Intermediate CA.
====

[TIP]
====
You can use PEM files as keystores if they contain both of the following:

* A private key in PKCS#1 or PKCS#8 format.
* One or more certificates.

You should also configure PEM file keystores with an empty password (`password=""`).
====

.Procedure

. Open your {brandname} Server configuration for editing.
. Add the keystore that contains SSL/TLS identities for {brandname} Server to the `{server_home}/server/conf` directory.
. Add a `server-identities` definition to the {brandname} Server security realm.
. Specify the keystore file name with the `path` attribute.
. Provide the keystore password and certificate alias with the `keystore-password` and `alias` attributes.
. Save the changes to your configuration.

.Next steps

Configure clients with a trust store so they can verify SSL/TLS identities for {brandname} Server.

[discrete]
== Keystore configuration

.XML
[source,xml,options="nowrap",subs=attributes+]
----
include::xml/server_ssl_identity_truststore.xml[]
----

.JSON
[source,json,options="nowrap",subs=attributes+]
----
include::json/server_ssl_identity_truststore.json[]
----

.YAML
[source,yaml,options="nowrap",subs=attributes+]
----
include::yaml/server_ssl_identity_truststore.yaml[]
----

== SSL/TLS Certificate rotation

SSL/TLS certificates have an expiration date, after which they will no longer be valid.
The process of renewing a certificate is also known as *rotation*.
{brandname} monitors the keystore files for changes and automatically reloads them without requiring a server or client
restart.

NOTE: to ensure seamless operations during certificate rotation, use certificates signed by a Certificate Authority and
configure both server and client trust stores with the CA certificate. The use of self-signed certificates will cause
temporary handshake failures until all clients and servers have been updated.

[role="_additional-resources"]
.Additional resources
* link:{hotrod_docs}#configuring-hotrod-encryption_hotrod-client-configuration[Configuring Hot Rod client encryption]
