[keycloak-user] setting up TLS(SSL) through the X509_CA_BUNDLE environment variable

Meissa M'baye Sakho msakho at redhat.com
Tue Nov 13 03:54:01 EST 2018


Sebastian,
I'm already working for the short term solution.
 I will create a JIRA and let you know when everything is ok.
@Pedro Igor Silva <psilva at redhat.com>  for the wildfly solution, I've
opened a thread in the wildfly forum [0]. No one answered ATM.
I think that it's a feature between wildfly and keycloak. We should be able
to reference a truststore while defining a keycloak SPI [1] with keycloak
4.5 that rely on wildfly 13.
This feature is missing.
 [0] =https://developer.jboss.org/message/986328#986328
 [1]=
https://www.keycloak.org/docs/latest/server_installation/index.html#_truststore
What do you think about that?

thanks,
Meissa


Le mar. 13 nov. 2018 à 09:37, Sebastian Laskawiec <slaskawi at redhat.com> a
écrit :

> So the variable you're pointing out is local to the script. Having said
> that, you have no access to it from the outside.
>
> I think the proper solution would be to modify Keycloak codebase
> (especially Keycloak subsystem) and integrate it with Elytron. Probably +Pedro
> Igor Silva <psilva at redhat.com> would be the best person to ask about that.
>
> As for the short-term solution, I guess introducing two optional
> environmental variables for storing Keystore and Truststore passwords would
> be enough. If those variables were empty, we would generate a new password.
> If not, we'd use it for generating JKS files.
>
> Unfortunately adding this feature is not currently on our priority list.
> Therefore, I highly encourage you to contribute it. If you plan to do so,
> please remember about creating a JIRA for it. I will be more than happy to
> review the code once you have something ready.
>
> Thanks,
> Sebastian
>
> On Tue, Nov 13, 2018 at 9:14 AM Meissa M'baye Sakho <msakho at redhat.com>
> wrote:
>
>> Hello Sebastien,
>> Any advice?
>> I really need to access trustore password initilized loccally from the
>> x509.sh script. (extrcat below)
>> local PASSWORD=$(openssl rand -base64 32 2>/dev/null)
>> local JKS_KEYSTORE_FILE="${KEYSTORE_TYPE}-keystore.jks
>>
>> I'm stuck otherwise.
>> How can I get access to it?
>> Meissa
>>
>> Le lun. 12 nov. 2018 à 10:24, Meissa M'baye Sakho <msakho at redhat.com> a
>> écrit :
>>
>>> Hi Sebastian,
>>> That's correct. I can see that my the truststore is created correctly
>>> with my CA certificates.
>>> I need now to configure the OutGoing HTTPS Request Truststore [3] with
>>> the created truststore and the password.
>>> The problem is that I can't set the password. I've checked into the
>>> x509-truststore.cli [1] and see that it's picked from the
>>> $keycloak_tls_truststore_password variable.
>>> and created from your x509.sh script [2]
>>> I've tried to use the same syntax in my cli below but it fails because
>>> the $keycloak_tls_truststore_password is not know from my cli.
>>> So Sebastien, do you know how I can get the trsustore password?
>>> Is it possible to set it as an environment variable to the docker image?
>>>
>>>
>>> [1]=
>>> https://raw.githubusercontent.com/jboss-dockerfiles/keycloak/master/server/tools/cli/x509-truststore.cli
>>> [2]=
>>> https://raw.githubusercontent.com/jboss-dockerfiles/keycloak/master/server/tools/x509.sh
>>> [3]=
>>> https://www.keycloak.org/docs/latest/server_installation/index.html#_truststore
>>> Thanks,
>>> Meissa
>>>
>>>
>>> Le mer. 31 oct. 2018 à 09:08, Sebastian Laskawiec <slaskawi at redhat.com>
>>> a écrit :
>>>
>>>> Hey Meissa,
>>>>
>>>> The warning you see does no harm. As you can see here [1], the message
>>>> is being thrown without stopping the script.
>>>>
>>>> Pulling JDK CAs has been implemented somewhat ahead of time. I asked
>>>> the Cloud Enablement (and also other Red Hat teams) to put Kubernetes and
>>>> OpenShift CAs into JDK lib directory. This way Keycloak will trust the
>>>> OpenShift cluster out of the box. The warning you see clearly indicates
>>>> that this feature hasn't been implemented yet.
>>>>
>>>> So the bottom line - please ignore this error. I'm pretty sure it will
>>>> disappear in the future (and if not, I'll just remove or disable this
>>>> feature).
>>>>
>>>> Thanks,
>>>> Sebastian
>>>>
>>>> [1]
>>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/tools/x509.sh#L88
>>>>
>>>> On Wed, Oct 31, 2018 at 8:59 AM Meissa M'baye Sakho <msakho at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Sebastian,
>>>>> Do you have any advice in this issue. It's related to the x509.sh
>>>>> script and I would really apprecaite an input/help here.
>>>>> Meissa
>>>>> ---------- Forwarded message ---------
>>>>> From: Meissa M'baye Sakho <msakho at redhat.com>
>>>>> Date: mar. 30 oct. 2018 à 17:12
>>>>> Subject: setting up TLS(SSL) through the X509_CA_BUNDLE environment
>>>>> variable
>>>>> To: keycloak-user <keycloak-user at lists.jboss.org>
>>>>>
>>>>>
>>>>> hello everyone,
>>>>> I'm using the jboss/keycloak:4.5.0.Final docker image.
>>>>> I'm trying to setup Mutual TLS by using the X509_CA_BUNDLE environment
>>>>> variable as explained in the Jboss/keycloak docker image documentation.
>>>>> I've mounted a volume to the image pointing to the cert file and
>>>>> defined the env variable.
>>>>> I'm running the image with the following command:
>>>>>  *docker run -d --name opengie -e KEYCLOAK_USER=meissa -e
>>>>> KEYCLOAK_PASSWORD=meissa \*
>>>>> *  -e PROXY_ADDRESS_FORWARDING=true \*
>>>>> *  -v
>>>>> /home/centos/docker-opengie/docker-image/staging:/var/run/secrets \*
>>>>> *  -v
>>>>> /home/centos/docker-opengie/docker-image/staging/jks:/etc/x509/https \*
>>>>> *  -e JGROUPS_DISCOVERY_PROTOCOL=dns.DNS_PING \*
>>>>> *  -e
>>>>> JGROUPS_DISCOVERY_PROPERTIES=dns_query=bdf-opengie-test.paas.eclair.local \*
>>>>> *  -e X509_CA_BUNDLE=/var/run/secrets/bdf-ca.crt \*
>>>>> *  jboss/keycloak:4.5.0.Final*
>>>>>
>>>>>
>>>>> When The container starts, I've checked that the cert has been
>>>>> corectly mounted to the expected folder /var/run/secrets
>>>>> But I see in the log that the certificat import fails (extract below):
>>>>> *Creating HTTPS keystore via OpenShift's service serving x509
>>>>> certificate secrets..*
>>>>> *HTTPS keystore successfully created at:
>>>>> /opt/jboss/keycloak/standalone/configuration/keystores/https-keystore.jks*
>>>>> *Creating Keycloak truststore..*
>>>>> *Keycloak truststore successfully created at:
>>>>> /opt/jboss/keycloak/standalone/configuration/keystores/truststore.jks*
>>>>> *Importing certificates from system's Java CA certificate bundle into
>>>>> Keycloak truststore..*
>>>>> *Failed to import certificates from system's Java CA certificate
>>>>> bundle into Keycloak truststore!*
>>>>> *Setting JGroups discovery to dns.DNS_PING with properties
>>>>> {dns_query=>bdf-opengie-test.paas.eclair.local}*
>>>>>
>>>>> I've checked in the script that handle the TLS import [1], but I'm not
>>>>> able to guess why the import is failing.
>>>>>
>>>>> The following extract is a part of the scripts that is used by the
>>>>> image to import the cert.
>>>>> # Import existing system CA certificates into the newly generated
>>>>> truststore
>>>>> local SYSTEM_CACERTS=$(readlink -e $(dirname $(readlink -e $(which
>>>>> keytool)))"/../lib/security/cacerts")
>>>>> if keytool -v -list -keystore "${SYSTEM_CACERTS}" -storepass
>>>>> "changeit" > /dev/null; then
>>>>> echo "Importing certificates from system's Java CA certificate bundle
>>>>> into Keycloak truststore.."
>>>>> keytool -importkeystore -noprompt \
>>>>> -srckeystore "${SYSTEM_CACERTS}" \
>>>>> -destkeystore "${JKS_TRUSTSTORE_PATH}" \
>>>>> -srcstoretype jks -deststoretype jks \
>>>>> -storepass "${PASSWORD}" -srcstorepass "changeit" >& /dev/null
>>>>> if [ "$?" -ne "0" ]; then
>>>>> echo "Successfully imported certificates from system's Java CA
>>>>> certificate bundle into Keycloak truststore at: ${JKS_TRUSTSTORE_PATH}"
>>>>> else
>>>>>   echo "Failed to import certificates from system's Java CA
>>>>> certificate bundle into Keycloak truststore!"
>>>>> fi
>>>>>
>>>>> Any advice?
>>>>>
>>>>> [1]=
>>>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/tools/x509.sh
>>>>>
>>>>> Meissa
>>>>>
>>>>


More information about the keycloak-user mailing list