1. Warum E-Mail Signatur?
Im Prinzip ist die E-Mail Signatur für alle von Interesse. Egal ob Unternehmen, Privatanwender oder Regierungsbehörden. Sie alle müssen der Identität ihres Kommunikationspartners vertrauen. Denn jeder möchte sich auf die sichere und vertrauliche Zustellung von Nachrichten und den enhaltenen Daten verlassen können.
Durch die Verwendung vertrauenswürdiger digitaler Zertifikate, die auf der überprüften Identität einer Person ausgestellt sind, bestätigt eine Signatur die Herkunft und Authentizität einer Nachricht. Erstellen und verwenden von Signaturen bildet damit den Grundstein für die Vertraulichkeit der Informationen.
Grundsätzlich gibt es zwei gängige Methoden zur E-Mail-Verschlüsselung und zur Signierung verwendet werden: S/MIME und PGP. S/MIME (Secure/Multipurpose Internet Mail Extensions) gibt es seit 1995, PGP (Pretty Good Privacy) gab es bereits etwas früher, so ab 1991. Sozusagen alte Hüte. Weder S / MIME noch PGP wurden bisher geknackt und werden von Experten als sicher eingestuft. Sowohl S / MIME als auch PGP basieren auf demselben Prinzip, der sogenannten Hybridverschlüsselung. Es gibt einen privaten und einen öffentlichen Schlüssel (Zertifikate bei S / MIME). Um jemandem eine verschlüsselte E-Mail zu senden, benötigen Sie den öffentlichen Schlüssel des Empfängers und Ihren eigenen privaten Schlüssel. Obwohl das Funktionsprinzip beider Methoden vergleichbar ist, sind S / MIME und PGP nicht miteinander kompatibel. Man ist also letztendlich gezwungen, entweder alle Kommunikationspartner von dem verwendeten Standard zu überzeugen oder zwei Spuren anzusteuern und S / MIME und PGP-Variable zu verwenden.
1.1. Signierung
Allerdings: S/MIME bietet zusätzlich zur Verschlüsselung noch eine Signierfunktion. Hierbei bleibt eine Nachricht für alle sichtbar, es wird allerdings eine kryptographische Signatur hinzugefügt, die vom Empfänger verifiziert werden kann. Ist die Signatur in Ordnung, bedeutet dies, dass der Inhalt der E-Mail nicht verändert wurde. Aber für eine E-Mail-Verschlüsselung mit S/MIME spricht noch ein weiterer Vorteil: Das Verfahren ist bereits fester Bestandteil vieler Mail-Programme, sei es auf dem Desktop oder auf mobilen Endgeräten
1.2. Zertifikatsklassen
Klasse 1: Es wird nur überprüft, ob die hinterlegte E-Mail-Adresse existiert.
Klasse 2: Enthalten neben der E-Mail-Adresse auch den Namen sowie das Unternehmen bzw. die Organisation. Hierbei wird schriftlich bestätigt, dass die Angaben auch korrekt sind
Klasse 3: Es wird zusätzlich der Handelsregisterauszug beziehungsweise der Personalausweis überprüft.
Klasse 4: Erfordert darüber hinaus ein persönliches Erscheinen bei der Zertifizierungsstelle zwecks Verifizierung bestimmter Originaldokumente
2. Umsetzung in SAP
2.1. Anlegen einer SMIME Identität
Eine SMIME Identität repräsentiert eine Email Adresse im SAP System. Diese Email Adresse sollte einem User zugeordnet sein, der als Absender einer Email fungiert.
Transaktion STRUST
STRUST -> Umfeld –> SMIME Identitäten
Neuer Eintrag für eine SMIME Identität (repräsentiert meist einen User)
- S/MIME Beispiel ZSTRUC
- Anwendung Beispiel ZMS
Logischer Name wird leer gelassen (Wird gefüllt über das Einlesen des Zertifikats)
Dadurch entsteht im Trust Manager ein neuer Eintrag SMIME ZMS.
2.2. PSE zu einer SMIME Identität anlegen
Markieren von SMIME ZMS und rechte Maustaste drücken.
PSE anlegen:
- Name: Max Mustermann (Wichtig)
- Org.: Leer
- Firma: Abteilung
- CA: O=munich enterprise sotfware GmbH, L=Groebenzell, S=Bayern, C=DE, EMAIL=max.mustermann@munich-enterprise.com (Wichtig, dass der String genauso eingetragen wird)
- O = Unternehmen
- L = Ort
- S = Region
- C = Land
- Email = Mailadresse (welche zertifiziert wird)
- Algorithmus: RSA mit SHA 256 (wichtig)
- Schlüssellänge: 2048 (wichtig)
2.3. Erstellung einer Zertifikatsanfrage
Jetzt ist im SAP System eine SMIME Identität vollständig angelegt. Das Schlüsselpaar mit „Privater Schlüssel“ und „Öffentlicher Schlüssel“ (Zertifikatsanforderung) sind im SAP System hinterlegt.
Wichtig: Diese SMIMIE Identität sollte nach der Beantragung eines Zertfikats nicht mehr gelöscht und neu erstellt werden. Es könnte sonst sein, das das Zertifikat nicht mehr zu dem erstellten Schlüsselpaar passt.
Transaktion STRUST
- Doppelklick aus die PSE der SMIME Identität
- Danach Zertifikatsanforderung erzeugen
- Ergebnis: Zertifikatsrequest (CSR – Datei)
Dieser Datei kann man dann über den Button in eine lokale Textdatei sichern.
2.4. Zertifikat bestellen
Mit dieser Zertifikatsanforderungen kann man bei den Zertifikatsanbietern (CA) ein Zertifikat bestellen. Nach erfolgter Validierung erhält man das Zertifikat mit dem entsprechenden Root Zertifikat und ein oder mehreren Zwischenzertifikaten.
In unserem Beispiel haben wir das Zertifikat bei der PSW Group bestellt. Der ausstellende CA ist in unserem Fall Certum:
Bestellung mit CSR Datei
2.5. Zertifikat in das SAP System importieren
2.6. Root Zertifikat und Zwischenzertifikate
Als erstes müssen das Root Zertifikat und die entsprechenden Zwischenzertifikate im SAP System hinterlegt werden.
Wichtig: Werden mehrere Email Adressen bei der gleichen Autorisierungsstelle (CA) zertifiziert. Müssen das Root- und die Zwischenzertifikate nur einmal hinterlegt werden.
2.6.1. Zertifikate auf der Datenbank anlegen (Root und Zwischenzert.)
Transaktion STRUST
Menü->Zertifikat->Datenbank
- Anlegen
- Für alle Zerifikate
2.6.2. Zertifikate einlesen
- Markieren System PSE.
- Danach Zertifikat importieren über Button.
- Nur Root- und Zwischenzertifikate jeweils importieren.
- Diese Zertifikate sind das in der Zertifikatsübersicht enthalten.
2.6.3. Zertifikate in der Datenback hinterlegen
Diesen Schritt für jedes Zertifikat durchführen.
Doppelklick auf das gewünschte Zertifikat.
Menü-> Zertifikat->Exportieren
- Dann Datenback wählen
- Mit dem entsprechend vorher angelegten Eintrag ausfüllen
2.7. SMIME Zertifikat einlesen
Als letztes wir das Zertifikat für die entsprechende Emailadresse eingelesen.
Transaktion STRUST
Doppelklick aus die PSE der SMIME Identität:
- Zertifikatsantwort einlesen
- Sichern aus lokaler Datei
- Zertifikat einlesen
- Speichern
Jetzt können signierte Mails versendet werden.
2.8. Exportieren des privaten Schlüssels einer SMIME Identität
Der Private Schlüssel ist notwendig, wenn man die Zertifikate in weiten Mailsystemen wie zum Beispiel Outlook verwenden möchte.
Sie können auf einem ABAP Stack durch Eingabe der Transaktion STRUST > Environment > Display SSF Version überprüfen, ob die SAPCRYPTOLIB installiert ist und in welcher Version. Alternativ können Sie auf der Kommandozeile den Befehl sapgenpse ausführen.
Exportieren des PSE Files in ein PKCS#12 File:
sapgenpse export_p12 –p
Beispiel:
sapgenpse export_p12 -p sapssl.pse test.p12
Mit dem freien OpenSSL kann man nun den private und public key extrahieren:
openssl pkcs12 -in -out -nodes
Beispiel:
openssl pkcs -in test.p12 -out output.txt -nodes
2.9. Verwendung in weiteren SAP Mandaten oder Systemen
2.9.1. Root und Zwischenzertifikate
2.9.1.2. Weitere Mandaten
Die Root- und Zwischenzertifikate gelten systemweit. Diese müssen in weiteren Mandanten nicht angelegt und importiert werden.
2.9.1.3. Weitere Systeme
Die Root- und Zwischenzertifikate müssen in weitere SAP System eingespielt werden. Hier geht man vor wie unter Punkt 2.6 beschrieben.
2.9.2. SMIME Identität anlegen
In weiteren Mandant oder in weiteren Systemen muss dann, wie unter Punkt 2.1 beschrieben eine SMIME Identität angelegt werden.
Achtung: nur Punkt 2.1 ausführen.
2.9.3. SMIMIE PSE Exporten
Die angelegte SMIME Identität mit eingelesenem Zertifikat wir nun exportiert.
Transaktion STRUST
Doppelklick aus die PSE der SMIME Identität.
Dann in lokaler Datei speichern.
2.9.4. SMIMIE PSE im neuen Mandanten / System importieren
Transaktion STRUST
Menü->PSE->Importieren
PSE Datei aus lokaler Datei auswählen.
Menü->PSE->Sichern als
Dann SMIME markieren und die angelegte SMIMIE Identität auswählen.
Speichern!
