Schwerpunkt: Verschlüsselung mit S/MIME

1. Wie arbeitet S/MIME?
2. Was ist eine Zertifizierungsstelle (Certificate Authority CA)?
3. Was sind S/MIME Zertifikate?
4. Worin besteht der Unterschied zwischen einem Root-Zertifikat und einem Unternehmenszertifikat?
5. Was muss ich überprüfen, falls eine der Aktionen nicht erfolgreich ausgeführt werden kann?
6. Was muss ich überprüfen, falls das Verschlüsseln/Verifizieren nicht funktioniert?
7. Was muss ich überprüfen, falls das Entschlüsseln/Signieren nicht funktioniert?
8. Welche rechtlichen Rahmenbedingungen existieren bzgl. elektronischer Signaturen?

Wie arbeitet S/MIME?

Bei der Verschlüsselung mit S/MIME werden auf Sender- und Empfängerseite je zwei unterschiedliche Zertifikate verwendet:
  • Ein öffentliches Zertifikat zum Verschlüsseln von ausgehenden Mails und/oder zum Verifizieren von eingehenden signierten Mails.
  • Ein privates Zertifikat zum Entschlüsseln von eingehenden Mails und/oder Signieren von ausgehenden Mails.
Bei S/MIME wird über ein streng hierarchisches Vertrauenssystem gearbeitet. Den gemeinsamen Vertrauensanker bildet das Wurzel- bzw. Basis-Zertifikat (Root-CA-Zertifikat oder auch Root Certificate).

Was ist eine Zertifizierungsstelle (Certificate Authority CA)?

Eine Certificate Authority (CA) hat folgende Aufgaben:
  • Ausstellen von Zertifikaten/Zertifizieren von Schlüsseln
  • Sperrlisten pflegen und veröffentlichen
Beim Ausstellen eines Zertifikates bindet die CA den Namen eines Benutzers an dessen öffentlichen Schlüssel. Die CA bürgt dafür, dass der Name und der öffentliche Schlüssel im Zertifikat zu derselben Person gehören. Die CA stellt sicher, dass sich der Antragsteller für ein Zertifikat gegenüber der CA identifiziert.
Es ist deshalb notwendig, dass alle beteiligten Personen dem öffentlichen Schlüssel der CA vertrauen. Wird der private Schlüssel der CA kompromittiert, müssen alle Anwenderzertifikate neu ausgestellt werden.
Die zertifizierten öffentlichen Schlüssel müssen veröffentlicht werden. Dies erfolgt für gewöhnlich in einem LDAP-Verzeichnisdienst.
Eine CA ist mit einer Ausweisstelle vergleichbar. Daher sollte eine Umgebung, in der eine CA betrieben wird, entsprechend gesichert sein. Näheres finden Sie im Whitepaper PKI-Grundlagen.

Was sind S/MIME Zertifikate?

Zertifikate werden von einer Certificate Authority erstellt und verwaltet. Ein Zertifikat verknüpft Daten eines kryptographischen Schlüssels (oder Schlüsselpaares, bestehend aus öffentlichem und privatem Schlüssel) mit Daten des Inhabers und einer Zertifizierungsstelle, sowie weitere Spezifikationen wie Version, Gültigkeitsdauer, Verwendungszweck und Fingerprint.
Häufig verwendete Dateinamen-Erweiterungen:
  • Datei im/nach PKCS#7 Standard: .p7b (enthält öffentlichen Schlüssel)
  • Datei im/nach ITU-T‚ X.509 Standard: .cer (enthält öffentlichen Schlüssel)
  • Datei im/nach PKCS#12 Standard: .pfx, .p12 (enthält privaten und öffentlichen Schlüssel)

Worin besteht der Unterschied zwischen einem Root-Zertifikat und einem Unternehmenszertifikat?

Wenn Sie unter iQ.Suite serverbasiert mit S/MIME arbeiten möchten, benötigen Sie zwei Zertifikate im PKCS#12-Format: Das Root-Zertifikat (root.pfx) ist das private Zertifikat der Root-Zertifizierungsstelle (Root-CA). Es wird ausschließlich dazu verwendet, um die Kopien des Unternehmenszertifikates (company.pfx) zu signieren.

In der Regel dient eine Root-CA nur der Erstellung und/oder Signatur von Benutzerzertifikaten. Der Partner, der dieser Root-CA vertraut, vertraut auch allen Zertifikaten und Unter-Zertifizierungsstellen, die von ihr signiert wurden. Daher muss nur einmal einem Zertifikat vertraut werden: dem Zertifikat der Root-CA.

Um eine Mail zu signieren, benötigt der Absender ein privates Zertifikat mit seiner eigenen E-Mail-Adresse. Das Unternehmenszertifikat (company.pfx) dient in unserem Falle als Vorlage, um mit Hilfe der Root-CA ein solches individuelles Benutzerzertifikat zu erstellen:
Es wird eine Kopie des Unternehmenszertifikates erstellt, die E-Mail-Adresse ausgetauscht und von der Root-CA signiert. Dieser Vorgang wird für jeden Benutzer wiederholt, für den noch kein eigenes Zertifikat in der Zertifikatsdatenbank zur Verfügung steht.

Was muss ich überprüfen, falls eine der Aktionen nicht erfolgreich ausgeführt werden kann?

