Alte Zertifikate nach PKI Update

phoenix · December 8, 2015, 3:08pm

Hallo,

nach einer Neuinstallation von UCS4.1 habe ich das Stammzertifikat geändert. Nun ist mir von zumindest 2 Diensten bekannt,
dass dort die Serverzertifikate nicht neu ausgestellt werden. Zum einen arbeitet der Radius Server noch mit alten Zertifikaten (ließ sich durch ein
univention-run-join-scripts --run-scripts 80univention-radius --force) beheben, als auch das ucs-sso Zertifikat ist noch das alte,
weshalb nach einem Versuch sich per SSO anzumelden folgende exception erscheint:

Backtrace:
1 /usr/share/simplesamlphp/www/_include.php:37 (SimpleSAML_exception_handler)
0 [builtin] (N/A)
Caused by: Exception: Unable to validate Signature
Backtrace:
6 /usr/share/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Utils.php:157 (SAML2_Utils::validateSignature)
5 [builtin] (call_user_func)
4 /usr/share/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Message.php:221 (SAML2_Message::validate)
3 /usr/share/simplesamlphp/modules/saml/lib/Message.php:194 (sspmod_saml_Message::checkSign)
2 /usr/share/simplesamlphp/modules/saml/lib/Message.php:251 (sspmod_saml_Message::validateMessage)
1 /usr/share/simplesamlphp/modules/saml/lib/IdP/SAML2.php:305 (sspmod_saml_IdP_SAML2::receiveAuthnRequest)
0 /usr/share/simplesamlphp/www/saml2/idp/SSOService.php:18 (N/A)

Ein erneutes Ausführen von 91univention-saml brachte leider keine Besserung. Sind eventuell noch weitere Dienste betroffen?
Ist es safe alle Joinskripts erneut auszuführen (univention-run-join-scripts --force), oder muss dann mit Problemen gerechnet werden?
Eine andere Sache, die mir aufgefallen ist, sind etliche Fehlermeldungen im Apache Log:

