Einführung von GÉANT-TCS-Zertifikaten an der Universität Münster

Wer bin ich?

• Am besten passt wohl: Systemarchitekt

• Erste intensive Kryptographie-Erfahrungen im Wehrdienst 1982/83

• Diplom-Physiker (Studium an der Uni Münster 1983-1989)

• Ab 1987 studentische Hilfskraft im Universitätsrechenzentrum

• Ab 1989 wissenschaftlicher Mitarbeiter (befristet, unbefristet, verbeamtet)

• Durchgehend in der System-Abteilung des URZ, später ZIV, jetzt IT

• Eigenentwicklungen: Informationssystem inform (vor WWW),
  Webmailer perMail, IT-Portal, zentrales Single Sign-On und mehr

• Arbeitsschwerpunkte: Zentraler Webserverpark, WWUCA, IT-Portal,
  Webmailer perMail; Stellvertreter: Postmaster, Listserveradmin usw.

• Früher auch Nutzerberatung, Uni-Webmaster, eigene PGP-CA,
  CERT, oft auch interner Ansprechpartner bei Internetrechtsfragen

Situation in Münster

• Westfälische Wilhelms-Universität (44.400 Stud.)

• Fachhochschule Münster/Steinfurt (15.600 Stud.)

• Kunstakademie Münster (400 Stud.)

• und weitere, insgesamt 9 Hochschulen

• Max-Planck-Institut für molekulare Biomedizin

• Universitätsklinikum Münster (UKM)

  • Besonderheit in NRW: UKMs sind eigenständig

  • Medizinische Fakultät ist Uni, nicht UKM

• WWU ist Stadt-Uni, keine Campus-Uni

  • 240 Gebäude in der ganzen Stadt (früher 1000)

  • Einige campusartige Bereiche

• WWU IT versorgt WWU und KA (nicht mehr UKM)

• DFN-Cluster-Anschluss von WWU, UKM, FH, KA, MPI

Situation an der WWU

• Zentral: WWU IT (ca. 160 Mitarb.)

  • IT-Infrastruktur

  • Kommunikations- und Medientechnik

  • Verwaltungs-IT

  • ⇨  optimaler Ort für WWUCA
     

• Dezentral: 9 eigenständige IV-Versorgungseinheiten

  • Arbeitsplatz- und Fachbereichssysteme

  • Verwenden oft Infrastruktur der WWU IT

  • Klare Aufgabenverteilung zwischen WWU IT und IVVen

  • ⇨  optimaler Ort für Teilnehmerservice

Netz-Verwaltung durch die WWU IT

• Alleinige Hoheit über sämtliche 53.000 Netzanschlusspunkte und die Netze (davon 205 km Glasfaser)

  • Endgeräte dürfen nur nach Anmeldung angeschlossen werden (zzt. 31.000)

  • WLAN und pLANet.X-Dosen können ohne Rechneranmeldung, dafür mit Login genutzt werden

  • Zzt. 20.000 gleichzeitige WLAN-Nutzer
     

• Zentrale Netzdatenbank steuert alle Netzanschlüsse und kennt alle Endgeräte-Verantwortlichen

  • Über drei Jahrzehnte gewachsene Eigenentwicklung

  • Self-Service „NIC_online“ für alle registrierten IT-Administratoren und die Admins

  • ⇨  optimale Datenquelle zum Prüfen von Serverzertifikat-Anträgen

Zentrale Nutzer- und Identitätsverwaltung durch die WWU IT

• Zentrale Nutzerdatenbank (mit Gruppenverwaltung und Identitätsmanagement)

  • Über fast drei Jahrzehnte gewachsene Eigenentwicklung

  • Alle Kennungen (zzt. 96.000 aktiv) werden durch die WWU IT vergeben und verwaltet

  • Datenfeeds aus Studierenden- und Personalverwaltungen

  • ⇨  optimale Datenquelle zum Prüfen von Nutzerzertifikat-Anträgen
     

