Univention Bugzilla – Bug 52513
stunnel should not use the SAML IdP signing certificate for its TLS tunnel
Last modified: 2022-12-06 14:06:42 CET
Currently the stunnel config uses saml/idp/certificate/certificate and saml/idp/certificate/privatekey to establish the stunnel connections between the SAML IdPs. IMHO the SAML IdP certificate should ONLY be used for signing the SAML assertions, but not for the stunnel connections. The current implementation has several drawbacks for typical, real-life UCS Portal + IdP scenarios where one needs to change the SSO FQDN from ucs-sso.domain.name to sso.internet.domain (see https://help.univention.com/t/16161). In this case the stunnel connections will fail, because: - stunnel uses saml/idp/certificate which matches ucs-sso.domain.name - stunnel will do a checkHost against ucs/server/sso/fqdn which we changed to sso.internet.domain and the certificate verification will fail. This leads to a non-working stunnel connection: Dec 18 10:32:13 srv-ucsm01 univention-saml-stunnel: LOG4[12]: CERT: No matching host name found Dec 18 10:32:13 srv-ucsm01 univention-saml-stunnel: LOG4[12]: Rejected by CERT at depth=0: C=DE, ST=DE, L=DE, O=Musterstadt, OU=Univention Corporate Server, CN=ucs-sso.musterstadt.de, emailAddress=ssl@musterstadt.de Dec 18 10:32:13 srv-ucsm01 univention-saml-stunnel: LOG3[12]: SSL_connect: 1416F086: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed Dec 18 10:32:13 srv-ucsm01 simplesamlphp[23839]: 3 [cb60e63e1d] SimpleSAML_Error_Exception: Error 8 - MemcachePool::get(): Server unix:///var/run/univention-saml/srv-ucsb01.musterstadt.de.socket (tcp 0, udp 0) failed with: Read failed (socket was unexpectedly closed) (0) Impact: We don't synchronized SAML assertions between the IdPs My first impulse to fix this was to change saml/idp/certificate/* to a certificate that matches sso.internet.domain, BUT this also changes the certificate which the SAML IdP uses to sign the SAML assertions and now the SAML logins fail for all SPs because I changed that certificate. The much better solution would be to change the stunnel config to use NOT the SAML IdP signing certificate. I propose to make at least "cert", "key" and "CAfile" configurable via their own UCRVs: stunnel/univention-saml/cert stunnel/univention-saml/key stunnel/univention-saml/CAfile
stunnel doesn't transfer SAML assertions but simplesamlphp Sessions. If you are able to hack into it, you can create sessions which doesn't exists. So if we change it we have 2 certificates(private keys) which have to be protected instead of one.
(In reply to Florian Best from comment #1) > stunnel doesn't transfer SAML assertions but simplesamlphp Sessions. Thanks, I got that wrong. Makes much more sense this way. > If you are able to hack into it, you can create sessions which doesn't > exists. > So if we change it we have 2 certificates(private keys) which have to be > protected instead of one. Sure. Is this an argument against using 2 certificates or just a "FYI statement"? I think "protecting private keys" is a much bigger topic than this specific bug (see Bug 45435 and Bug 42494 comment 1).