OvGU-Logo

SSL/TLS/SMIME-Zertifikate der Otto-von-Guericke-Universität Magdeburg

Dieser Service (Teilnehmerservice TS) dient der Erstellung elektronischer Zertifikate (z.B. EMAIL-SMIME, Webserver-HTTPS) für Mitglieder der Otto-von-Guericke-Universität Magdeburg nach den Richtlinien der Zertifizierungsinstanz des Vereins zur Förderung des Deutschen Forschungsnetzes e.V. (www.pki.dfn.de).

ACHTUNG! folgende Antrags-Weblinks ändert sich u.U. jährlich. Benutzen Sie bitte diese Webseite als Einstieg/Bookmark

Beantragung eines S/MIME-Zertifikats für EMAIL-Signatur

Persönliche EMAIL-Zertifikate via Anbieter DFN/Geant/Harica können und dürfen nur für der ovgu.de-EMAILs ausgestellt werden. Zertifikate ohne Personenbindung sind wegen der Anbieter-Policy nicht erlaubt.

Beantragung eines SSL/TLS-Zertifikats für Server

Zertifikate können nur für der OvGU gehörenden Domains (ovgu.de und uni-magdeburg.de) ausgestellt werden und müssen DFN-satzungsgemäß der universitären Forschung dienen. Global verankerte Zertifikate werden an verschiedenen Stellen veröffentlicht, d.h. die betreffenden Server sind mit der Zertifikatserstellung sofort weltweiten Angriffen ausgesetzt.
ACHTUNG: sobald den URZ-PKI-Kollegen zeitlich möglich, wird die Beantragung auf ein automatisches Verfahren (ACME) umgestellt. Die jetzige händische Beantragung ist eine Übergangslösung. LetsEncrypt als Ausweichlösung hat einen vergleichbaren Sicherheitslevel.

Erzeugen eines CSR-Requests mit OpenSSL und Test des Zertifikates (ab 2007)

Dies ist eine minimale rudimentaere Anleitung. Im Web finden Sie u.U. bessere zu Ihrer Anwendung passende Anleitungen. Generierung und Hochladen des CSR-Antrags ist sicherer als die von Anbietern oft angebotene Schlüsselgenerierung im Browser (Sicherheit kostet).

 1) Lesen Sie Policy "DFN-Community" der www.pki.dfn.de
 2) Schluessel erzeugen, falls nicht bereits vorhanden
    openssl genrsa -out rsa4096.key 4096  # linux-manual: man genrsa
    # -rand ~/.gnupg/random_seed wenn moeglich (bessere Zufallszahl) 
    # -des3 nur fuer verschluesselten Key (Passphrase benoetigt)
    # alte Schluessel und CSRs koennen ggf. wiederverwendet werden
    # Zugriffsrechte einschraenken! z.B. chmod u=rw,go= rsa4096.key
 3) Certificationrequest generieren (PKCS#10-Zertifikatantrag), falls nicht bereits vorhanden
    openssl req -new -out rsa4096.csr -key rsa4096.key \
    -subj "/GN=Max/SN=Mustermann/CN=Max Mustermann/emailAddress=max.\
mustermann@ovgu.de/OU=Abteilung/O=Otto-von-Guericke-Universitaet Magdeburg/C=DE"
    # keine Umlaute verwenden! (ä=ae,ö=oe,...)
    # Gruppen und Pseudonyme muessen mit CN "GRP: ","PN: ", "GRP - " oder "PN - " beginnen
    # Anm: GRP/PN-Zertifikate koennen nur bei DFN-Community beantragt werden
    # Server: -subj "/CN=foo1.ovgu.de/O=Otto-von-Guericke-Universitaet Magdeburg/C=DE"
    # optional alternative Server-Namen:      (zugefuegt 2023-07)
    # since OpenSSL 1.1.1 -addext "subjectAltName = DNS:foo1.ovgu.de, DNS:foo2.ovgu.de"
    #   bei Usern DN.CN=Titel Vorname Name (nur wie im Ausweis! ä=ae usw.)
    # CAs ordnen SAN evl. um und aendern CN (z.B. Harica 2025)
    # - challenge.pwd=xxxx
    openssl req -noout -text -verify -in rsa4096.csr # ggf. altes CSR pruefen
    # Fingerprint notieren
    openssl req -noout -modulus -in rsa4096.csr | openssl sha1 -c
 4) Zetifikatsantrag einreichen (.csr,.req oder .pem)
    # neu2017: Online-Antrag (Links s.o.) ausfuellen und ausdrucken.
    # neu2022: Online-Antrag (Links s.o.) ausfuellen
    Zertifizierung durch die CA (CSR zu CRT/P7B/PKCS#7)
    # rsa4096.crt speichern (ggf. combined KEY+CRT as PKCS#12)
 5) Zertifikat (.crt oder .pem) pruefen und einspielen, z.B: 
    openssl x509 -noout -text -in rsa4096.crt  # show cert-content
    # fuer SSL-Server (siehe ssl.conf SSLCertificateFile)
    export CFG=/usr/local/apache/conf    # FC6: /etc/httpd/conf.d/
    cp rsa4096.key $CFG/ssl.key/server.key
    cp rsa4096.pem $CFG/ssl.crt/server.crt  # von CA-signiert ggf. CA-Kette anhaengen
    ### CentOS-6.4: see /etc/sysconfig/httpd + /etc/httpd/conf.d/ssl.conf
    cp rsa4096.key /etc/pki/tls/private/localhost.key
    cp rsa4096.pem /etc/pki/tls/certs/localhost.crt
    # copy chain to /etc/pki/tls/certs/server-chain.crt
    # Datei-Zugriffsrechte fuer httpd beachten! nutze chroot + user nobody
    # Wenn abweichend, bitte EMAIL mit Korrektur an mich
    # fuer Nutzerzertifikate (entsprechend Anwendung/App)
    # ToDo: minimal encrypt/decrypt/signatur von Files mit openssl
    # ToDo: replace Apache by universal stunnel-Anleitung
 6) Webserver mit Zertifikat nach Restart testen
    openssl s_client -connect www.meinserver.de:443 -showcerts
    # es muss die gesamte Zertifikatskette angezeigt werden
    # die Zertifikatskette kann meist an das Zertifikat gehaengt werden

