inst.sh fails if apache uses a non-default TLS certificate
Closed this issue · 1 comments
Univention Forum (german): http://forum.univention.de/viewtopic.php?f=67&t=6573
By default, TLS capable services on a Univention Corporate Server use a TLS certificate that is signed by the (self-signed) UCS CA. The inst.sh validates this certificate by verifying against the UCS CA Root Certificate when using the OCS-API via curl:
curl --cacert /etc/univention/ssl/ucsCA/CAcert.pem -X PUT ...
This works fine as long as the default certificate is used. But services like Apache can easily be configured to use other certificates that are issued by an official CA:
http://sdb.univention.de/1243
http://wiki.univention.de/index.php?title=Cool_Solutions_-_Let%27s_Encrypt
In these cases, the curl commands fail and the config is not written to Nextcloud resulting in a non-working Nextcloud installation.
It should be sufficient to use --capath /etc/ssl/certs/ instead of --cacert /etc/univention/ssl/ucsCA/CAcert.pem, because since UCS 4.1-4 Errata 361, the UCS CA certificate is also linked to /etc/ssl/certs/ (AFAIK it is possible to specify which UCS Version and Errata Level is required for the App in the App Center Provider Portal)
Just verified this: With UCS 4.1-4 Errata 361 or newer the UCS CA root certificate is added to the system's trust store:
/etc/ssl/certs/ucsCA.pem -> /usr/local/share/ca-certificates/ucsCA.crt
/usr/local/share/ca-certificates/ucsCA.crt -> /etc/univention/ssl/ucsCA/CAcert.pem
Because of that, we can simply remove the --cacert option and let curl use the system's trust store by default.
Tested with UCS default certificate:
- on UCS Memberserver: ✓
- no errors during App installation: ✓
- no errors in
/var/log/univention/join.log: ✓ - successful login to Nextcloud with regular UCS LDAP user: ✓
Pull Request incoming 🙂