• Zentrale Self-Services für alle Nutzer und die Admins

  • IT-Portal (für alle Nutzer: Passwörter, digitale IDs, IT-Einstellungen)

  • WWUBEN-Portal (für Gruppenleiter: Gruppenverwaltung, Antragsbearbeitung)
     

• Fast alle Systeme in der WWU sind angeschlossen

  • SAP, Mail, Active Directory, LearnWeb, HIS-LSF, SSO (lokal+eduGAIN), Webserver (+CMS), WLAN, VPN, ...

Zentrale Gruppenverwaltung durch die WWU IT

• Alle Gruppenmitgliedschaften werden durch die WWU IT verwaltet

  • weit über 4000 Gruppen

• Manche Gruppenzugehörigkeiten werden automatisch vergeben

  • (WWU-Mitarbeiter, Fachbereichsmitarbeiter, Studierende usw., basierend auf den Datenfeeds)

• Andere Gruppenzugehörigkeiten werden nur auf Antrag vergeben

  • (Zugehörigkeit zu Arbeitsgruppen, Zugang zu Spezialsystemen, Webspaces usw.)

  • Antragstellung in der Regel im IT-Portal

  • Genehmigungen erfolgen dezentral durch Nutzergruppenleiter
     

• Zugangsberechtigungen zu Systemen werden durch die Systembetreiber verwaltet

  • Meist wird der Zugang aufgrund von Gruppenmitgliedschaften gewährt

  • Es gibt keine zentrale Berechtigungen-Datenbank

Zentrale E-Mail-Systeme

• Alle E-Mail-berechtigten Nutzer haben Adresse kennung@uni-muenster.de

  • und können Aliasnamen setzen

  • Eine Adresse wird die Wunsch-E-Mail-Adresse

• Zwei E-Mail-Systeme:

  • Standard (IMAP, SMTP, perMail, notfalls POP, alle über TLS) für alle Berechtigten

  • Exchange (MAPI, ActiveSync, EWS, OWA, alle über HTTPS) für Mitarbeiter u. a.

  • Beide treten nach außen unter @uni-muenster.de auf

• Früher etliche Fachbereichs-Mailsysteme, heute nur noch @wiwi.uni-muester.de

  • Auch diese verwenden die zentrale Nutzerverwaltung

  • IT-Portal kann sehen, welche Nutzer welche Adressen dort haben

• Corporate-Identity-Richtlinie: Alle WWU-Mitarbeiter haben unter uni-muenster.de-Adressen aufzutreten

• ⇨  optimale Datenquelle zum Prüfen von E-Mail-Adressen

IT-Portal

• Eigenentwicklung von mir seit gut einem Jahrzehnt

• Self-Service für alle Nutzer

• Schreibzugriff auf Nutzerdatenbank und zentrale Systeme und Lesezugriff auf Netzdatenbank

• E-Mail-Einstellungen (Aliasnamen, Spamfilter usw.)

• Passwörter und PINs (einzige Stelle zum Setzen zentraler Passwörter)

• Beantragen von Kennungen und Gruppenmitgliedschaften, inkl. Verlängerungen

• Lizenzen (Zugriff auf Sophos, Office 365 usw.)

• Drucken/Scannen (Abrechnung kostenpflichtiger Druckaufträge usw.)

• u. v. a. m.

• ⇨  optimaler Ort zum Beantragen von digitalen IDs (Zertifikaten)

• Live-Demo

Situation an der WWU (Fazit)

• Durch die zentralen Datenbanken extrem komfortable Situation
  (verglichen mit vielen anderen Rechenzentren)
   

• Über Jahrzehnte hart erarbeitet

• Dank Weitsicht und geduldiger Überzeugungskraft von Dr. Wilhelm Held
  (unser RZ-Leiter seit 1981 genießt seit 2007 seinen verdienten Ruhestand)
  und vielen anderen
   

• Man beachte unsere IP-Adressen aus der Frühzeit: 128.176.xxx.xxx
   

WWUCA: Zertifizierungsstelle der Universität Münster

