UCS SSO and LetsEncrypt

Hi,

I installed the OpenID Connect Provider and Kopano Meet. A quick test worked but unfortunately the browsers complained about the certificate. So I added ucs-sso.our-tld to LetsEncrypt config and changed the entries in the registry

saml/apache2/ssl/certificate: /etc/univention/letsencrypt/signed_chain.crt
saml/apache2/ssl/certificatechain: /etc/univention/letsencrypt/intermediate.pem
saml/apache2/ssl/key: /etc/univention/letsencrypt/domain.key

Unfortunately after a reload of apache the service stopped working and complained about
The requested URL /.well-known/openid-configuration was not found on this server.

So I removed kopano meet and openID connector, deleted my changed registry entries and deleted ucs-sso.our-tld fromt the letsencrypt settings. Now kopano meet seems to run in a loop. Everytime I click the button “Anmelden” at the start page it tries to start but falls back to the start page.

I found other people already had issues when adding ucs-sso to lets encrypt but I could not find a reliable solution for this.

Any ideas?

Andy

Hi @raceface2nd,

the ucs-sso entries look good, I have the following snippet in my deployment scripts to set the sso subdomain up:

univention-app install letsencrypt
ucr set letsencrypt/domains="ucs-123.my-domain.de mattermost.my-domain.de ucs-sso.my-domain.de"
univention-app configure letsencrypt

# set le cert for sso
ucr set \
saml/apache2/ssl/ca saml/apache2/ssl/certificate="/etc/univention/letsencrypt/signed_chain.crt" \
saml/apache2/ssl/certificatechain="/etc/univention/letsencrypt/intermediate.pem" \
saml/apache2/ssl/key="/etc/univention/letsencrypt/domain.key"

To find out why this is happening you need to have a look into the “Developer Tools” in your browser. In the network tab filter for requests including the word “authorize”. One of these requests will have an error state.

hi @fbartels,

after deinstalling the kopano meet and the openID connector, deleting the ucs-sso subdomain from the LE domain list and waiting a while I could reinstall both with the initial used certs.

I can now enter kopano meet again.

Changing the UCR variables to use the LE cert again after adding the sub domain ucs-sso brings me to a
The requested URL /signin/v1/identifier/_/authorize was not found on this server.

Andy

I had a look into /etc/apache2/sso-vhost.conf.d/openid-connect-provider.conf and recognized that I get a 404 error when trying to curl via command line http://localhost:8777/signin/ from the following lines

# Kopano Konnect login area
ProxyPass /signin/ http://localhost:8777/signin/ retry=0
ProxyPassReverse /signin/ http://localhost:8777/signin/

Andy

Is this a 404 page from Apache or just the sentence “404 page not found” on a white page?

The latter is totally fine, because this page actually does not exist within Konnect, the Login page (and the page that is requested by apps) is located at “/signin/v1/identifier”.

If its an Apache error page, then the apache webserver probably needs a restart.

It’s an Apache site. Already made a restart.

grafik

This happens right after adding the ucs-sso sub domain to LE, changing the saml/apache2/ssl/ cert variables and restarting apache.

I can drop the HAR log of the browser if this helps? Did not find any errors in the univention app logs of kopano-meet and openid-connect-provider.

if the error message comes from apache, then it means the vhost is not properly included in the configuration.

This could be something that Univention needs to look into. Does /etc/apache2/sites-enabled/univention-saml.conf exist on your system? (I would guess so, since I do see the simplesamplphp when going to your sso domain)

Yes, the vhost config exists, this is the /etc/apache2/sites-enabled/univention-saml.conf

# Warning: This file is auto-generated and might be overwritten by
#          univention-config-registry.
#          Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-config-registry ueberschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
#
#       /etc/univention/templates/files/etc/apache2/sites-available/univention-saml.conf
#

Alias /simplesamlphp/saml2/idp/certificate /etc/simplesamlphp/ucs-sso.my-domain-idp-certificate.crt
<Directory "/etc/simplesamlphp">
        <Files "ucs-sso.my-domain-idp-certificate.crt">
                Require all granted
        </Files>
</Directory>


Alias /simplesamlphp /usr/share/simplesamlphp/www

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?simplesamlphp/(.*) https://%{SERVER_NAME}/simplesamlphp/$1 [R,L]