Prüfen Sie, ob die Passworte für das root.pfx und das company.pfx, die Sie in der Konfiguration eingepflegt haben, mit denen übereinstimmen, welches Sie beim Erstellen gewählt haben.
Prüfen Sie, ob folgende Dateien im Verzeichnis iqsuitesmimedata liegen:
  • root.pfx
  • company.pfx
  • Prüfen Sie, ob diese Pfade in der Konfiguration entsprechend angepasst sind.
  • Prüfen Sie, ob alle Zertifikate gültig sind (Ablaufdatum!)

Was muss ich überprüfen, falls das Verschlüsseln/Verifizieren nicht funktioniert?

  • Lotus Notes/Domino:
    • Prüfen Sie, ob Sie für den Empfängers ein Zertifikat vorhanden ist, d.h. in der Zertifikatsdatenbank (g_cert.nsf) oder ob das Zertifikat über ein LDAP-Verzeichnis erreichbar ist.
    • Prüfen Sie, ob das eigene Unternehmens-Zertifikat mit dem richtigen Pfad eingetragen ist (wird für die Initialisierung des Jobs benötigt).
  • Microsoft Exchange/SMTP:
    • Prüfen Sie, ob Sie ein öffentliches Zertifikat des Empfängers in das Verzeichnis GrpDatasmimedata importiert haben. Wenden Sie sich in diesem Fall an unseren Support.

Was muss ich überprüfen, falls das Entschlüsseln/Signieren nicht funktioniert?

  • Lotus Notes/Domino:
    • Prüfen Sie, ob sich Ihr Unternehmenszertifikat im iqsuitesmime-Verzeichnis befindet
    • Falls Sie signieren wollen, prüfen Sie, ob auch das Aussteller-Zertifikat root.pfx im iqsuitesmime-Verzeichnis vorhanden ist. Für beide Zertifikate müssen die richtigen Passwörter eingegeben sein.
  • Microsoft Exchange/SMTP:
    • Prüfen Sie, ob sich das private Unternehmenszertifikat in dem Verzeichnis GrpDatasmimedata befindet.
    • Prüfen Sie, ob in der Konfiguration der S/MIME-Einstellungen unter S/MIME Optionen die Pfade für die Zertifikate richtig gesetzt sind.

Welche rechtlichen Rahmenbedingungen existieren bzgl. elektronischer Signaturen?

Die elektronische Signatur ist durch mehrere Rechtsvorschriften geregelt:
Das bürgerliche Gesetzbuch erlaubt den Ersatz der schriftlichen Form durch die elektronische Form, soweit durch Gesetz nichts anderes bestimmt ist (§ 126 BGB). Die elektronische Form ist gewahrt, wenn dem Dokument der Name hinzugefügt und mit einer qualifizierten elektronischen Signatur versehen wird (§ 126a BGB). Die qualifizierte elektronische Signatur stellt höhere Anforderungen. Stattdessen können die Vertragspartner eine andere Form vereinbaren, also insbesondere eine einfachere elektronische Signatur wählen (§ 127 BGB).
Das Signaturgesetz unterscheidet zwischen der elektronischen Signatur an sich, die daher häufig als einfache elektronische Signatur bezeichnet wird, der fortgeschrittenen elektronischen Signatur und der qualifizierten elektronischen Signatur. Letztere erfordert ein gültiges Zertifikat und die Erzeugung mit einer Signaturerstellungseinheit. Das ist im Regelfall ein Lesegerät für Chipkarten, ergänzt um geeignete Verschlüsselungssoftware. Die Anforderungen an Chipkarten mit Signaturfunktionalität werden durch DIN V 66291-1 bestimmt. Die Zertifikate werden im Bundesamt für die Sicherheit in der Informationstechnik (http://www.bsi.de) gesammelt.

Die für qualifizierte elektronische Signaturen zugelassenen Kryptoalgorithmen werden von der Regulierungsbehörde für Telekommunikation und Post genehmigt und veröffentlicht. Dort sind auch die fÃür eine qualifizierte elektronische Signatur zugelassenen Produkte aufgelistet. Zertifizierungsdienste sind genehmigungsfrei, aber anzeigepflichtig. Bei der Anzeige ist darzulegen, dass und wie die gesetzlichen Anforderungen (finanzielle Deckungsvorsorge, Zuverlässigkeit, Fachkunde) erfüllt sind.

Zusammenfassend lässt sich im Hinblick auf die serverbasierte Verschlüsselung mit S/MIME und der iQ.Suite folgendes sagen:

Wer rechtsverbindlich signieren muss, benötigt sogenannte qualifizierte Zertifikate. Diese Zertifikate sind an natürliche, juristische Personen gebunden und dürfen sich u.a. nur in Ihrem Besitz befinden (z.B. auf einer Smartcard). Mit diesen Zertifikaten darf nur der Benutzer selbst signieren und kein Vertreter (z.B. ein Server), da diese Zertifikate passwortgeschützt sind.

iQ.Suite Crypt erzeugt die benutzerspezifischen Zertifikate am Server. Daher sind diese nicht personengebunden. Aus diesem Grund können die Zertifikate bei Einsatz von iQ.Suite Crypt auch selbst mittels iQ.SuiteTrust oder mit Hilfe eines anderen Programms zur Zertifikate-Generierung erstellt werden. Es muss nicht auf die Zertifikate eines Trustcenters zurückgegriffen werden.