single sign-on – Red Hat Developer BlogInsights and news on Red Hat Developer tools, platforms and more
2019-05-25T07:00:26Z https://developers.redhat.com/blog/feed/atom/WordPressNicolas Masséhttps://github.com/nmasse-itixhttps://developers.redhat.com/blog/?p=5578972019-03-19T17:15:28Z2019-02-06T13:00:56ZWhen deploying Red Hat Single Sign-On/Keycloak for a test or a proof of concept, most users will choose to use a self-signed certificate as explained in the official documentation. The setup instructions are straightforward, but this self-signed certificate will trigger certificate error messages in your web browser and can also prevent some clients such as Postman […]

The setup instructions are straightforward, but this self-signed certificate will trigger certificate error messages in your web browser and can also prevent some clients such as Postman from working properly.

This article explains how to use a public certificate from Let’s Encrypt with Red Hat Single Sign-On.

Are you using a public certificate?

A simple and effective way to know if you are using a public certificate is to use curl.

$ curl https://sso.example.test/auth/realms/master
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.

If you get this output from curl, you are using a self-signed certificate that will cause you headaches later.

Continue reading to learn how to fix this!

Instructions

During the rest of this article, we will focus on a Red Hat Single Sign-On 7.2 installation on OpenShift.

I assume Red Hat Single Sign-On has been installed, as explained in the official documentation using one of the “sso72-x509-*” templates.

First, move to the project in which you installed Red Hat Single Sign-On:

$ oc project sso

We will retrieve a public certificate using Let’s Encrypt as a certificate authority, and Lego is a client that can speak with Let’s Encrypt. It has several advantages such as ease of use and it’s packaged as a container image.

To get a public certificate for your Red Hat Single Sign-On instance, we need to find the hostname of that instance. The hostname is a property of the OpenShift route that has been created as part of the Red Hat Single Sign-On installation.

Query the hostname of your Red Hat Single Sign-On route and save it for later use:

$ hostname=$(oc get route sso -o jsonpath='{.spec.host}')

This route to your Red Hat Single Sign-On instance needs to be replaced by a temporary route to Lego so that Let’s Encrypt can perform the HTTP challenge. The easiest way to do this is to delete your existing route and create a new one with the same hostname:

Confirm that your Red Hat Single Sign-On instance is now using a public certificate by running again the curl command:

$ curl https://$hostname/auth/realms/master

Lego does not need to run continuously, so between certificate renewals (every 90 days), you can scale it down:

$ oc scale dc/lego --replicas=0

Conclusion

Self-signed certificates are always a headache when delivering a proof of concept or a workshop. This article presented a very practical way to get a valid public certificate for your Red Hat Single Sign-On instance.

Some aspects would need improvements to be used for longer periods or in production environments. For instance, we would need to use the proper Kubernetes concepts, Job and Cron to run Lego, handle the certificate renewal, and use the DNS validation challenge (which requires a more complex setup but does not involve deleting the sso route).

Also, this article is about getting public certificates for your Red Hat Single Sign-On instance that is publicly deployed on the Internet. If your instance is deployed on your laptop for development purposes, the mkcertproject can help you generate proper certificates and make them trusted in your web browser.

Nevertheless, I hope this article will give you ideas and entice you to use public certificates for your Red Hat Single Sign-On setups.