• Seit 1997 PGP, seit 2000 in der DFN-PKI

• Aktuell: DFN-PKI „Global“ und „TCS“

• Zielgruppe: WWU und KA

  • bis letztes Jahr auch UKM

• 3 „handlungsbevollmächtigte Personen“

• dazu 14 „Teilnehmerservice-Mitarbeiter“

• Mein Arbeitszeitaufwand ca. 20 %,
  andere sehr viel weniger
   

• Vorteil: CA und IT-Portal in einer Hand

Eingliederung der WWUCA

• Offiziell ein Dienstangebot der WWU IT, keine organisatorische Einrichtung

• Drei Mitarbeiter der WWU IT Abt. 6 Systeme beim DFN als HPs akkreditiert

• Ich bin zwar Leiter der WWUCA, dienstrechtlich aber einfacher Mitarbeiter ohne Personalverantwortung

  • Projekt-Character: Mitarbeiter unterschiedlicher Abteilungen arbeiten zusammen

  • Aber auf Dauer angelegt

• Alle TS-Mitarbeiter sind interessierte Freiwillige

  • räumlich über die ganze WWU verteilt

  • Bedienstete in unbefristetem Beschäftigungsverhältnis

  • aus WWU IT, IV-Versorgungseinheiten, IT-affinen Instituten oder sonstwie qualifiziert

  • Zustimmung der Vorgesetzten, einen Teil der Arbeitszeit für Teilnehmerservice abzuzweigen

  • Vorgesetzte wissen, dass Zertifizierungsrichtlinien Vorrang vor Institutsinteressen haben

Antragswege vor GÉANT TCS – Personen-E-Mail-Zertifikate

1. Ursprüngliche DFN-Browseroberfläche – für Laien völlig unverständlich

   • Schlüsselerzeugung und -zwischenspeicherung im Browser, PKCS#12-Export aus Browser

   • (erst Jahre später durch viel bessere Browseroberfläche ersetzt, Zwischenspeicherung in JSON-Datei)
      

2. Daher Eigenentwicklung im IT-Portal – nutzt öffentliche SOAP-Schnittstelle der DFN-PKI

   • Anmeldung unter persönlicher Kennung

   • Schlüssel wird vom IT-Portal erzeugt und verschlüsselt in Nutzerdatenbank gespeichert

     • dadurch auch spätere Key-Recovery-Möglichkeit (falls Schlüsselpasswort noch bekannt ...)

   • PDF-Datei muss ausgedruckt und persönlich abgegeben werden (Identitätskontrolle)

   • Wenn fertig, wieder ins IT-Portal, dieses holt Zertifikat und erstellt PKCS#12-Datei
      

3. Nur für Experten: DFN-Browseroberfläche für Serverzertifikate, aber Profil „User“

   • Schlüsselerzeugung und -speicherung durch Nutzer (mit OpenSSL usw.)

Antragswege vor GÉANT TCS – andere Nutzerzertifikate

• Gruppen-/Funktionsträger-E-Mail-Zertifikate

  • Genauso wie Personenzertifikate

  • aber Anmeldung im IT-Portal unter unpersönlicher Kennung

  • (unpersönliche Kennungen haben bei uns immer einen Besitzer, aber der kann sich ändern)

  • PDF-Datei kann per (mit persönlichem WWUCA-Zertifikat) signierter E-Mail eingereicht werden
     

• Codesigning-Zertifikate

  • Exakt wie Personen-/Gruppen-/Funktionsträger-Zertifikate

  • Bei der Antragsübergabe den Teilnehmerservice explizit um ein Codesigning-Zertifikat bitten
     

• Live-Demo

Antragswege vor GÉANT TCS – Serverzertifikate (1)

1. Ursprüngliche DFN-Browseroberfläche

   • Schlüsselerzeugung durch Nutzer (OpenSSL usw.), Upload der Requestdatei

   • Abgabe des Antragsformulars persönlich oder per mit persönlichem WWUCA-Zertifikat signierter Mail

   • Teilnehmerservice prüft manuell Identität und Admin-Rechte

     • IT-Portal liefert Admins zu einem FQDN und Angaben zur Person
        