FAQ - häufige Fragen

Q: Wozu dienen elektronische Zertifikate?
A: Zertifikate sollen sicher stellen, dass ein (öffentlich) verfügbarer Public-Key zu einem angegebenen Besitzer gehört. Sie sind ein elektronisches Dokument, welches die Verbindung eines Public-Keys mit seinem Besitzer (bzw. ein Textstring, der diesen beschreibt), meist auch dem Zweck und einem Gültigkeitszeitraum über seinen Hash per Signatur beglaubigt. Es soll die aufwendige einmalige händische Prüfung von Public-Keys durch den Nutzer (wie bei ssh und gpg) durch Automatische Prüfungen über Zertifikate höherer Instanzen ersetzen. Der Signaturherausgeber wird in der Regel wiederum ein Zertifikat besitzen, wodurch eine Kette entsteht. Am Ende der Kette steht ein selbstsigniertes (Root-)Zertifikat. Diesem und allen untergeordneten Zertifikaten wird vom Nutzer, Betriebssystem oder der Software vertraut, im Sinne dass die Zugehörigkeit korrekt geprüft wurde und kein weiterer Zugriff insbesondere auf den Privat-Key der Instanzen durch unbefugte Dritte erfolgt ist. Dieses System ist anfällig für unterschiedliche Probleme, denen man sich bewusst sein sollte (z.B. Widerrufslisten, Software-Bugs, Fehlverhalten, uvm).

Q: Machen Zertifikate das Internet sicher?
A: Kommt drauf an. Alle am Schlüsselaustausch beteiligten Komponenten müssen ebenfalls sicher sein. Dazu gehört Deine Hardware, Dein Betriebssystem, Dein Browser, die Root-CAs, Deine Software-Zulieferer, deren Zulieferer usw. Das ist nie 100% gewährleistet. Hauptproblempunkte dabei sind Dein Betriebssystem, i.d.R. aus einem Land das Anbieter verpflichtet, für seinen Geheimdienst Dein Gerät oder Deine Daten (z.B. Schlüssel) zu kompromitieren ohne es Dir zu verraten. Auch der Browser hat Funktionalitäten, die wegen der Komplexität der Sicherheit nicht dienlich sind (z.B. Scriptsprachen für dynamische Inhalte). Da Du das Drumherum für Krypto dringend benötigst, helfen Dir Zertifikate allein nicht wirklich weiter. Daher ist die Antwort ehrlicherweise eher "leider nein" oder "nicht genug".

