2020-01-17 13:18:54 +00:00
[[_setting_up_ssl]]
2016-04-28 20:34:44 +00:00
=== Setting up HTTPS/SSL
2017-08-28 12:50:14 +00:00
WARNING: {project_name} is not set up by default to handle SSL/HTTPS.
It is highly recommended that you either enable SSL on the {project_name} server itself or on a reverse proxy in front of the {project_name} server.
2016-04-28 20:34:44 +00:00
2017-08-28 12:50:14 +00:00
This default behavior is defined by the SSL/HTTPS mode of each {project_name} realm. This is discussed in more detail in the
link:{adminguide_link}[{adminguide_name}], but let's give some context and a brief overview of these modes.
2016-04-28 20:34:44 +00:00
2016-06-03 13:56:47 +00:00
external requests::
2020-03-30 19:13:34 +00:00
{project_name} can run out of the box without SSL so long as you stick to private IP addresses like `localhost`, `127.0.0.1`, `10.x.x.x`, `192.168.x.x`, and `172.16.x.x`.
2019-04-25 11:56:21 +00:00
If you don't have SSL/HTTPS configured on the server or you try to access {project_name} over HTTP from a non-private IP adress you will get an error.
2016-04-28 20:34:44 +00:00
none::
2017-08-28 12:50:14 +00:00
{project_name} does not require SSL. This should really only be used in development when you are playing around with things.
2016-04-28 20:34:44 +00:00
2016-06-03 13:56:47 +00:00
all requests::
2017-08-28 12:50:14 +00:00
{project_name} requires SSL for all IP addresses.
2016-04-28 20:34:44 +00:00
2017-08-28 12:50:14 +00:00
The SSL mode for each realm can be configured in the {project_name} admin console.
2016-04-29 20:12:12 +00:00
2021-11-10 11:39:43 +00:00
==== Enabling SSL/HTTPS for the {project_name} server
2016-04-28 20:34:44 +00:00
2016-04-29 20:12:12 +00:00
If you are not using a reverse proxy or load balancer to handle HTTPS traffic for you, you'll need to enable HTTPS
2017-08-28 12:50:14 +00:00
for the {project_name} server. This involves
2016-04-28 20:34:44 +00:00
. Obtaining or generating a keystore that contains the private key and certificate for SSL/HTTP traffic
2017-08-28 12:50:14 +00:00
. Configuring the {project_name} server to use this keypair and certificate.
2016-04-28 20:34:44 +00:00
===== Creating the Certificate and Java Keystore
2021-11-10 11:39:43 +00:00
In order to allow HTTPS connections, you need to obtain a self signed or third-party signed certificate and import it into a Java keystore before you can enable HTTPS in the web container where you are deploying the {project_name} Server.
2016-04-28 20:34:44 +00:00
====== Self Signed Certificate
2017-08-28 12:50:14 +00:00
In development, you will probably not have a third party signed certificate available to test a {project_name} deployment so you'll need to generate a self-signed one
2016-04-29 20:12:12 +00:00
using the `keytool` utility that comes with the Java JDK.
2016-04-28 20:34:44 +00:00
[source]
----
$ keytool -genkey -alias localhost -keyalg RSA -keystore keycloak.jks -validity 10950
Enter keystore password: secret
Re-enter new password: secret
What is your first and last name?
[Unknown]: localhost
What is the name of your organizational unit?
[Unknown]: Keycloak
What is the name of your organization?
[Unknown]: Red Hat
What is the name of your City or Locality?
[Unknown]: Westford
What is the name of your State or Province?
[Unknown]: MA
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=localhost, OU=Keycloak, O=Test, L=Westford, ST=MA, C=US correct?
[no]: yes
----
2021-11-10 11:39:43 +00:00
When you see the question `What is your first and last name ?`, supply the DNS name of the machine where you are installing the server. For testing purposes, `localhost` should be used.
2016-04-28 20:34:44 +00:00
After executing this command, the `keycloak.jks` file will be generated in the same directory as you executed the `keytool` command in.
2021-11-10 11:39:43 +00:00
If you want a third-party signed certificate, but don't have one, you can obtain one for free at http://www.cacert.org[cacert.org]. However, you first need to use the following procedure.
2016-04-28 20:34:44 +00:00
2021-11-10 11:39:43 +00:00
.Procedure
2016-04-28 20:34:44 +00:00
2021-11-10 11:39:43 +00:00
. Generate a Certificate Request:
+
2016-04-28 20:34:44 +00:00
[source]
----
$ keytool -certreq -alias yourdomain -keystore keycloak.jks > keycloak.careq
----
2021-11-10 11:39:43 +00:00
+
Where `yourdomain` is a DNS name for which this certificate is generated.
2016-04-28 20:34:44 +00:00
Keytool generates the request:
2021-11-10 11:39:43 +00:00
+
2016-04-28 20:34:44 +00:00
[source]
----
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIC2jCCAcICAQAwZTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1BMREwDwYDVQQHEwhXZXN0Zm9y
ZDEQMA4GA1UEChMHUmVkIEhhdDEQMA4GA1UECxMHUmVkIEhhdDESMBAGA1UEAxMJbG9jYWxob3N0
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr7kck2TaavlEOGbcpi9c0rncY4HhdzmY
Ax2nZfq1eZEaIPqI5aTxwQZzzLDK9qbeAd8Ji79HzSqnRDxNYaZu7mAYhFKHgixsolE3o5Yfzbw1
2016-04-29 20:12:12 +00:00
29RvyeUVe+WZxv5oo9wolVVpdSINIMEL2LaFhtX/c1dqiqYVpfnvFshZQaIg2nL8juzZcBjj4as
2016-04-28 20:34:44 +00:00
H98gIS7khql/dkZKsw9NLvyxgJvp7PaXurX29fNf3ihG+oFrL22oFyV54BWWxXCKU/GPn61EGZGw
Ft2qSIGLdctpMD1aJR2bcnlhEjZKDksjQZoQ5YMXaAGkcYkG6QkgrocDE2YXDbi7GIdf9MegVJ35
2DQMpwIDAQABoDAwLgYJKoZIhvcNAQkOMSEwHzAdBgNVHQ4EFgQUQwlZJBA+fjiDdiVzaO9vrE/i
n2swDQYJKoZIhvcNAQELBQADggEBAC5FRvMkhal3q86tHPBYWBuTtmcSjs4qUm6V6f63frhveWHf
PzRrI1xH272XUIeBk0gtzWo0nNZnf0mMCtUBbHhhDcG82xolikfqibZijoQZCiGiedVjHJFtniDQ
9bMDUOXEMQ7gHZg5q6mJfNG9MbMpQaUVEEFvfGEQQxbiFK7hRWU8S23/d80e8nExgQxdJWJ6vd0X
MzzFK6j4Dj55bJVuM7GFmfdNC52pNOD5vYe47Aqh8oajHX9XTycVtPXl45rrWAH33ftbrS8SrZ2S
vqIFQeuLL3BaHwpl3t7j2lMWcK1p80laAxEASib/fAwrRHpLHBXRcq6uALUOZl4Alt8=
-----END NEW CERTIFICATE REQUEST-----
----
2021-11-10 11:39:43 +00:00
. Send this CA request to your Certificate Authority (CA).
+
2016-04-28 20:34:44 +00:00
The CA will issue you a signed certificate and send it to you.
2021-11-10 11:39:43 +00:00
. Obtain and import the root certificate of the CA.
+
You can download the cert from CA (in other words: root.crt) and import as follows:
+
2016-04-28 20:34:44 +00:00
[source]
----
$ keytool -import -keystore keycloak.jks -file root.crt -alias root
----
2021-11-10 11:39:43 +00:00
. Import your new CA generated certificate to your keystore:
+
2016-04-28 20:34:44 +00:00
[source]
----
$ keytool -import -alias yourdomain -keystore keycloak.jks -file your-certificate.cer
----
2017-08-28 12:50:14 +00:00
===== Configure {project_name} to Use the Keystore
2016-04-28 20:34:44 +00:00
2017-08-28 12:50:14 +00:00
Now that you have a Java keystore with the appropriate certificates, you need to configure your {project_name} installation to use it.
2016-04-28 20:34:44 +00:00
2021-11-10 11:39:43 +00:00
.Procedure
2018-11-26 17:40:08 +00:00
2021-11-10 11:39:43 +00:00
. Edit the _standalone.xml_, _standalone-ha.xml_, or _host.xml_ file to use the keystore and enable HTTPS.
. Either move the keystore file to the _configuration/_ directory of your deployment or the file in a location you choose and provide an absolute path to it.
+
If you are using absolute paths, remove the optional `relative-to` parameter from your configuration (See <<_operating-mode, operating mode>>).
2018-11-26 17:40:08 +00:00
2021-12-16 15:40:06 +00:00
. Configure the keystore using the CLI:
2021-11-10 11:39:43 +00:00
+
[source]
2018-11-26 17:40:08 +00:00
----
2021-12-16 15:40:06 +00:00
$ /subsystem=elytron/key-store=httpsKS:add(relative-to=jboss.server.config.dir,path=keycloak.jks,credential-reference={clear-text=secret},type=JKS)
$ /subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,credential-reference={clear-text=secret})
$ /subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM,protocols=[\"TLSv1.3\"])
2018-11-26 17:40:08 +00:00
----
2021-11-10 11:39:43 +00:00
+
If using domain mode, the commands should be executed in every host using the `/host=<host_name>/` prefix (in order to create the `security-realm` in all of them). Here is an example, which you would repeat for each host:
+
2018-11-26 17:40:08 +00:00
[source]
----
2021-12-16 15:40:06 +00:00
$ /host=<host_name>/subsystem=elytron/key-store=httpsKS:add(relative-to=jboss.server.config.dir,path=keycloak.jks,credential-reference={clear-text=secret},type=JKS)
2018-11-26 17:40:08 +00:00
----
2021-11-10 11:39:43 +00:00
+
2021-12-16 15:40:06 +00:00
. Modify the `https-listener` to use the `server-ssl-context`previously created:
2021-11-10 11:39:43 +00:00
+
2018-11-26 17:40:08 +00:00
[source]
----
2021-12-16 15:40:06 +00:00
$ /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=httpsSSC)
2018-11-26 17:40:08 +00:00
----
2021-11-10 11:39:43 +00:00
+
2018-11-26 17:40:08 +00:00
If using domain mode, prefix the command with the profile that is being used with: `/profile=<profile_name>/`.
2021-11-10 11:39:43 +00:00
+
2018-11-26 17:40:08 +00:00
The resulting element, `server name="default-server"`, which is a child element of `subsystem xmlns="{subsystem_undertow_xml_urn}"`, should contain the following stanza:
2021-11-10 11:39:43 +00:00
+
2017-03-30 07:49:38 +00:00
[source,xml,subs="attributes+"]
2016-04-28 20:34:44 +00:00
----
2017-08-28 12:50:14 +00:00
<subsystem xmlns="{subsystem_undertow_xml_urn}">
2016-04-28 20:34:44 +00:00
<buffer-cache name="default"/>
<server name="default-server">
2021-12-16 15:40:06 +00:00
<https-listener name="https" socket-binding="https" ssl-context="httpsSSC"/>
2016-04-28 20:34:44 +00:00
...
</subsystem>
----
2018-11-26 17:40:08 +00:00
2021-12-17 09:06:20 +00:00
For more information on configuring TLS refer to the https://docs.wildfly.org/25/WildFly_Elytron_Security.html#configure-ssltls[WildFly documentation].
2018-11-26 17:40:08 +00:00