2. Eigenentwicklung im IT-Portal

   • Angepasste Kopie des Antrags für ein Nutzerzertifikat (s. o.)
      

3. Öffentliche SOAP-Schnittstelle der DFN-PKI

   • Musterskript siehe https://www.uni-muenster.de/WWUCA/de/howto-special-phpsoap.shtml

   • Eigentlich nur eine Zusammenstellung der vom IT-Portal genutzten SOAP-Aufrufe

   • Schlüsselerzeugung und -speicherung auf Rechner des Antragstellers

Antragswege vor GÉANT TCS – Serverzertifikate (2)

4. Erweitertes Skript nutzt öff. SOAP-Schnittstelle der DFN-PKI und HTTPS-Schnittstelle vom IT-Portal

• Musterskript siehe https://www.uni-muenster.de/WWUCA/de/howto-special-autocert.shtml

• Hochladen des Antrags per SOAP und Übermittlung aller Daten und der PDF-Datei an IT-Portal

• Dabei Anmeldung mit persönlichem Zertifikat des Antragstellers

• IT-Portal prüft alles und hinterlegt signierte Datei mit Antragsdaten und Antragstelleridentität
   

• Skript auf meinem Zertifizierungsrechner kennt mein RA-Operator-Zertifikat, holt hinterlegte Dateien, holt Antragsdaten per RA-SOAP, vergleicht und prüft alles, vertraut der Identifizierung durch das IT-Portal, druckt fürs Archiv und genehmigt per RA-SOAP

• Kein ACME, aber vollautomatisches Beantragen und Ausstellen von Serverzertifikaten

• Verfahren ist vom DFN-PKI-Team geprüft

• Dokumentation: https://www.uni-muenster.de/WWUCA/de/howto-special-autocert-doku.shtml

Antragswege vor GÉANT TCS – Serverzertifikate (3)

• Erweiterung der Eigenentwicklung im IT-Portal (Punkt 2)

  • Anmeldung mit WWUCA-Zertifikat erforderlich

  • Anbindung an den selben Automatismus wie oben beim Musterskript (Punkt 4)
     

• Fast alle Serverzertifikate werden bereits vollautomatisch ausgestellt
   

• Live-Demo

Situation vor GÉANT TCS – Beschlüsse leitender Gremien

• Keine direkten Beschlüsse zur WWUCA

  • Etliche Beschlüsse und Regelungen, die nur mit einer eigenen CA umsetzbar sind

  • Explizites Verbot, ungepflegte Systeme (Windows XP, altes SSL/TLS usw.) an unser Netz anzubinden
     

• April 2021: Konkrete Zielvorgabe, dass alle Bediensteten alle E-Mails signieren

  • Zuerst die Bediensteten in der Universitätsverwaltung

  • Unmittelbare Folge:

    • Drei Verwaltungs-IT-Servicedesk-Mitarbeiter wurden Teilnehmerservice-Mitarbeiter

    • Mehrere hundert Video-Identifizierungen in der Verwaltung

    • Gleiche Mitarbeiter helfen bei der Einrichtung auf den Arbeitsplätzen

    • ⇨  Betreuung der Verwaltungsbediensteten in einer Hand

Situation vor GÉANT TCS – Anleitungen und Support

• Fast alle Antragswege sind ausführlich im WWW dokumentiert

• Ebenso der Einbau der Zertifikate in verbreitete Software

• https://www.uni-muenster.de/WWUCA/de/howto.html
   

• WWUCA hat eigene Telefonnummer (klingelt bei allen HPs) und E-Mail-Adresse

• 14 TS-Mitarbeiter, räumlich über die ganze WWU verteilt, können ebenfalls helfen

• Ebenso natürlich die normale IT-Hotline, Beratung usw.

Situation vor GÉANT TCS – Verzeichnisdienste