<Directory /usr/share/simplesamlphp/www/>
        <FilesMatch ".+\.ph(p[345]?|t|tml)$">
                SetHandler php-cgi
        </FilesMatch>
        Action php-cgi /saml-bin/php-cgi

        Order allow,deny
        Allow from all
</Directory>
<Directory /var/www/saml/>
        Options -Indexes
</Directory>

<IfModule mod_ssl.c>
<VirtualHost *:443>
        IncludeOptional /etc/apache2/sso-vhost.conf.d/*.conf
        SSLEngine on
        SSLProxyEngine on
        ServerName ucs-sso.my-domain
        SSLCertificateFile /etc/univention/letsencrypt/signed_chain.crt
        SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
        SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem
                SSLCertificateChainFile /etc/univention/letsencrypt/intermediate.pem
        DocumentRoot /var/www/
        RedirectMatch ^/$ /simplesamlphp/

        ScriptAlias /saml-bin /var/www/saml
        SuexecUserGroup samlcgi samlcgi

        RewriteEngine on
        RewriteCond %{HTTP:Authorization}  !^$
        RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
        Include /etc/apache2/sites-available/univention-proxy.conf
</VirtualHost>
<VirtualHost *:80>
        IncludeOptional /etc/apache2/sso-vhost.conf.d/*.conf
        ServerName ucs-sso.my-domain
        DocumentRoot /var/www/
        RedirectMatch ^/$ /simplesamlphp/

        ScriptAlias /saml-bin /var/www/saml
        SuexecUserGroup samlcgi samlcgi

        RewriteEngine on
        RewriteCond %{HTTP:Authorization}  !^$
        RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

        Include /etc/apache2/sites-available/univention-proxy.conf
</VirtualHost>
</IfModule>

And /etc/apache2/sso-vhost.conf.d/openid-connect-provider.conf is

#####################################################################
# generated by openid-connect-provider app join script, do not edit manually #
#####################################################################

# Kopano Konnect OIDC
ProxyPass /.well-known/openid-configuration http://localhost:8777/.well-known/openid-configuration retry=0
ProxyPass /konnect/v1/jwks.json http://localhost:8777/konnect/v1/jwks.json retry=0
ProxyPassReverse /konnect/v1/jwks.json http://localhost:8777/konnect/v1/jwks.json
ProxyPass /konnect/v1/token http://localhost:8777/konnect/v1/token retry=0
ProxyPassReverse /konnect/v1/token http://localhost:8777/konnect/v1/token
ProxyPass /konnect/v1/userinfo http://localhost:8777/konnect/v1/userinfo retry=0
ProxyPassReverse /konnect/v1/userinfo http://localhost:8777/konnect/v1/userinfo
ProxyPass /konnect/v1/static http://localhost:8777/konnect/v1/static retry=0
ProxyPassReverse /konnect/v1/static http://localhost:8777/konnect/v1/static
ProxyPass /konnect/v1/session http://localhost:8777/konnect/v1/session retry=0
ProxyPassReverse /konnect/v1/session http://localhost:8777/konnect/v1/session
ProxyPass /konnect/v1/register http://localhost:8777/konnect/v1/register retry=0
ProxyPassReverse /konnect/v1/register http://localhost:8777/konnect/v1/register

# Kopano Konnect login area
ProxyPass /signin/ http://localhost:8777/signin/ retry=0
ProxyPassReverse /signin/ http://localhost:8777/signin/

if I try to curl http://localhost:8777/signin/v1/identifier/_/authorize in the command line I get an error 400. So in general it works. I can also access https://ucs-sso.my-domain/kopanoid/signin/v1/identifier/_/authorize from the browser. But due to some reason kopano meet tries to get https://ucs-sso.my-domain/signin/v1/identifier/_/authorize which is not working after the change of the cert and adding ucs-sso sub domain to LE.

There is one point when the app suddenly swaps the URL from …/kopanoid/signin/… to /signin/…

grafik

grafik

yes, the /kopanoid part is expected. there is another Konnect hidden away in the Meet app. This is required since allowing guest users needs modifications to the identifier registration and that was too complicated to do with the Univention OpenID app. But this is not your issue.

Your issue is though that https://ucs-sso.360x.media/signin/v1/identifier/ gives a 404 when calling it in the browser. This should give you the OpenID Login page. Since this is an Apache error page this means the url is not properly proxied to the OpenID app.

Okay, understand. So in your eyes it is an univention proxy issue of the open ID connector config?

It looks I found a part of the issue . . . When trying to enter https://ucs-sso.my-domain/simplesamlphp/ I get the error /saml-bin/php-cgi/simplesamlphp/index.php. Had a look to the apache config and the folder /usr/share/simplesamlphp/www/ is there and the folder /var/www/saml as well as the file php-cgi

Also https://ucs-sso.my-domain/.well-known/openid-configuration brings me a The requested URL /.well-known/openid-configuration was not found on this server.

/etc/apache2/sites-available/univention-proxy.conf looks like this

# Warning: This file is auto-generated and might be overwritten by
#          univention-config-registry.
#          Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-config-registry ueberschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
#
#       /etc/univention/templates/files/etc/apache2/sites-available/univention-proxy.conf
#

# If we are in ucs-sso virtualhost context we need to redirect the requests to the correct FQDN

RewriteCond %{HTTP_HOST} ^ucs-sso.my-domain$
RewriteCond %{REQUEST_URI} ^/univention/(login|management|self-service|portal|server-overview)/$
RewriteRule ^/univention/(.*)$ %{REQUEST_SCHEME}://my-domain/univention/$1 [L,QSA,R=301,END]





# prevent to proxy requests under /univention/ to the UMC-Webserver if the request URI matches a existing file

# This is outsourced into a single new file because the VirtualHost for ucs-sso.$domainname
# also needs to serve files under /univention/ but there is a bug in apache which doesn't evaluate these rules
# in the non-default virtualhost while they are in the global configuration
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d
RewriteRule ^/univention/(.*)$ %{DOCUMENT_ROOT}%{REQUEST_FILENAME} [END]

# TODO: Since apache 2.4.26 it is possible to just define the environment variable "no-proxy" for requests with these conditions.
# TODO: if this works properly we can remove the rules above and put this definition back into the regular UMC configuration and remove the reference in univention-saml.conf
# note: with "Loglevel trace8" one can see which environment variables are set when
# FIXME: REQUEST_FILENAME seems always empty... using REQUEST_URI instead
#SetEnvIfExpr "-f '%{DOCUMENT_ROOT}%{REQUEST_FILENAME}' || -d '%{DOCUMENT_ROOT}%{REQUEST_FILENAME}' || -f '%{REQUEST_FILENAME}' || -d '%{REQUEST_FILENAME}'" "no-proxy=1"
SetEnvIfExpr "-f '%{DOCUMENT_ROOT}%{REQUEST_URI}' || -d '%{DOCUMENT_ROOT}%{REQUEST_URI}'" "no-proxy=1"

I’ve mailed with Univention about this and apparently the sso page needs some manual steps to work with Lets Encrypt. The recommended solution was to link the the config file for it into /etc/apache2/ucs-sites.conf.d/. For me it worked out of the box since I had already linked it into /etc/apache2/conf-enabled.

$ ls -la conf-enabled/openid-connect-provider.conf
lrwxrwxrwx 1 root root 46 Nov 15 13:26 conf-enabled/openid-connect-provider.conf -> ../conf-available/openid-connect-provider.conf

Hey @fbartels,

that did the trick. Just ran a a2enconf openid-connect-provider.conf followed by systemctl reload apache2 and it works. Never thought about to have a look if there is some config not enabled.

BTW . . . after a first glance on kopano meet I must say you did a great job. If I could wish something for future development it would be a SIP bridge to enable users dial-in.

Thank you very much!

1 Like

Hello there,

would it be possible that someone write quick summary, how to enable LE for the OpenID-SSO Domain? maybe @fbartels or @raceface2nd We are an app-provider and need a public SSO-endpoint.
And its hard to tell/help customers to enable LE or some other certificate for the SSO if you can’t do it yourself.

I’ve tried the provided steps, but now some of the endpoints are not reachable and i think i did something wrong.

we also want to point our customers (schools) to that summary, that they can easily change their certificates too.

Better would be an option in the LE-installer, which automatically adds SSO just like apache or postfix.

1 Like

Hello @lsteinbrecher,

the following knowledge base articles may help:

Automatically changing the certificates for the single sign-on configuration by an app is absolutely not recommended, because the scenarios can be vary a lot.

The target environment needs to make the SSO endpoint publicly available on its own and the above linked articles should help with that.

Best regards,
Nico

Mastodon