Beantragung persönlicher elektronischer Zertifikate bei Sectigo (unter DFN/Geant)

Link zur kurzen Anleitung hier. Dies ist nur eine lange Anleitung zur Beantragung persönlichen Zertifikaten bei dem externen Anbieter Sectigo von Nov2024. Falls Die Anleitung nicht stimmt, dann hat sich hat Sectigo die Webseite geändert. Bitte informiert mich dann.
Die Screenshots sind netterweise von einem Kollegen zur Verfügung gestellt (Danke!). Sie sind extra so klein gewählt, um alle Informationen mit wenigen Bildern wiederzugeben.
Sectigo ist ein internationales Security-Unternehmen, deshalb sind die Webseiten in Englisch.
ACHTUNG: der Nutzer macht einen Einzel-Vertrag mit Sectigo (s. EULA), DFN und Geant sind nur Vermittler. Anmeldung über diesen Link.

Zuerst muss man seine "Otto-von-Guericke-University Magdeburg" auswählen. Falls die Webseite nicht erreichbar ist, sperrt die Netzwerk/TLS-Firewall (Medizin-kampus?) oder Sectigo bzw. Shibboleth ist down. Die Webseiten können teilweise langsam sein. Der Link https://cert-manager.com/customer/DFN/ssl/sslsaml/login zeigt auf eine externe Webseite ohne "sectigo" im Domain-Namen, ist (Nov2024) von der RootCA "USERTrust RSA Certification Authority" Country "US" signiert. Normale Browser vertrauen dieser Seite und kennzeichnen dies durch ein grünes Schloss. Der Public-Key hat sich einige Male geändert, scheint seit März aber stabil zu sein. Der SSL-Fingerprint ändert sich natürlich etwa monatlich. Damit ruht die SSL-Security auf dem US-RootZertifikat. Man muss JavaScript eingeschaltet haben. JavaScript ist hauptverantwortlich für fast alle Sicherheitslücken des Browsers. Der Webseitenanbieter geht davon aus, dass er selbst nie gehackt wird, und der Nutzer nie auf Phishing-Seiten gelenkt wird, oder ihm ist die Sicherheit des Nutzers relativ egal. Die Webseite nutzt Javascript, um Nutzerdaten an Google weiterzugeben. Mit der Browsererweiterung NoScript kann man das einschränken und gewinnt etwas an Sicherheit. Zwischendurch wechselt die Webseite zu "https://service.seamlessaccess.org", wo man seine Uni unter der Teilnehmerliste auswählen kann. Ich empfehle "otto" einzutippen, dann findet man die Otto-von-Guericke-University. Diese Seite brauch ebenfalls JavaScript und ist von der RootCA "GlobalSign Root CA - R3" signiert. Der Browser wird auch diesem Anbieter vertrauen.

Jetzt werden wir auf den universitätseigenen IDP-Server umgelenkt. Der soll verhindern, dass das Passwort des Nutzers an fremde Anbieter gelangt. Gleichzeitig wird der Datenschutz erfüllt, denn man kann die übertragenen Daten einsehen und stimmt der Uebertragung zu. Das ist die DSGVO-Option "freiwillige Zustimmung". Zwingt Dich jemand, suche Hilfe bei dem Datenschutzbeauftragten.

Nutzername und Passwort (Kerberos) des zentralen OVGU-Accounts eintragen.
Es werden Nutzerdaten an Sectigo übertragen, so auch Deine Standard-EMAIL-Adresse. Diese ist für das Zertifikat nicht änderbar. Das Zertifikat des IDP-Servers ist auch von Sectigo erstellt. Der IDP-Server leitet wieder auf den Sectigo-Server zurück und bestätigt diesem Deine Identität.

Name, Organization und Email muss passen.
Wenn hier ein Fehler "You are not allowed to self enroll." kommt, wurde Dein Personalausweis noch nicht vom IT-Service geprüft (geht nur persöhnlich vor Ort, VC gilt als unsicher) oder Du hast keine Rechte als Uni-Mitglied eingetragen.


Profil "GEANT Personal email ..." wählen. Jetzt taucht erst der weitere Fragen-Teil auf.

"730 days" wählen (länger geht nicht).
Nach den 730 Tagen ist Dein Key abgelaufen und Du sollst ihn nicht weiter verwenden. Falls Du aber danach für diesen Key verschlüsselte Dateien und Mails besitzt oder bekommst, die Du weiterhin entschlüsseln können möchtest, musst Du Dir den alten Key aufbewahren, oder die Dateien entschlüsseln bzw. umschlüsseln. Wählst Du kürzere Laufzeiten, musst Du öfter das Zertifikat und damit den Schlüssel wechseln.

