Neue Namensattribute bei der LRZ-CA

Die aktuelle Version 3.0 der Zertifizierungsrichtlinie der DFN-PKI (Sicherheitsniveau "Global") hat sich gegenüber der vorhergehenden Version signifikant geändert (jetzt ist der öffentliche Schlüssel der DFN-PCA in einem Zertifikat enthalten, das durch die Deutsche Telekom Root CA 2 ausgestellt wurde).  Als Folge ändern sich die Namensattribute bei allen Zertifikaten, die von der LRZ-CA nach dem Sicherheitsniveau "Global" ausgestellt werden.

Zertifikate der LMU-CA oder TUM-CA oder Zertifikate nach dem Sicherheitsniveau "Grid" sind von der Änderung nicht betroffen.

Neue Namensattribute

Bisher waren im PKCS#10-Zertifikatantrag beim Namen die folgenden beiden Endungen möglich:

  • O=Leibniz-Rechenzentrum,L=Garching,ST=Bayern,C=DE
  • O=Leibniz-Rechenzentrum,L=Muenchen,ST=Bayern,C=DE

In Zukunft ist beim Attribut "O" (Organization) nur noch der Wert "Bayerische Akademie der Wissenschaften" erlaubt.  Dadurch ist dann nur noch die folgende Endung möglich:

  • OU=Leibniz-Rechenzentrum,O=Bayerische Akademie der Wissenschaften,L=Garching b. Muenchen,ST=Bayern,C=DE

Migration

Alle bisher ausgestellten Zertifikate dürfen weiter verwendet werden, bis ihre Gültigkeit von selbst abläuft;  diese alten Zertifikate müssen also nicht vorzeitig erneuert werden.

Bei neuen Zertifikaten oder bei der Verlängerung bestehender Zertifikate sollte der Name unbedingt die neue Endung besitzen.
Nur in Ausnahmefällen kann noch für kurze Zeit ein Zertifikat ausgestellt werden, bei dem der Name eine der beiden alten Endungen besitzt.  In diesen Ausnahmefällen ist nur eine kürzere Gültigkeitszeit möglich.

Erforderliche Anpassungen

Bei Server-Zertifikaten reicht es in vielen Fällen aus, das Zertifikat zu aktualisieren bzw. auszutauschen.

Bei Shibboleth enthalten die Meta-Daten das aktuelle Zertifikat des Service-Providers bzw. Identity-Providers.  Deshalb muss man in diesem speziellen Fall auch die Metadaten bei der Föderation aktualisieren lassen.

Wenn eine Server-Anwendung Client-Zertifikate zur Authentifizierung nutzt (i.a. SSL-Client-Auth) und dabei den SubjectDN prüft, muss man die Server-Anwendung anpassen.  Beispiele für derartige Server-Anwendungen:

  • Web-Server mit SSL-Client-Auth
  • LDAP-Server mit SSL-Client-Auth
  • RADIUS, falls EAP-TLS zum Einsatz kommt
  • Mail-Server mit SSL-Client-Auth: IMAP, POP und SMTP
  • Falls beim Shibboleth-Login ein Shibboleth-Identity-Provider SSL-Client-Auth benutzt, ist der Identity-Provider betroffen.  Gewöhnlich wird aber zur Authentifizierung immer noch Kennung plus Passwort benutzt.

Achtung!

Wurde ein altes Nutzer-Zertifikat (Client-Zertifikat) zur Verschlüsselung von E-Mails verwendet, darf man das alte Zertifikat mit dem zugehörigen privaten Schlüssel unter keinen Umständen wegwerfen.  Andernfalls kann man die alten E-Mails nicht mehr entschlüsseln.

Aus Sicherheitsgründen sollte man alte Zertifikate und/oder Schlüssel prinzipiell nur dann wegwerfen, wenn es einen triftigen Grund dafür gibt.  Andernfalls sollte man sie an einem sicheren Ort aufbewahren.