Keycloak hostname Letsencrypt challenge fails after update

After updating the Keycloak app to 8.2. 21.1.2-ucs2 the Letsencrypt certificate could not be updated any more. In the changelog it says:

If the Keycloak hostname is accessed using http, you are now directly redirected to https

But the Letsencrypt app needs http for the challenge. So I just removed the new <VirtualHost *:80> block from /etc/apache2/sites-available/univention-keycloak.conf and reloaded Apache. Then sudo -u letsencrypt /usr/share/univention-letsencrypt/refresh-cert succeeded.

I would prefer a proper permanent solution. Thanks!

This problem still exists. Am I the only one with this problem?

Moin and thanks for bringing this up! I created a bug report for this problem, we will update that accordingly: Bug 56825 – Let's encrypt challenge fails for Keycloak domain because of HTTPS redirect


1 Like

Sorry for the late reply,

how sure are we that this is a problem with the http->https redirect, i just tried it on my test machine and i worked:

$ more /etc/apache2/sites-enabled/univention-keycloak.conf
<VirtualHost *:80>
   ServerName auth-test...
   Redirect permanent / https://auth-test...
$ curl http://auth-test...
<title>301 Moved Permanently</title>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://auth-test...">here</a>.</p>
<address>Apache/2.4.38 (Univention) Server at auth-test... Port 80</address>
$ sudo -u letsencrypt /usr/share/univention-letsencrypt/refresh-cert 
+ DIR_LE=/etc/univention/letsencrypt
++ id -un
+ '[' '!' letsencrypt = letsencrypt ']'
+ trap cleanup EXIT
++ mktemp --tmpdir=/etc/univention/letsencrypt
+ TMPFN=/etc/univention/letsencrypt/tmp.QICJFP7Vku
+ date
Do 15. Feb 14:37:29 CET 2024
+ echo 'Refreshing certificate for following domains:'
Refreshing certificate for following domains:
+ cat /etc/univention/letsencrypt/domains
auth-test... portal-test...
+ is_ucr_true letsencrypt/staging
+ local value
++ /usr/sbin/univention-config-registry get letsencrypt/staging
+ value=
+ case "$(echo -n "$value" | tr '[:upper:]' '[:lower:]')" in
++ echo -n ''
++ tr '[:upper:]' '[:lower:]'
+ return 2
+ /usr/share/univention-letsencrypt/ --disable-check --account-key /etc/univention/letsencrypt/account.key --csr /etc/univention/letsencrypt/domain.csr --acme-dir /var/www/.well-known/acme-challenge/
Parsing account key...
Parsing CSR...
Found domains: auth-test..., portal-test...
Getting directory...
Directory found!
Registering account...
Already registered!
Creating new order...
Order created!
Verifying auth-test......
auth-test... verified!
Verifying portal-test...
portal-test... verified!
Signing certificate...
Certificate signed!
+ is_ucr_true letsencrypt/staging
+ local value
++ /usr/sbin/univention-config-registry get letsencrypt/staging
+ value=
+ case "$(echo -n "$value" | tr '[:upper:]' '[:lower:]')" in
++ echo -n ''
++ tr '[:upper:]' '[:lower:]'
+ return 2
+ mv -f /etc/univention/letsencrypt/tmp.QICJFP7Vku /etc/univention/letsencrypt/signed_chain.crt
+ chmod 0644 /etc/univention/letsencrypt/signed_chain.crt
++ date +%Y%m%d-%H%M%S
+ cp /etc/univention/letsencrypt/signed_chain.crt /etc/univention/letsencrypt/signed_chain.crt_20240215-143739
++ date
+ echo 'Certificate refreshed at Do 15. Feb 14:37:39 CET 2024'
Certificate refreshed at Do 15. Feb 14:37:39 CET 2024


Strange, I just tested it again and now it seems to work for me too without removing the <VirtualHost *:80> block.

Great, thanks for the test, i will close the bug, but feel free to re-open if the problem appears again.

Best regards,

I had this problem again and fixed it now more permanently by adding

RewriteEngine on
RewriteCond %{HTTP_HOST} ^$
RewriteCond %{REQUEST_URI} ^/.well-known/(.*)$
RewriteRule ^/.well-known/(.*)$ %{REQUEST_SCHEME}://$1 [L,QSA,R=301,END]

to /var/lib/univention-appcenter/apps/keycloak/data/local-univention-keycloak.conf.