• Alle „Global“-E-Mail-Zertifikate, deren Besitzer der Veröffentlichung zugestimmt hatte,
  werden aus dem DFN-PKI-LDAP-Server in das zentrale Exchange-Adressbuch gespiegelt

• ebenso in das zentrale LDAP-System, das verschiedene zugangsbeschränkte LDAP-Server versorgt
   

• (Ein eigener öffentlicher „Adressbuch-LDAP-Server“, der ebenfalls daraus versorgt wird, war angedacht, wird aber jetzt erst realisiert)

Situation vor GÉANT TCS – Fazit

 
Das alles war bereits vorhanden ...
 
... bevor wir uns Gedanken über GÉANT TCS machen mussten ...

Überlegungen zur Migration (1)

• TCS wird alle 5 Jahre neu ausgeschrieben

  • Dienstangebot so weit reduzieren wie möglich, falls 2025 wieder migriert werden muss

• Was ist wichtig für Serverzertifikate?

  • ACME für Serverzertifikate ist ein Muss!

  • Es wird aber auch eine Alternative benötigt

• Was ist wichtig für Personenzertifikate?

  • WWU-Leitung fordert: Alle Mitarbeiter sollen bald alle E-Mails signieren

  • Identifizierung verursacht hohen Zeitaufwand

  • WWU hat 5.000 Mitarbeiter ...

  • Vereinfachte Identifizierung sehnsüchtig erwünscht

Überlegungen zur Migration (2)

• Gründliches Studium der TCS-Policy bezüglich Anforderungen an die Identitätskontrolle

  • Policies sehr abstrakt und interpretierbar, ganz anders als bei „Global“

  • „GÉANT TCS eScience Personal Certificates“ haben etwa gleiche Anforderungen wie „Global“

  • „GÉANT TCS Personal Certificates“ haben reduzierte Anforderungen (IGTF-Anforderungen entfallen)

    • Keine zwingende Ausweiskontrolle, andere Dokumente können ausreichen

    • Keine 39-Monats-Frist: Einmalige Identifizierung des Inhabers einer Kennung gilt unbefristet

    • Für neue Zertifikate reicht Passwortkontrolle, falls Kennung durchgehend dem Inhaber zugeordnet
       

• ⇨  Für unsere Zwecke (E-Mail, SSO-Login) sind „GÉANT TCS Personal Certificates“ perfekt

Evaluation der vorhandenen Identifizierungen (1)

• IT-Portal hat Zugriff auf Auszug aus Studierenden- und Mitarbeiter-DB

• Verschiedene Personenkreise sind unterschiedlich gut identifiziert

• Zugehörigkeit zu Personenkreisen konnten dem Auszug einfach hinzugefügt werden
   

• GÉANT TCS (non-eScience) Personal Certficates verlangen nur eine einfache Passwortkontrolle, wenn ein Account-Besitzer irgendwann einmal anhand von ausreichenden Dokumenten identifiziert wurde (eine Kontrolle eines Lichtbildausweises wird nicht verlangt) und seitdem durchgehend im Besitz des Accounts ist

• Das sollte bei vielen Uni-Angehörigen der Fall sein

• Genaue Nachforschungen nötig

Evaluation der vorhandenen Identifizierungen (2)

• Tabelle aller Personenkreise in Online-Office in unserer hausinternen Cloud erstellt

• Personal- und Studierendenverwaltung gebeten, für jeden Personenkreis die Dokumente einzutragen, die zwingend vorgelegt werden müssen, bevor man in den Personenkreis aufgenommen wird

  • Ansprechpartnerin in Personalverwaltung hat alle Abteilungen eingespannt

  • Überraschend große Kooperationsbereitschaft bei allen Stellen

• Nach nur zwei Monaten hatte ich alles zusammen – trotz über 100 Personenkreisen
   

• Dann konnte ich entscheiden, welche Identifizierungen ich für ausreichend im Sinne der Policy halte

• (DFN-PKI-Team sagt, dass ich entscheiden muss: DFN kann nicht alle Prozesse aller Unis prüfen)