Enrollment Method = "Key Generation" wählen. Dein Browser läd ein JavaScript, dass die Key-Erzeugung (Key=Schlüssel) für Dich übernimmt. Das ist einfacher in der Bedienung. Niemand prüft, ob zeitweise weitere Funktionen in diesem Script eingebaut sind, die zum Leaken Deines Keys führen. Es prüft auch niemand, ob der erzeugte Key Schwächen hat (Stichwort: Random generators). Diese Methode sollte aus Sicherheitsgründen innerhalb der Uni von eigenen Fachkräften zur Verfügung gestellt und gepflegt werden. Das kostet jedoch dauerhaft personellen Aufwand, der nicht verfügbar ist. Daher gibt es hier diese günstige Variante.
Bei der Alternative "CSR" kannst Du mit einem separaten und erprobten Programm (z.B. OpenSSL) einen Key erzeugen und den Request unabhängig vom Browser und Internet erzeugen. Das ist der sicherste Weg, erfordert aber Wissen zum Umgang mit elektronischen Zertifikaten. Das kann und sollte man sich aneignen, wenn man Cryptologie nutzt. Ausserdem braucht man mit CSR dann keine alten Schlüssel aufheben, denn den CSR kann man samt alten Key wiederverwenden. Dann bleibt der Schlüssel/Key gleich und alte Dateien sind weiterhin entschlüsselbar. Streng genommen braucht man für Verschlüsselung kein Zertifikat. Das Zertifikat bestätigt nur, dass Du (oder jemand anderes) Deinen Public Key zusammen mit Deiner EMAIL und Deinen Namen dem Zertifizierer vorgelegt hat. Und damit hat man die Verantwortung, diese Zuordnung selbst zu prüfen, auf jemand oder besser einige andere deligiert, die und deren Arbeitsqualität Du i.d.R. nicht kennst. Um das Problem kompromitierter Vertrauensketten und schlecht funktionierender Widerrufe (Revokations) zu reduzieren, werden Laufzeiten von Zertifikaten zunehmend verkürzt. Das macht mehr Arbeit für User und Support.

"RSA-2048" wählen, aber darauf achten, dass das alle eure Mail-Partner auch können. Ggf diese fragen oder testen und dann andere passende Algorithmen wählen.
Alternativ kann eine schwerer zu brechende Schlüssellänge RSA-4096 gewählt werden. Ältere Software kann u.U. nicht mit RSA-4096 umgehen bzw. die volle Performance unterstützen. Die Schluessel sind doppelt so lang und die Rechenzeit steigt je nach Operation um das etwa 3 oder 7-fache. RSA ist durch grosse Quantencomputer (QCs) knackbar. Bisher reicht die QC-Groesse aber nicht und es ist wegen der nötigen Quanten-Kohärenz oder der nötigen Fehlerkorrektur fraglich, ob QCs mit 2048 nutzbaren Qbits je gebaut werden können. Es gibt andere Crypto-Alternativen, wo noch nicht bekannt ist, ob die von QCs knackbar sind. Sectigo bietet statt RSA noch "EC - P-384" und "EC - P-256" (Elliptic Curve Encryption, auch ECC). Diese koennen (laut Wikipedia) ebenfalls durch grosse QCs geknackt werden. Beachte, dass das zur Verschlüsselung genutzte Gerät sicher gegen Fremdzugriff sein muss, korrekte Algorithmen implementiert hat und zuverlässige Zufallszahlen generiert. Da das Endgerät üblicherweise nicht sicher gegen Fremdzugriff ist (Telemetrie, Auto-Updates u.a.), macht die Erhöhung der Schlüssellänge wenig Sinn.
Hier geht es daher um einfach bedienbare Sicherheit mit (sicherheits-mindernden) Kompromissen. Das zu erreichende Ziel ist, dass die beteiligten EMail-Programme die Zusammenarbeit mit dem gewählten Schlüsselformat akzeptieren. Die Uni will Euch hier vorzugsweise vor Phishingmails und einfachen Betrug schützen. Trotzdem darf man auf einem (unsicheren) Endgerät dem grünen Schloss im EMAIL-Programm nicht blind vertrauen. In der Security-Kette hängen zu viele Co-Lieferanten, die Fehler machen oder dessen Security untergraben wurde.

