Persönliche Nutzerzertifikate zum Signieren und Verschlüsseln von E-Mail
cp luh-ca.cnf luh-ca.my
Die Leibniz Universität Hannover stellt im Rahmen einer DFN-weiten Public Key Infrastruktur (PKI) allen Mitgliedern und Angehörigen der LUH Zertifikate zur Verfügung.
ja | |
ja | |
ja | |
ja |
Im Rahmen von DFN-PKI-G2, einer DFN-weiten Public Key Infrastruktur (PKI), können über das LUIS von allen Angehörigen und Mitgliedern der Leibniz Universität Hannover Zertifikate im X.509-Format für folgende Anwendungszwecke beantragt und bezogen werden:
Die Zertifizierungstelle (Certification Authority, CA) wird durch den DFN betrieben, die Bearbeitung der Zertifikatsanträge erfolgt durch die im LUIS angesiedelte Registration Authority (RA). Für alle Fragen im Zusammenhang mit Zertifizierung steht die RA der LUH-CA für Sie als Ansprechpartner zur Verfügung.
Voraussetzung für das Signieren und Verschlüsseln von Mails in AppleMail ist das Importieren der Zertifikatsdatei in die Schlüsselbundverwaltung von macOS. Dazu wird die Schlüsselbundverwaltung geöffnet und über "Ablage" > "Objekte importieren" die Zertifikatsdatei ausgewählt. Das Zertifikat sollte nun in der Kategorie "Meine Zertifikate" angezeigt werden.
Mail verfassen
Erhalt einer signierten / verschlüsselten E-Mail
Prüfen einer Signatur einer empfangenen E-Mail
Die Anleitung wurde mit Mozilla Thunderbird 78.11.0 erstellt.
Nach der Installation des User-Zertifikats in Outlook können ggf. Probleme mit dem Versenden von "leeren E-Mails" entstehen. Bitte beachten Sie dazu die Hinweise des Mail-Teams.
Nutzerinnen und Nutzer dürfen den geheimen Schlüssel oder ein digitales Zertifikat, das den geheimen Schlüssel enthält, nicht auf Webmail-Angebote hochladen.
In Sogo-Webmail ist diese Funktionalität deaktiviert.
Siehe auch §5 Sicherheit der E-Mail-Richtlinie.
Die Anleitung wurde mit Adobe Reader DC Version 2022.001.20085 auf Windows 10 erstellt (Hinweise für ältere / Nicht-DC-Versionen sind mit enthalten).
Im ersten Schritt muss das Wurzelzertifikat der DFN-PKI heruntergeladen werden, damit Signaturen von Zertifikaten der DFN-PKI im PDF-Viewer auf ihre Gültigkeit überprüft werden können. Laden Sie das Wurzelzertifikat hier herunter und speichern Sie es ab. Fahren Sie dann mit der Schritt-Für-Schritt-Anleitung fort.
Als nächstes wird das Nutzerzertifikat importiert, um damit eigene PDFs zu signieren. Halten Sie dafür ihr Nutzerzertifikat im .p12-Format bereit und fahren Sie mit der Schritt-Für-Schritt-Anleitung fort.
Alle Vorarbeiten sind abgeschlossen, Sie können nun PDFs signieren. Im Folgenden wird Schritt-Für-Schritt gezeigt, wie das geht.
Im Falle einer älteren Adobe Reader Version oder der ESR-Version (betrifft auch die OPSI-Version vom Adobe Reader) kann das Wurzelzertifikat in Schritt 1 nicht importiert werden, da der Adobe Reader das .crt-Format nicht kennt. In diesem Falle muss das Zertifikat erst in das .p7b-Format konvertiert werden. Im Folgenden wird erklärt, wie das geht. Nachdem Sie diesen Sonderschritt abgeschlossen haben, fahren Sie in der obigen Anleitung fort.
Wir verwenden die luh-ca.cnf.
Für zusätzliche Namen (Subject Alternate Names) im Zertifikat die luh-ca.cnf anpassen:
cp luh-ca.cnf luh-ca.my
Anschließend die Änderungen einbringen:
$ diff luh-ca.cnf luh-ca.my 74c74 < # subjectAltName = @alt_names --- > subjectAltName = @alt_names 82,83c82,83 < DNS.1 = example1.example.uni-hannover.de < DNS.2 = example2.example.uni-hannover.de --- > DNS.1 = example1.luis.uni-hannover.de > DNS.2 = example2.luis.uni-hannover.de
Erstellen des CSR, die grundlegend erforderlichen Angaben (inkl. des Common Names) werden nach Ausführen des Befehls erfragt:
$ openssl req -config luh-ca.cnf -new -keyout server-key.pem -out server-req.pem Generating a RSA private key ..........................................................................................................................+++++ ........................+++++ writing new private key to 'server-key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (=DE) [DE]: State or Province Name (=Niedersachsen) [Niedersachsen]: Locality Name (=Hannover) [Hannover]: Organization Name (=Leibniz Universitaet Hannover) [Leibniz Universitaet Hannover]: Common Name (Servername FQDN) []:example.luis.uni-hannover.de
Überprüfen eines CSR:
$ openssl req -text -noout -verify -in server-req.pem -inform PEM verify OK Certificate Request: Data: Version: 1 (0x0) Subject: C = DE, ST = Niedersachsen, L = Hannover, O = Leibniz Universitaet Hannover, CN = example.luis.uni-hannover.de Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:c9:71:f7:b5:7b:ac:33:5b:ad:96:71:d7:2a:21: […] 97:9f Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment Signature Algorithm: sha256WithRSAEncryption 76:a6:ca:1e:76:35:f9:3d:5b:e0:7f:a6:66:bc:41:ce:85:99: […] 79:10:de:37
Die DFN-PKI bietet einen öffentlichen Verzeichnisdienst (LDAP-Server) an, in der die vom Inhaber zur Veröffentlichung freigegebenen Nutzerzertifikate im Sicherheitsniveau Global zu finden sind (siehe auch DFN-PKI-FAQ).
Das LDAP-Verzeichnis kann in E-Mail-Clients eingebunden werden.
Die Anleitung wurde mit Mozilla Thunderbird 78.11.0 erstellt.
Dateiendungen bei Zertifikaten sind nicht vorgegeben und spezifizieren nur die Kodierung. Ob es sich dabei um ein Zertifikat, eine Zertifikatsanfrage, oder ein Schlüssel handelt, muss man über den Dateinamen zu erkennen geben.
Zertifikate:
$ openssl x509 -in server-cert.der -inform DER -out server-cert.pem -outform PEM
RSA-Schlüssel:
$ openssl rsa -in server-key.der -inform DER -out server-key.pem -outform PEM
Zertifikate:
$ openssl x509 -in server-cert.der -inform PEM -out server-cert.pem -outform DER
RSA-Schlüssel:
$ openssl rsa -in server-key.der -inform PEM -out server-key.pem -outform DER
PKCS12 ist ein Containerformat welches Zertifikate und Schlüssel beinhalten kann. Zum Trennen in die Bestandteile:
Client-Zertifikat extrahieren:
$ openssl pkcs12 -clcerts -nokeys -in test-client1-ca-2019.p12 -out test-client1-ca-2019-cert.pem Enter Import Password:
$ head -n 8 tests/conf/test-client1-ca-2019-cert.pem Bag Attributes localKeyID: 55 84 55 EC 44 16 9E B8 05 AE 9B EB C7 BB 55 D5 B2 AC A6 C1 subject=C = DE, O = Testinstallation Eins CA, CN = PN: Teilnehmerservice Test RAID 60
issuer=C = DE, O = Test, CN = Test Client 1 Issuing CA
-----BEGIN CERTIFICATE----- MIIFJjCCBA6gAwIBAgIMIX3zIme/leh2t+pTMA0GCSqGSIb3DQEBCwUAMD8xCzAJ
Zertifikatskette extrahieren:
$ openssl pkcs12 -cacerts -nokeys -in test-client1-ca-2019.p12 -out test-client1-ca-2019-chain.pem Enter Import Password:
$ grep "subject" tests/conf/test-client1-ca-2019-chain.pem subject=C = DE, O = Test, CN = Test Client 1 Issuing CA subject=C = DE, O = Test, CN = Test Intermediate CA subject=C = DE, O = Test, CN = Test Root CA
Der Schlüssel ist mit einem Kennwort geschützt, welches in einem zusätzlichen Schritt entfernt werden kann:
$ openssl pkcs12 -nocerts -in test-client1-ca-2019.p12 -out test-client1-ca-2019-key.pem Enter Import Password: Enter PEM pass phrase: Verifying - Enter PEM pass phrase:
$ head -n 5 test-client1-ca-2019-key.peme Bag Attributes localKeyID: 55 84 55 EC 44 16 9E B8 05 AE 9B EB C7 BB 55 D5 B2 AC A6 C1 Key Attributes: <No Attributes> -----BEGIN ENCRYPTED PRIVATE KEY----- MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQIFa7SsLOW2rMCAggA
Schlüssel-Kennwortschutz entfernen:
$ openssl rsa -in test-client1-ca-2019-key.peme -out test-client1-ca-2019-key.pem Enter pass phrase for test-client1-ca-2019-key.peme: writing RSA key
$ head -n 2 tests/conf/test-client1-ca-2019-key.pem -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAzchh+cIkhmx9cQHg+CcqKPo6/8OYi7wmL+japhJQ6CKtZCcO
Zertifikatsinformationen anzeigen:
$ openssl x509 -in server-cert.pem -inform PEM -text Certificate: Data: Version: 3 (0x2) Serial Number: 23:3e:03:59:e4:c7:55:e7:28:59:42:2b Signature Algorithm: sha256WithRSAEncryption Issuer: C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA Validity Not Before: Jul 27 07:44:11 2020 GMT Not After : Oct 29 07:44:11 2022 GMT Subject: C = DE, ST = Niedersachsen, L = Hannover, O = Leibniz Universitaet Hannover, OU = Leibniz Universitaet Hannover IT Services, CN = www.luis.uni-hannover.de Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:ce:e3:a1:c4:f1:e5:71:02:6a:3e:15:5b:2b:c3: ... 24:23 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 Policy: 1.3.6.1.4.1.22177.300.30 Policy: 1.3.6.1.4.1.22177.300.1.1.4 Policy: 1.3.6.1.4.1.22177.300.1.1.4.7 Policy: 1.3.6.1.4.1.22177.300.2.1.4.7 X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Key Identifier: AF:7E:23:0B:1B:8F:BC:95:B9:15:50:7F:23:78:9F:F0:00:6C:9B:7F X509v3 Authority Key Identifier: keyid:6B:3A:98:8B:F9:F2:53:89:DA:E0:AD:B2:32:1E:09:1F:E8:AA:3B:74
X509v3 Subject Alternative Name: DNS:www.luis.uni-hannover.de, DNS:luis.uni-hannover.de, DNS:www.rrzn.uni-hannover.de, DNS:rrzn.uni-hannover.de, DNS:www.rrzn-handbuecher.de, DNS:rrzn-handbuecher.de X509v3 CRL Distribution Points:
Full Name: <link http: cdp1.pca.dfn.de dfn-ca-global-g2 pub crl cacrl.crl>URI:http://cdp1.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.crl
Full Name: <link http: cdp2.pca.dfn.de dfn-ca-global-g2 pub crl cacrl.crl>URI:http://cdp2.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.crl
Authority Information Access: OCSP - URI:http://ocsp.pca.dfn.de/OCSP-Server/OCSP CA Issuers - URI:http://cdp1.pca.dfn.de/dfn-ca-global-g2/pub/cacert/cacert.crt CA Issuers - URI:http://cdp2.pca.dfn.de/dfn-ca-global-g2/pub/cacert/cacert.crt
CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 46:A5:55:EB:75:FA:91:20:30:B5:A2:89:69:F4:F3:7D: 11:2C:41:74:BE:FD:49:B8:85:AB:F2:FC:70:FE:6D:47 Timestamp : Jul 27 07:44:14.364 2020 GMT Extensions : none Signature : ecdsa-with-SHA256 30:46:02:21:00:8E:8B:B7:1B:06:72:82:92:5E:6E:8C: 98:18:3E:F2:28:6D:9F:84:68:95:2E:AF:BD:EB:AE:1E: A1:07:28:20:C1:02:21:00:AB:88:B3:F4:3A:84:F5:45: AA:23:A4:20:D4:9A:3C:13:BE:13:A7:AC:39:13:46:E5: 65:BA:E0:31:88:03:6C:E4 ... Signature Algorithm: sha256WithRSAEncryption 74:f5:68:24:28:a6:67:86:b6:52:b1:4d:f4:15:ca:8f:33:e7: ... 24:ab:8a:ab -----BEGIN CERTIFICATE-----
Das Zertifikat, der private Schlüssel und die Zertifikatskette müssen auf dem System an der richtigen Stelle eingebracht werden. Dies wird hier beispielhaft für ein "Debian Buster"-System getan.
Auf dem Server den (temporären) Zielordner vorbereiten:
$ mkdir /home/<user>/certs
Zertifikat und Schlüssel per scp auf das System kopieren (falls noch nicht geschehen):
$ scp server-key.pem server-cert.pem <user>@<zielhost>:/home/<user>/certs/.
Damit der private Schlüssel ohne Passwortabfrage von den Applikationen gelesen werden kann, erstellen wir eine Kopie des Schlüssels ohne Passwortschutz:
$ cd /home/<user>/certs
$ openssl rsa -in server-key.pem -out server-key_nopass.pem
Auf dem Server werden das Zertifikat und der Schlüssel an die richtige Stelle verschoben und die Zugriffsrechte angepasst:
$ cp /home/<user>/certs/server-cert.pem /etc/ssl/certs/.
$ cp /home/<user>/certs/server-key_nopass.pem /etc/ssl/private/.
$ chown root:root /etc/ssl/certs/server-cert.pem /etc/ssl/private/server-key_nopass.pem
$ chmod 0644 /etc/ssl/certs/server-cert.pem
$ chmod 0600 /etc/ssl/private/server-key_nopass.pem
Damit die Zertifikatskette bis zum Zertifikat vollständig ist, muss diese auf dem System abgespeichert werden:
$ cd /etc/ssl/certs
$ wget -O dfnglobal2-chain.pem pki.pca.dfn.de/dfn-ca-global-g2/pub/cacert/chain.txt
Entfernen der temporären Dateien:
$ rm -r /home/<user>/certs/
Soll der Schlüssel (und Zertifikat) im Home-Verzeichnis nicht entfernt werden und auch außerhalb von /etc/ssl aufbewahrt werden, müssen auch hier dementsprechende Zugriffsrechte gesetzt werden (insbesondere für die _nopass-Datei, da diese nicht mehr durch ein Passwort geschützt ist):
$ chown root:root /home/<user>/certs/server-key.pem /home/<user>/certs/server-key_nopass.pem /home/<user>/certs/server-cert.pem
$ chmod 0644 /home/<user>/certs/server-cert.pem
$ chmod 0600 /home/<user>/certs/server-key.pem /home/<user>/certs/server-key_nopass.pem
Das Zertifikat und der private Schlüssel sind nun auf dem Server hinterlegt und können im nächsten Schritt von den jeweiligen Applikationen verwendet werden (Im nächsten Drop-Down-Menü am Beispiel von Apache2).
In der entsprechenden .conf-Datei von Apache werden folgende Einträge vorgenommen (Setzt die Installation der Zertifikate/Schlüssel voraus, wie im Dropdown-Menü "Bereitstellen der Notwendigkeiten (Beispiel: Debian) beschrieben):
SSLCertificateFile /etc/ssl/certs/server-cert.pem SSLCertificateKeyFile /etc/ssl/private/server-key_nopass.pem
Ein Neustart des Apache2-Dienstes ist ggf. notwendig:
$ systemctl restart apache2
Der Status des Apache2-Dienstes kann wie folgt eingesehen werden:
$ systemctl status apache2
Für die Fehlersuche kann der vollständige Log des Apache2-Dienstes hilfreich sein:
$ journalctl -u apache2
Mit der kryptographischen Signatur stellt der Absender einer Mail Informationen zur Verfügung, die Empfängern die Verifikation seiner Identität ermöglichen. Es reicht aus, dass der Versender ein Nutzerzertifikat hat.
Weitere Informationen und Anleitungen zur Verwendung finden sich auf der Seite Sichere E-Mail.
Mit der kryptographischen Signatur stellt der Absender einer Mail Informationen zur Verfügung, die Empfängern die Verifikation seiner Identität ermöglichen. Es reicht aus, dass der Versender ein Nutzerzertifikat hat.
Mit der Verschlüsselung stellt der Absender einer Mail sicher, dass diese nur vom Empfänger gelesen werden kann. Sender und Empfänger müssen ein Nutzerzertifikat haben
Weitere Informationen finden sich auf der Seite Sichere E-Mail.
Ein digitales Zertifikat ist ein Datensatz, dessen Authentizität und Integrität durch kryptografische Verfahren geprüft werden kann. Es entspricht einem digitalen Ausweisdokument, welches ein Schlüsselpaar bestehend aus einen öffentlichen und einem privaten Schlüssel eindeutig einer Person oder einem Server zuordnet. Eine Zertifizierungsstelle beglaubigt diese Zuordnung. Zertifikate werden eingesetzt um die Sicherheit von Daten zu gewährleisten (Verschlüsselung) oder die Identität des Kommunikationspartners (Server-Authentifizierung, Mail-Signatur) eindeutig bestätigen zu können.
Eine Person oder ein Server identifiziert sich durch den Besitz des privaten Schlüssels, der zu dem im Zertifikat beglaubigten öffentlichen Schlüssel passt.Der private Schlüssel eines Zertifikates verbleibt beim Besitzer des Zertifikates, er muss gut geschützt werden und darf nicht öffentlich werden. Geht der private Schlüssel verloren oder wird kompromittiert, muss das Zertifikat gesperrt werden.
Der öffentliche Schlüssel eines Zertifikates muss den Kommunikationspartnern bekannt gemacht werden, damit diese anhand des Schlüssels überprüfen können, ob das Gegenüber tatsächlich im Besitz des geheimen Schlüssels ist. Der öffentliche Schlüssel von A wird vom Kommunikationspartner B genutzt, um die Authentizität der Signatur von A zu prüfen oder um Daten für B zu verschlüsseln.
Ein Zertifikat enthält neben der Zuordnung des Schlüsselpaares zum Besitzer noch weitere Informationen wie z.B. Gültigkeitsdaten, die ausstellende Zertifizierungsstelle, Einsatz-Zweck des Zertifikates (Mailverschlüsselung, Signatur, Authentifizierung, ...)
Nutzerzertifikate sind personenbezogene Zertifikate. Diese Zertifikate können in Mailprogrammen zum Signieren und Verschlüsseln von E-Mails eingesetzt werden. Durch die digitale Signatur einer E-Mail können die Empfänger sicher sein, dass die absendende Person auch tatsächlich diejenige ist, als die sie sich ausgibt.
Serverzertifikate dienen der Identifizierung des Servers. Durch sie lässt sich für die Klienten sicherstellen, wirklich mit dem Server verbunden zu sein dessen Adresse angewählt wurde. Nur nur der "echte" Server kann das korrekte Zertifikat präsentieren.
Jedes Zertifikat enthält die Signatur der Zertifizierungsstelle, die dieses Zertifikat ausgestellt hat. Dadurch kann die Kette aller beteiligten Zertifikaten verfolgt werden, bis hin zu einem Wurzelzertifikat, dem vertraut wird.
Wurzelzertifikate werden von sicheren Trust-Centern ausgestellt, die sich durch sehr hohe Sicherheitsstandards auszeichnen und die regelmäßigen Qualitätskontrollen unterzogen werden. Die meisten Browser, Mailprogramme und viele andere Anwendungsprogramme bringen schon bei Installation eine Vielzahl integrierter vertrauenswürdiger Wurzelzertifikate mit. Auch die Zertifikate der DFN-PKi im Sicherheitsniveau global sind über das bereits vorintegrierte Wurzelzertifikat der T-Systems Business-Services in dieser vertrauenswürdigen Zertifikatskette mit einbezogen.
In Browsern (Firefox, Chrome, …) wird in der URL-Leiste eine gesicherte verschlüsselte Verbindung i.d.R. mit einem Schloss-Symbol angezeigt. Durch Klicken auf das Schloss-Symbol können weitere Informationen zum Zertifikat angezeigt werden.
In Mailprogrammen wird z.B. beim Erhalt einer signierten und/oder verschlüsselten Nachricht ein (Brief-)Siegel-Symbol angezeigt. Durch Klicken auf das (Brief-)Siegel-Symbol können weitere Informationen zum Zertifikat angezeigt werden.
Zertifikatswarnungen Ihres Browsers sollten Sie ernst nehmen und die Webseite vor der gewarnt wird gegebenenfalls lieber nicht besuchen. Bei Fragen und Unsicherheiten zu diesem Thema wenden Sie sich gerne an die RA im LUIS.
Typische Warnmeldungen könnten sein:
Das Zertifikat ist abgelaufen
Das Zertifikat wurde widerrufen
Das Zertifikat wurde für einen ganz anderen Server ausgestellt
Das Zertifikat ist selbst-signiert, d.h. der Besitzer des Zertifikats hat dieses selbst unterschrieben. Solche selbst-signierten Zertifikate sollten nur für Testzwecke, aber nicht für öffentliche Server eingesetzt werden.
Der Browser oder das Mailprogramm kennen die Zertifizierungsinstanz (Certification Authority, CA) nicht, die das Zertifikat ausgestellt hat. Das kann daran liegen, dass das Wurzelzertifikat oder eines der Zwischenzertifikate fehlen. Die Zertifikatskette muss vollständig sein und bei einem Wurzelzertifikat enden, dem vertraut wird. Fehlt in der Kette ein Zertifikat, kann keine vollständige Verifizierung stattfinden.
Die Zertifizierungsstelle (CA) arbeitet als vertrauenswürdige Instanz, die eine eindeutige, zweifelsfreie Zuordnung zwischen einem Schlüsselpaar (öffentlicher und privater Schlüssel) und einer Person oder einem Rechner herstellt.
Der Fingerprint ist eine eindeutige Zahl, die einem Zertifikat zugeordnet ist. Die Zahl selbst ist nicht Teil des Zertifikates, sondern lässt sich aus dem Inhalt berechnen (Hash-Verfahren). Selbst, wenn sich der Inhalt des Zertifikates nur um ein Zeichen ändert, erhält man eine andere Zahl. Daher benutzt man den Fingerabdruck zur Überprüfung von Zertifikaten. So können Sie z.B. die auf den Webseiten der DFN-PKI veröffentlichten Fingerprints mit denen des in Ihrem Browser geladenen DFN-Root-Zertifikates vergleichen. Halten Sie den ganzen Internet-Verkehr für unsicher, dann können Sie sich natürlich auch telefonisch den Fingerprint durchgeben lassen.