• Bei Studierenden war meine Entscheidung knapp, bei allen anderen deutlich

• Ergebnis (letzter Stand): https://www.uni-muenster.de/WWUCA/Personenkreise-2022-05-09.pdf

Evaluation der vorhandenen Identifizierungen (3)

• ⇨  Bei ca. 90 % der Uni-Angehörigen reichen die vorhandenen Identifizierungen aus

  • bei den meisten Beamten, Angestellten, ordentlichen Studierenden

  • nicht aber bei Hilfskräften, Lehrbeauftragten, Gasthörern, Gastwissenschaftlern, ...
     

• Ebenso bei allen, die schon mal ein persönliches „Global“-Zertifikat erhalten haben
   

• Der kleine „Rest“ muss einmal einem TS-Mitarbeiter seinen Ausweis zeigen

  • Diese Ausweiskontrolle wird in Nutzerdatenbank/Identitätsmanagement vermerkt

  • Dafür ist ein IT-Portal-Modul schnell geschrieben

  • Kein Massenandrang zu befürchten, denn viele aus dem „Rest“ werden nie ein Zertifikat benötigen

Überlegungen zur Migration (3)

• SAML-Zugang zu Sectigo erlaubt keine Beschränkung auf Nicht-eScience-Zertifikate

  • SAML-Zugang darf also nur gewährt werden, wenn eScience-Identifizierungsanforderungen erfüllt

  • Verwendung des SAML-Zugangs würde alle Vorteile der non-eScience-Zertifikate zunichte machen

• Einzige brauchbare Alternative ist die REST-API

  • ⇨  Offensichtliche Lösung: Im IT-Portal SOAP-API durch REST-API ersetzen
     

• Zertifikatausstellung erlaubt, wenn ausreichend identifizierter Nutzer sich mit Passwort ausweist

  • IT-Portal muss wissen, welche Nutzer ausreichend identifiziert sind

  • IT-Portal kann sämtliche Kontrollen durchführen und alle Zertifikate vollautomatisch ausstellen

  • Weiterer Vorteil: Zustimmung zur Veröffentlichung kann eingeholt werden

Überlegungen zur Migration (4)

• Keine unnötigen Alternativen realisieren

  • Nutzer – und Teilnehmerservice – sollen ausschließlich das IT-Portal nutzen

  • Auch TS-Mitarbeiter bekommen keinen Zugang zum Sectigo Certificate Manager

  • TS-Mitarbeiter werden nur noch für Identitätskontrollen und Support benötigt
     

• Keine unnötigen Features nutzen oder gar anbieten

  • Große Teile der Sectigo-Möglichkeiten (Departments, eScience-Zertifikate, ...) bleiben ungenutzt

  • Wer weiß, was davon nach 2025 oder 2030 migrierbar wäre ...
     

• Nur HPs nutzen ausnahmsweise den Sectigo Certificate Manager:

  • Grundkonfiguration, Domainvalidierung, Zertifikatwiderrufe, ...

  • Einladung zu Codesigning-Zertifikaten

Überlegungen zur Migration (5)

• „Global“-Policy verlangt Widerruf von Zertifikaten ausgeschiedener Nutzer

  • Monatlich suche ich per Skript auf meinem Zertifizierungsrechner nach solchen Zertifikaten

  • Nach manueller Gegenkontrolle widerrufe ich manuell (Java-Oberfläche)

  • „TCS“-Policy scheint das nicht zu verlangen

    • Muss aber noch mal genau nachlesen (ist noch zu tun)

    • Ggf. vergleichbares Check-and-Revoke-Skript programmieren
       

• Widerruf auf Nutzerwunsch oder bei Kompromittierung

  • Einfach WWUCA kontaktieren

  • Nach Plausibilitätscheck durch HP manueller Widerruf mittels Sectigo Certificate Manager

Überlegungen zur Migration (6)

• Code-Signing-Zertifikate bei „Global“ sind Personen-/Gruppen-Zertifikate

  • Normales Antragsverfahren für Personen/Gruppen