[Tue Dec 08 15:57:27 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US
[Tue Dec 08 15:57:27 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US
[Tue Dec 08 15:57:27 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US
[Tue Dec 08 15:57:28 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US
[Tue Dec 08 15:57:28 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US
[Tue Dec 08 15:57:28 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US
[Tue Dec 08 15:57:28 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US
[Tue Dec 08 15:57:28 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US
[Tue Dec 08 15:57:28 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US

Hat jemand für diese Fehler einen Rat?

Moritz_Bunkus · December 9, 2015, 3:34pm

Moin,

Ich habe mir eben mal das Join-Script angesehen. Das Zertifikat wird nur dann neu ausgestellt, wenn es noch nicht im Dateisystem existiert. Sie können es also im Dateisystem umbenennen (oder löschen, wenn Sie mutig sind) und dann das Join-Script erneut mit --force ausführen.

Wo liegt das Zertifikat? Das wiederum steht in der UCR-Variablen »saml/idp/certificate/certificate«: »ucr get saml/idp/certificate/certificate«.

Mit --force? Hmm, das SAML-Script ist so geschrieben, dass es nichts kaputt macht, wenn es mehrfach ausgeführt wird. Ob das für alle anderen auch gilt, kann ich nicht sagen; laut Univention sollte das aber OK sein.

Moritz_Bunkus · December 9, 2015, 3:43pm

Moin,

[quote=“phoenix”]Eine andere Sache, die mir aufgefallen ist, sind etliche Fehlermeldungen im Apache Log:

[Tue Dec 08 15:57:27 2015] [error] [client 172.16.1.128] File does not exist: /var/www/univention-management-console/js_$20150712001328$/umc/modules/i18n/en, referer: https://example.domain.tld/univention-management-console/?lang=en-US …[/quote]

Die können Sie getrost ignorieren.

Hintergrund ist das Übersetzungssystem der UMC. Für jedes Modul, das in der UMC angezeigt wird (User, Devices, DHCP…), wird eine Übersetzungsdatei für die ausgewählte Sprache beim Server angefragt. Da die Begriffe standardmäßig aber eh schon auf Englisch im Quelltext stehen, gibt es für Englisch schlicht keine Übersetzungsdateien.

Wenn Sie sich statt dessen einmal mit deutscher Oberfläche einloggen, so werden Sie die Fehler eben nicht mehr sehen.

Ja, es ist unschön und sollte meiner Meinung nach eigentlich nicht vorkommen, weil es die Fehlersuche bei tatsächlichen Problemen mit Webanwendungen erschwert, ist aber letztlich harmlos.

phoenix · December 12, 2015, 9:03am

Hey,
danke für die rasche Antwort
Stimmt, das Zertifikat war tatsächlich noch das alte… Habs jetzt mit univention-certificate new neu ausgestellt, soweit alles okay, saml join script erneut ausgeführt,
er wirft mir aber immernoch die gleiche exception!? Gibts eventuell noch ein join script, welches ausgeführt werden muss?

Zur Sache mit dem Apache error Log, ja, schön ist das tatsächlich nicht… Könnte man nicht dummy translation files erstellen, die den Fehler abfangen?

Moritz_Bunkus · December 14, 2015, 9:06am

Ich weiß nicht wirklich, was bei SAML alles an dem Zertifikat hängt, sprich ob Dienste neu gestartet werden müssten oder so. Können Sie den Server nicht einfach mal neu starten?

Zu den Apache-Fehlermeldungen: klar, da gibt’s die verschiedensten Dinge, die man tun kann: wenn Englisch dann garn icht erst laden; Dummy-Dateien für Englisch anlegen (aus Programmierersicht eine hässliche Lösung); Apache so konfigurieren, dass bei Requests nach den englischen Übersetzungen keine Fehlermeldung geloggt wird (aus Programmierersicht hässlich aber von Ihnen als Admin durchaus als Interims-Lösung umsetzbar). Ich habe hierzu einen Bug-Eintrag erstellt; es schien vorher noch keinen gegeben zu haben.

phoenix · December 14, 2015, 12:53pm

Jup, ist schon geschehen, aber leider immernoch mit dem selben Ergebnis…
Leider bin ich kein Programmierer, aber soweit ich den Backtrace richtig nachvollziehen kann, kommt hier der falsche Key her:

foreach ($pemKeys as $i => $pem) { $key = new XMLSecurityKey(XMLSecurityKey::RSA_SHA1, array('type'=>'public')); $key->loadKey($pem); [...]
Was in der Folge dann die Exception verursacht… Aber was ist das für ein Key?

Super, Danke, werde ich mal verfolgen und in der Zwischenzeit den Log mit Apache säubern.

freundliche Grüße

Moritz_Bunkus · December 14, 2015, 2:00pm

Können Sie bitte mal die Ausgabe des folgenden Befehls hier posten:

eval $(ucr shell domainname) openssl x509 -in /etc/simplesamlphp/ucs-sso.${domainname}-idp-certificate.crt -noout -text

phoenix · December 15, 2015, 10:08am

Hey, klar (Domain aus sicherheitstechnischen Gründen abgeändert)

root@ucs-dc01:/usr/local/bin# openssl x509 -in /etc/simplesamlphp/ucs-sso.${domainname}-idp-certificate.crt -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 10 (0xa)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=DE, ST=Northrine-Westphalia, L=Witten, O=domain, OU=Univention Corporate Server, CN=Univention Corporate Server Root CA (ID=domain.tld)/emailAddress=ssl@domain.tld
        Validity
            Not Before: Dec 10 09:50:05 2015 GMT
            Not After : Dec  8 09:50:05 2020 GMT
        Subject: C=DE, ST=Northrine-Westphalia, L=Witten, O=domain, OU=Univention Corporate Server, CN=ucs-sso.domain.tld/emailAddress=ssl@domain.tld
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d0:c7:98:a8:cb:f8:d3:75:97:ea:52:bf:51:43:
                    5a:53:b5:be:21:5f:01:d3:76:fc:a6:59:3b:a5:6e:
                    8d:05:90:19:9d:d0:7b:4a:50:36:d9:f6:e6:73:b4:
                    ed:4e:e2:01:1b:7d:c5:bc:a3:89:11:71:36:96:96:
                    56:84:e0:48:f9:be:4f:93:42:ba:39:47:9b:e2:e8:
                    d8:9f:4a:4a:c1:e3:29:37:33:b8:83:ed:c1:22:c3:
                    81:99:6c:ae:5c:f1:1b:da:7b:84:dd:06:47:62:69:
                    d2:66:f0:2c:c6:ba:e8:93:ee:a7:13:c2:dc:3b:53:
                    8d:8c:bf:69:a8:7f:6a:c4:e3:5e:b0:ec:f7:fe:28:
                    ef:2b:f1:67:66:b1:73:27:77:8f:08:67:ea:82:ad:
                    cd:26:a7:9e:07:2b:ed:14:90:7c:c1:b6:0b:07:c1:
                    5f:19:7f:71:4e:33:54:f3:d5:0b:ca:bc:96:95:d5:
                    0d:fb:b1:a8:35:67:90:94:99:5d:af:31:23:b2:d3:
                    85:d1:3c:9f:00:4a:09:e7:1c:64:5c:4a:de:f2:a2:
                    f8:4e:e7:da:16:9d:f3:02:4f:db:d2:c3:e4:f7:62:
                    4b:6f:a2:bf:ba:f4:90:e1:d4:dc:d7:27:d0:16:52:
                    7b:58:a6:d6:2f:a5:b0:91:67:03:e0:28:b5:bf:72:
                    16:6f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Subject Key Identifier:
                C4:AD:31:90:3B:4C:1C:C9:07:DD:CA:5F:1D:23:42:8E:64:78:C7:3B
            X509v3 Authority Key Identifier:
                keyid:05:32:6A:88:75:AB:A5:78:71:7E:14:10:AC:02:4B:7D:6F:B9:40:B1
                DirName:/C=DE/ST=Northrine-Westphalia/L=Witten/O=domain/OU=Univention Corporate Server/CN=Univention Corporate Server Root CA (ID=domain.tld)/emailAddress=ssl@domain.tld
                serial:FA:16:80:F9:E4:0B:5E:E8

            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name:
                DNS:ucs-sso.domain.tld, DNS:ucs-sso
    Signature Algorithm: sha256WithRSAEncryption
         48:4c:5b:29:0b:52:b6:19:01:57:de:62:f8:3a:84:80:8b:4b:
         4e:b5:d8:e2:f6:2f:2c:4f:3b:02:d5:16:cb:97:07:6e:d3:49:
         5f:b1:07:4d:da:49:34:3a:4f:cd:f0:5e:b6:96:69:11:cb:5b:
         f0:41:9a:4d:0b:76:49:58:bb:c9:30:c4:9d:71:8d:63:dd:a5:
         9c:fe:8a:97:ef:82:81:91:a2:03:70:ea:eb:3e:7f:76:36:9b:
         11:00:2b:fd:da:6f:7e:88:db:3c:f9:b8:04:f5:00:c4:d1:5c:
         d8:09:f0:68:be:1b:af:ce:92:5e:25:9c:d2:22:19:29:63:ce:
         bc:ab:de:6e:4e:04:0b:02:90:d5:38:5b:3c:4f:74:cc:ee:9d:
         9d:80:86:de:ea:dc:37:fa:a4:e5:f0:aa:da:41:07:a4:61:63:
         14:eb:90:41:c0:ba:0f:4e:e3:51:29:23:c2:e8:5c:1c:d9:3b:
         97:11:31:06:85:bc:d1:db:bd:84:c4:b1:cb:65:14:5f:34:eb:
         69:6a:86:af:30:0d:71:3d:8f:f3:0d:08:42:8f:e4:a0:61:50:
         5e:4e:89:e9:12:e5:b7:49:1d:aa:01:1b:ee:ba:25:ba:68:fd:
         99:d1:a5:98:77:53:6e:5d:8e:1e:b6:8c:28:d7:94:25:39:8c:
         79:a9:b0:4f

Und hier nochmal zur Bestätigung, dass das Zertifikat auf jeden Fall okay ist

root@ucs-dc01:/usr/local/bin# ./ssl-cert-chain-check.sh ./certificate
Using default temp DH parameters
ACCEPT
verify depth is 8
depth=1 C = DE, ST = Northrine-Westphalia, L = Witten, O = domain, OU = Univention Corporate Server, CN = Univention Corporate Server Root CA (ID=domain.tld), emailAddress = ssl@domain.tld
verify return:1
depth=0 C = DE, ST = Northrine-Westphalia, L = Witten, O = domain, OU = Univention Corporate Server, CN = ucs-sso.domain.tld, emailAddress = ssl@domain.tld
verify return:1
DONE
ACCEPT
!!! =========> CA-Bundle is not needed! <========

./ssl-cert-chain-check.sh: line 13: 24153 Terminated              openssl s_server -key "$KEY" -cert "$CRT" "$@" -www
Using default temp DH parameters
ACCEPT
verify depth is 8
depth=1 C = DE, ST = Northrine-Westphalia, L = Witten, O = domain, OU = Univention Corporate Server, CN = Univention Corporate Server Root CA (ID=domain.tld), emailAddress = ssl@domain.tld
verify return:1
depth=0 C = DE, ST = Northrine-Westphalia, L = Witten, O = domain, OU = Univention Corporate Server, CN = ucs-sso.domain.tld, emailAddress = ssl@domain.tld
verify return:1
DONE
ACCEPT
./ssl-cert-chain-check.sh: line 13: 24159 Terminated              openssl s_server -key "$KEY" -cert "$CRT" "$@" -www

EVERYTHING OK
SSLCertificateKeyFile ./certificate.key
SSLCertificateFile    ./certificate.crt
SSLCACertificateFile  ./certificate.bundle

So wie ich das sehe, bleibt mir nur noch jedes join script anzusehen und zu schauen, ob da irgendwo Zertifikate von saml abhängen!?

Best · December 15, 2015, 3:31pm

Generell müssen /etc/simplesamlphp/ucs-sso.${domainname}-idp-certificate.crt und /etc/univention/ssl/ucs-sso.${domainname}/cert.pem inhaltlich identisch sein (aber andere Dateisystem-Berechtigungen haben).
Gleiches gilt für den Private-Key /etc/simplesamlphp/ucs-sso.${domainname}-idp-certificate.key und /etc/univention/ssl/ucs-sso.${domainname}/private.key.

Das muss auf allen Identity Providern (= UCS-DC-Master und UCS-DC-Backup-Systeme) der Fall sein.
Im Browser kann dann manuell überprüft werden, ob das Zertifikat in den XML-Metadaten korrekt ist:

eval "$(ucr shell domainname)"
firefox "http://ucs-sso.${domainname}/simplesamlphp/saml2/idp/metadata.php"

Ist dies der Fall kann auf jedem Service Provider (=jedes UCS-System mit UMC) folgende Befehle ausgeführt werden:

eval "$(ucr shell ucs/server/sso/fqdn)"
rm /usr/share/univention-management-console/saml/idp/*.xml
ucr set umc/saml/idp-server="https://${ucs_server_sso_fqdn}/simplesamlphp/saml2/idp/metadata.php" || echo 'Failed!'
/etc/init.d/univention-management-console-web-server restart
univention-run-joinscripts --force --run-scripts 92univention-management-console-web-server.inst

Danach sollte im Directory /usr/share/univention-management-console/saml/idp/ wieder die XML-Metadaten Datei vom Identity Provider liegen und UMC sollte wieder per SAML erreichbar sein.

phoenix · December 16, 2015, 9:42am

Super, das war´s. SSO funktioniert nun wie es soll, danke!
Bzgl. des Apache Patches, wie genau muss der angewendet werden? Weil einfach so gehts nicht:

wget http://forge.univention.org/bugzilla/attachment.cgi?id=7376 -O /tmp/umc.patch | patch < /tmp/umc.patch

Danke auch nochmal an Moritz für die tatkräftige Unterstützung!
MfG, Marcel

Best · December 16, 2015, 10:29am

Der patch ist für die Struktur in unserem Code-Repository kann also nicht gegen ein laufendes UCS-System angewendet werden.
Das würde ich auch erst einmal nicht empfehlen, da dazu UCS-Templates von UMC angepasst werden müssen und diese dann durch die manuelle Anpassung nicht automatisch bei einem Update angepasst werden können. Dadurch könnten Folgefehler passieren und bei jedem Update müssen die beiden Dateien von Hand verglichen werden.
Sie können die Änderungen auf Ihre eigene Gefahr&Verantwortung ansonsten manuell in /etc/univention/templates/files/etc/apache2/sites-available/univention-management-console und /usr/share/univention-management-console-frontend/js/umc/modules/i18n/empty.json entsprechend dem Patch übernehmen.

Moritz_Bunkus · December 16, 2015, 12:30pm

Hallo Herr Best,

es wäre super, wenn Sie die Support-DB-Einträge zum Thema Zertifikatserneuerung mit der notwendigen Prozedur für SAML ergänzen könnten. Danke sehr.

cpzengel · January 10, 2023, 7:33pm

Servus, hier der selbe Mist.
Keine Ahnung wie ich das reinbekommen habe.

Wie erzeugt man das Zertifikatspaar für SSO neu, wenn es fehlt?