Zertifikate für die SAML-basierte Kommunikation

Sofern Sie erfolgreich Attribute übertragen konnten, sollten Sie als nächstes auf DFN-PKI-Zertifikate wechseln. Die bei der Installation erzeugten Private Keys und zugehörigen selbst-signierten Zertifikate müssen für den späteren Produktionsbetrieb gegen DFN-PKI-Zertifikate ausgetauscht werden. Wir empfehlen die Verwendung der selben Key- und Zertifikats-Files, die bereits für den Webserver verwendet werden, damit das Key-Handling nicht zu unübersichtlich wird.

Es gibt ein paar Kleinigkeiten zu beachten:

  • Das Format der Zert-Datei muss PEM sein, DER funktioniert nicht.
  • Die PEM-Dateien dürfen keine Kommentare enthalten, sie müssen in der ersten Zeile mit „—–BEGIN“ anfangen.
  • In den PEM-Dateien dürfen am Ende der Zeilen keine Leerzeichen oder andere unsichtbare Zeichen sein.
  • Der private Schlüssel darf nicht mit einer Passphrase verschlüsselt sein.

Unter Debian/Ubuntu liegen diese Dateien typischerweise unter /etc/ssl. Tragen Sie sie in ./conf/idp.properties ein.

/opt/shibboleth-idp/conf/idp.properties
# ...
idp.signing.key= /etc/ssl/private/idp-dev.uni-beispiel.de.key.pem
idp.signing.cert= /etc/ssl/localcerts/idp-dev.uni-beispiel.de.crt.pem
idp.encryption.key= /etc/ssl/private/idp-dev.uni-beispiel.de.key.pem
idp.encryption.cert= /etc/ssl/localcerts/idp-dev.uni-beispiel.de.crt.pem
# ...

Der IdP läuft im Tomcat und damit mit den Berechtigungen des Tomcat-Users. Damit er Zugriff auf die Dateien unterhalb von /etc/ssl/private bekommt, muss er (unter Debian und Ubuntu) in die Gruppe 'ssl-cert' aufgenommen werden:

root@idp:~# usermod -aG ssl-cert $( getent passwd | grep ^tomcat | cut -d ":" -f1 )

Das Verzeichnis /etc/ssl/private und sein Inhalt sollten dem User root und der Gruppe ssl-cert gehören:

root@idp:~# chown -R root:ssl-cert /etc/ssl/private

Der private Schlüssel sollte für root les- und schreibbar sein, für die Gruppe ssl-cert nur lesbar, andere haben dort keine Rechte:

root@idp:~# chmod 0640 /etc/ssl/private/idp-dev.uni-beispiel.de.key.pem

So sehen die Dateirechte auf dem privaten Schlüssel dann aus:

root@idp:~# ls -la /etc/ssl/private/idp-dev.uni-beispiel.de.key.pem 
-rw-r----- 1 root ssl-cert 3272 May 31 12:56 /etc/ssl/private/idp-dev.uni-beispiel.de.key.pem

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# systemctl restart tomcat9

Das DFN-PKI-Zertifikat muss nun noch in die veröffentlichten Metadaten des IdP eingetragen werden. Dort steht jetzt noch das bei der Installation generierte selbst-signierte Zertifikat.

  • Gehen Sie in die Metadatenverwaltung. Löschen in den IdP-Metadaten zunächst alle eingetragenen Zertifikatsinstanzen.
  • Tragen Sie das neue Zertifikat zweimal ein: einmal im Abschnitt „IdP Single Sign On Descriptor“ und einmal im Abschnitt „Attribute Authority Descriptor“. In beiden Fällen lassen Sie dabei das Feld „Verwendungszweck“ leer. So wird dasselbe Zertifikat für Signierung und Verschlüsselung verwendet.
  • Warten Sie dann 90 Minuten, bis die neuen Zertifikate in die DFN-AAI-Test-Metadaten aufgenommen worden sind.

Testen Sie danach erneut die Attribut-Freigaben mithilfe der DFN-Test-SPs.

Die Datei ./metadata/idp-metadata.xml enthält nach wie vor die selbst-signierten Zertifikate, die bei der Installation automatisch generiert wurden. Diese Datei wird nicht automatisch aktualisiert. Das ist kein Problem, denn die Datei ist für den Betrieb des IdP nicht erforderlich. Sie ist als Hilfsmittel zur initialen Registrierung des IdP in einer Föderation gedacht. Wir empfehlen diese Datei „in Ruhe“ zu lassen.

  • Zuletzt geändert: vor 3 Monaten