• Überraschung: Code-Signing-Zertifikate bei „TCS“ sind Einrichtungszertifikate

  • Zertifikatnehmer (CN) ist die Universität als Ganzes

  • Keine Person, keine Gruppe, keine Orga-Einheit, nur Kontakt-Mail-Adresse

  • Extrem restriktiv vergeben: Anträge nur von Finanzverantwortlichen akzeptieren

  • Original-Sectigo-Einladungsverfahren verwenden

  • Das funktioniert und andere Realisierung lohnt nicht für 1 Zertifikat pro Jahr

Entwicklungsschritte (1)

• Ab August 2021 Teilnahme am DFN-PKI-Pilotbetrieb zur Einfühung von GÉANT-TCS

• Programmierung der IT-Portal-Funktionen, Reihenfolge nach Dringlichkeit
   

1. ACME-Konten

   • Keine eigene Rechteverwaltung aufbauen: Berechtigungen werden aus Netz-DB übernommen

   • Designentscheidung: ACME-Konten tragen einen FQDN als Namen, dieser legt die Rechte fest

   • Jeder Admin eines FQDN in der Netz-DB darf das gleichnamige ACME-Konto anlegen und verwalten

   • Jeder Admin kann weitere eigene FQDNs an das gleiche ACME-Konto hängen

   • Anmeldung im IT-Portal natürlich nur mit persönlichem Zertifikat
      

   • Unangenehme Entdeckung: REST-API-Antwortzeit steigt mit der Anzahl der ACME-Konten der WWU

Entwicklungsschritte (2)

2. Persönliche E-Mail-Zertifikate:

   • „Global“-Modul kopiert und API ersetzt

   • Zertifikat wird direkt abgeholt, PKCS#12-Datei direkt zum Heruntergeladen angeboten

     • Download PDF-Datei und Wiedereinstieg nach Zertifikatausstellung entfallen

     • Schlüsselspeicherung in DB und Key-Recovery-Möglichkeit entfallen (Nachrüstung wäre möglich)

     • Schlüsselerzeugung weiterhin durch das IT-Portal

   • Entscheidung: Antragsteller erhalten nur dann ein Zertifikat, wenn sie der Veröffentlichung zustimmen

     • Rektoratsbeschluss erlaubt Veröffentlichung dienstlicher Kontaktdaten aller Mitarbeiter in Personensuche, LDAP, Exchange usw. (Rechtsgrundlage: Wichtiges Interesse der WWU)

     • Zertifikate enthalten keine anderen Daten

     • WWUCA und Zertifikate dienen dem Interesse der WWU, nicht dem Privatinteresse unserer Nutzer

   • Spätere Revidierung denkbar (z. B. wenn Studierende zwingend Zertifikate benötigen)

Entwicklungsschritte (3)

3. Eintragung einer Ausweiskontrolle durch TS-Mitarbeiter

4. Unpersönliche Zertifikate:

   • Sectigo kennt keine unpersönlichen Zertifikate, nur persönliche ohne den Namen des Besitzers

     • (Undokumentiert: API lässt einfach GN und SN weg, wenn GN und SN nicht in CN enthalten)

     • (Aber in Sectigo-DB bleiben GN und SN gespeichert.)

   • Daher Antrag nicht mehr unter unpersönlicher Kennung, sondern unter Kennung des Besitzers stellen

   • Eine leicht modifizierte Kopie des Moduls für persönliche Zertifikate reicht aus

5. Server-Zertifikate ohne ACME

   • Analoge Überlegungen und Realisierung wie bei persönlichen Zertifikaten

   • Anmeldung im IT-Portal natürlich nur mit persönlichem Zertifikat

• Live-Demo

Kuriositäten und Ärgernisse

• Für Sectigo ist jede unterschiedliche E-Mail-Adresse im DN eine eigene „Person“

  • Die gleiche E-Mail-Adresse darf aber bei anderer „Person“ im Subject Alternative Name stehen
     

