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
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.
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.
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.
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
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.
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)
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.
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.
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
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.
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.
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.
