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

Rainer Perske

ca. 75 Min.

Diese Datei mit dem Browser öffnen:
https://www.uni-muenster.de/IT.RainerPerske/2022-09-14.EinfuehrungTCS.html

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/