• Pro „Person“ und Profil nur zwei Zertifikate, ältere werden stillschweigend widerrufen!

• Werden Zertifikatanträge mit gleicher E-Mail, aber abweichendem GN oder SN gestellt,
  dann werden alle Zertifikate der „Person“ stillschweigend widerrufen!
  (Abweichende CNs sind kein Problem)
   

• Code-Signing-Zertifikate gibt es nur für die Uni als Ganzes
   

• Microsoft_UPN kann nicht mehr genutzt werden, daher schreiben wir die WWU-Kennung für das SSO jetzt als (funktionsfähige) E-Mail-Adresse <kennung+{ID}@uni-muenster.de> ins Zertifikat

Große Probleme mit PDF-Signaturen

• Problembereich Wurzelzertifikate (Verursacher: Adobe)

  • Sectigo-ECC-Wurzelzertifikat wird von Adobe nicht mitgeliefert – wie erwartet

  • Sectigo-RSA-Wurzelzertifikat wird von Adobe per „Richtlinieneinschränkung“ gesperrt

    • Selbst wenn man diese deaktiviert, wird sie beim nächsten Update wieder aktiviert

    • Man müsste komplett alle Updates verhindern – inakzeptabel
       

• Problembereich Unsinnige Zertifikatwiderrufe (Verursacher: Sectigo)

  • Automatisches Widerrufen alter Zertifikate beim Beantragen neuer Zertifikate macht archivierte Signaturen ungültig (bei E-Mails ärgerlich, bei aufzubewahrenden PDF-Dokumenten inakzeptabel)
     

• TCS-Zertifikate daher (anders als „Global“-Zertifikate) nicht für interne PDF-Signaturen geeignet

Überlegungen zum zukünftigen Vorgehen bei PDF-Signaturen

• PDF-Dokumente zur Weitergabe nach außerhalb (Zeugnisse, Bescheinigungen, Förderanträge, ...)

  • Wer solche PDFs signieren muss, wird mit qualifizierter Signaturkarte und notwendiger Hard- und Software ausgestattet (kaum teurer als spezielle PDF-Signierzertifikate, die von Adobe anerkannt werden, aber nicht von Behörden)

• PDF-Dokumente für rein WWU-interne Verwendung (Prüfprotokolle, Sitzungsprotokolle, ...):

  • TCS scheidet aus; Bindung an andere externe CA und deren Policy unnötig

  • Eine eigene PDF-CA war schnell im IT-Portal realisiert (fertiges CA-Skript war vorhanden)

  • Das Wurzelzertifikat dieser PDF-CA wird in alle Acrobat-Installationen der WWU integriert

  • Klickorgien oder Gruppenrichtlinien zum Ergänzen von Wurzelzertifikaten nötig

  • Wer (nur) solche PDFs signieren muss, holt sich ein Zertifikat der PDF-CA

• Soweit ausreichend, sollte nicht die PDF-Datei selbst signiert werden, sondern die E-Mail,
  mit der die PDF-Datei verschickt wird

Fazit

• Dank hervorragender Voraussetzungen hat die Einführung schnell und gut geklappt
   

• Die neuen Zertifikate werden gut angenommen

• „Global“-Zertifikat werden nur noch sehr vereinzelt nachgefragt
   

• Nächstes Ziel ist die Vollversorgung der Verwaltungsmitarbeiter

• Limitierender Faktor ist nicht mehr die Identifizierung, sondern Support und Schulung
   

• Für PDF-Signaturen sind TCS-Zertifikate (anders als Global-Zertifikate) völlig unbrauchbar
   

• Live-Demo, bis der Magen knurrt ...

Vielen Dank

• Rainer Perske
  perske@uni-muenster.de
  +49 251 83 31582
  https://perske.net

• Westfälische Wilhelms-Universität
  WWU IT
  Zertifizierungsstelle
  Röntgenstraße 7–13
  48149 Münster
  ca@uni-muenster.de
  +49 251 83 31590
  https://www.uni-muenster.de/WWUCA/