Wähle einen Schlüssel-Schutz-Algorithmus. Das ist dafür da, dass andere Leute, die auf Dein Dateisystem zugreifen können, Deine elektronische Signatur nicht gleich missbrauchen können. Andere müssen zusätzlich Deine Tastatureingaben abfangen oder anderwertig an dieses Passwort kommen (2FA). Du merkst beim importieren oder signieren der Mails, wenn Deine Algorithmus-Auswahl nicht zu Deinem EMAIL-Programm passt. Aeltere Systeme kennen meist TripleDES (3DES) aber vielleicht kein AES, neuere Systeme ab dem Jahr 2000 kennen vermutlich AES aber verweigern sich vielleicht nach 2019 TripleDES. Das NIST (National Institute of Standards and Technology, eine US-Behörde) hat 3DES laut Wikipedia 2019 wegen CVE-2016-2183 für die Nutzung nach 2023 untersagt. Aber Softwarehersteller können träge sein oder müssen der NIST-Behörde nicht folgen. Für ein sicheres (Offline-)System wäre der Schlüsselschutz irrelevant. Hier als Kompromiss probiere es erst mit AES.

EULA lesen, speichern und als Verstanden und Akzeptiert abhaken. Submit.
Wegen der Länge der der EULA (5952 Worte, englisch, 41kB) finde ich den Dienst nicht akzeptabel, aber es ist eine Nutzer-Entscheidung. Die Forschungsstelle Recht im DFN hat 2022 die Stellungnahme von GEANT von 2020 zu Sectigo bewertet und findet den Datenschutz nicht perfekt aber im Ergebnis DSGVO-konform. Dabei ist der Brexit nicht berücksichtigt.

Das Schlüssel-Generieren braucht einige Sekunden Zeit. Im Browser mehr als ausserhalb, längere Schlüssel brauchen exponentiell mehr Zeit als kürzere Schlüssel. Das ist so gewollt.

Warte auf die Meldung "Your certificate has been successfully generated."
Im Download-Ordner des Browsers findest Du danach eine Datei "certs.p12" (ungetestet von anderer Uni übernommen). In der p12-Datei steckt Dein mit Passwort verschlüsselter Schlüssel und das erstellte Zertifikat.
Ab hier stoppt diese Doku, weil es viele Programme gibt und ich aus Security-Gründen nicht das allgemein übliche Betriebssystem verwende und damit die Probleme des nutzerspezifischen EMail-Programmes nicht kenne. Gehe (zurück) auf die Supportseiten und folge den Hinweisen für die üblichen Anwendungen oder frag Deinen zuständigen OS-Admin.
Sectigo liefert Zertifikate, wo Dein Browser oder Mailprogramm in der Regel das Rootzertifikat schon kennt. Das kann auch ein Sicherheitsproblem sein, weil da viele Anbieter aus vielen Ländern und Organisationen drinstehen. Du bist also Deinem OS- bzw. Browser-Hersteller und dessen Auswahl ausgeliefert. Da dass Vertrauen zu Root-Anbietern sich ändern kann (z.B. durch Kriege), solltest Du diese updaten (lassen). Das beisst sich mit dem, was ich oben zu sicheren Systemen sagte. Man kann sich das aber schönreden. Fakt ist, dass wir hier fundamentale Probleme haben, die nicht verschwinden. Besser aber eben unbequem ist es für die Security, die Root-Liste auf die notwendige zu reduzieren und bei Bedarf selbst die nötigen Root-Zertifikate zu verwalten. Tut man das, wird der Browser viele Webseiten nicht darstellen wollen. Also macht das fast niemand. Aber seit Euch dieser Tatsache im richtigen Moment wenigstens bewusst. Bei echter Security hat man das unsichere Handy oder den PC zum internetten und ein separates Offline-Gerät zum signieren/verschlüsseln (z.B. PhotoTAN-Gerät beim Online-banken als "Stand der Technik"). Selbst wenn man alles richtig macht, bleibt da noch das Problem mit der fehlenden mathematischen Beweisbarkeit der Algorithmen-Sicherheit. In diesem Sinne -- nichts ist sicher.

Ich hoffe, obige Bemerkungen helfen dem ein oder anderen. Ich kann aus Zeitgründen, weil man mit neuen Zertifikaten, (zweit-)alte Zertifikate ungültig macht und weil man keine Testzertifikate erstellen darf, nicht alles selbst testen. Rechtschreib- und Sachkorrekturen gern per EMAIL an mich (Joerg.Schulenburg) senden. Wer eine Stoppuhr hat, kann mir auch mal die Zeiten für die Key-Generierung zuschicken. Ich freue mich, wenn ich die Anleitung nicht umsonst geschrieben habe und Feedback bekomme und ergänze diese Doku dann.
Weitere Infos rund um elektronische Zertifikate ca.ovgu.de.
Zurück zur URZ-Webseite Beantragung eines Nutzerzertifikates (nur aus internen Netzen erreichbar).
Allgemeine Gedanken zur Security in english.