Q: Kann ich Krypto sicherer machen? Wie?
A: Benutze für wichtige Sachen (viel Geld, Deine Gesundheit) einen zusätzlichen dedizierten Krypto-Rechner zum Ver-/Entschlüsseln/Prüfen mit aufs nötigste reduzierter Software, mit dem Du nichts anderes als Krypto machst, d.h. nicht im Internet "surfst". Schalte auf diesem Gerät alle nicht benötigten oder gefährliche Funktionen (z.B. Javascript) ab. Reduziere dort die Liste vertrauenswürdiger Root-Zertifikate auf die für Dich notwendigen. Schalte für dieses Gerät automatische Updates ab, da über diesen Weg auch infizierte oder angreifbare Software eingeschleust werden kann. Besser, Du hängst das Gerät nicht ans Internet. Bringe den Private-Key am besten nie auf unsichere Geräte.
Ja, das macht Aufwand. Sicherheit kostet (Aufwand/Mühe). Der Kauf von Sicherheitsleistungen/Software wird das Problem i.d.R. nicht beseitigen.

Q: Bekomme ich hier Qualifizierte Signaturen?
A: Nein. Aber Du bekommst hier Fortgeschrittene Signaturen. D.h. die Krypto-Mathematik ist die Gleiche. Der technische Aufwand ist gleich, aber der regulatorische Aufwand bzw die Bürokratie ist geringer. Wenn sich alle Partner vorher darauf geeinigt haben, können damit auch Verträge unterzeichnet werden. Deshalb muss auch bei unseren Fortgeschrittenen Zertifikaten Dein Ausweis geprüft werden. Siehe auch DFN-PKI FAQ rechtliche Grundlagen (von 2021).

Q: Warum wird hier so viel gewarnt? Woanders lese ich nichts darüber.
A: Als Mitverantwortlicher fühle ich mich verpflichtet, auch den Laien auf die realen Gefahren hinzuweisen. Im Internet findet man viele Falschinformationen, verkürzte Problemhinweise oder es werden Probleme nicht erwähnt, um die Sicherheit im Internet zu beschönigen oder einfach mangels besseren Wissens. Nach mehr als 20 Jahren ist meine Erfahrung "Sicherheit ist schwierig" und "Der Teufel steckt im Detail". In den IT-Nachrichten bzw nach Recherchen liest man immer mal wieder von aufgetretenen Sicherheitsproblemen. Oft ändern sich in Folge dieser Probleme und mit dem Wunsch nach Vereinfachung und Einsparung dann Methoden, Regeln, Empfehlungen, die dann nur andere Probleme befördern. Das ist eher ein ewiger Wettlauf ohne finale Lösung. Die wachsenden Schlüssellängen sind nicht gemeint, diese braucht man, um dem technischen Fortschritt stand zu halten. Aber die verkürzten Laufzeiten von Zertifikaten als Kostentreiber nebst automatischer Neuausstellung zur Kostensparung sind ein typisches Symptom des Problems Schlüsselverlust und nicht funktionierenden Widerrufsmanagement. Die Folge ist eine Schwächung der Zuordnungsprüfung und Vorfälle wie die von jabber.ru 2023 mit erfolgreicher Man-in-the-middle-attack, vor die genau diese TLS-Krypto-Technologie schützen sollte und (mit HTTP Public Key Pinning (HPKP)) auch hätte schützen können.

Aktuelles+Historie:

Fussnoten/Hinweise

Author: Jörg Schulenburg 2004-2025, please disable JavaScript for more security and privacy, this site is "No-Script/No-Style/No-CSS/No-Cookie"-compatible and available without encryption in case your TLS is broken. (gpg-signature.asc: ToDo)