How-to sapgenpse

Wenn man sich im SAP-Umfeld mit Zertifikaten beschäftigen muss, und dies ist früher oder später immer der Fall ;-), kommt man sehr schnell, direkt oder indirekt, mit dem Kommandozeilentool sapgenpse in Kontakt. Dieser Artikel beschreibt, wie und wozu man sapgenpse sinnvoll einsetzen kann.

Einleitung

Bei SAP werden Public-Key Zertifikate in einer Personal Security Environment (PSE) gespeichert.

Es ist eine Umgebung, in der sowohl vertrauenswürdige, öffentliche Zertifikate als auch der private Schlüssel des Besitzers zweckgebunden gespeichert werden. Daher sollte nur der Besitzer der Informationen Zugriff auf seine PSE haben. Die PSE eines Benutzers oder einer Komponente befindet sich normalerweise in einem geschützten Verzeichnis im Dateisystem oder auf einer Smartcard.

Die Zweckbindung besteht zum Beispiel darin, dass das SAP-System sowohl als Server als auch als Client agiert. Daher sieht SAP von Hause aus schon gewisse Trennungen vor.

PSE-Arten

Da wären zum einen die SAPSSLS, die zur Anwendung kommt, wenn der SAP Anwendungsserver als Webserver agiert und die Anfragen verschlüsselt per HTTPS ausliefert.

Das SAP-System selber, verwendet die SAPSYS PSE um digitale Signaturen anzulegen und zu verifizieren. Damit können aber keine Informationen verschlüsselt werden.

Für eine verschlüsselte Netzwerkverbindung wird die SAPSNC verwendet, die z. B. die SAP Protokolle RFC und DIAG absichern kann. Darauf, auf SNC, setzt auch Single Sign-On (SSO) auf.

Das SAP-System kann sich, beim Austausch von Informationen, auch als Client verhalten, wenn es einen anderen Server anspricht. Dafür gibt es zwei PSE:

Der Anwendungsserver verwendet die anonyme Client-PSE (SAPSSLA) für die Verbindung mit einem anderen Web-Server, wenn nur eine serverseitige Authentifizierung verwendet wird. Er verwendet sie nicht für seine eigene Authentifizierung.

Demgegenüber wird die Standard-SSL-Client-PSE (SAPSSLC) verwendet, um sich selbst bei anderen Web-Servern zu authentifizieren.

Vielleicht zum besseren Verständnis: Beim Aufruf dieser Webseite, verwenden Sie auch eine anonyme Verbindung. Wenn Sie sich beim SAP Supportportal mit einem Zertifikat authentifizieren, dann entspricht dass der Standard-SSL-Client-PSE.

PSE mit sapgenpse pflegen

Die Pflege einer PSE wird man mit einem ABAP-System normalerweise mit der Transaktion STRUST durchführen. Es gibt aber Situationen, in der die STRUST nicht die gewünschte Funktion bietet, mit der sapgenpse dies aber sehr wohl möglich ist. Ein Beispiel ist der Export von Zertifikaten mit privatem Schlüssel.

Die Grundfunktionalität wird dabei von der CommonCryptoLib ausgeliefert. Sie kann als Teil des Kernels separat aktualisiert werden. Das kann dann notwendig werden, wenn man einen stabilen Kernel in seiner SAP Umgebung selten auf einer höheren Version aktualisiert.

In diesem Zuge sollte man sich regelmäßig den SAP Hinweis 1848999 durchlesen.

PSE anlegen – sapgenpse gen_pse

Sobald man auf der Kommandozeile mit dem Tool sapgenpse arbeitet, muss als erstes die Variable SECUDIR gepflegt werden. Die folgenden Beispiele gehen von einem *NIX artigen System aus, aber das Prinzip bei Windows ist das gleiche.

ts1adm@/usr/sap/TS1/D00/sec $: export SECUDIR=$(pwd)
ts1adm@/usr/sap/TS1/D00/sec $: sapgenpse gen_pse -p SAPSSLS -a RSA:2048:SHA256 -k GN-dNSName:sapserver.example.com -k GN-dNSName:www.sapserver.example.com "CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE"

Im folgenden die Parameter noch einmal einzeln aufgelistet.

-p SAPSSLS
-a RSA:2048:SHA256
-k GN-dNSName:sapserver.example.com 
-k GN-dNSName:www.sapserver.example.com 
"CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE"

Mit dem ersten Parameter -p wird der Name der PSE angegeben, die erzeugt werden soll. Der Parameter ist Pflicht.

Der zweite Parameter -a ist optional. Damit kann der zu verwendende Schlüsseltyp (RSA, DSA oder ECDSA), die vom Schlüsseltyp abhängige Schlüsselgröße und der Hashalgorithmus für die Signatur (SHA1, SHA224, SHA256, SHA384, SHA512) ausgewählt werden.

Der Parameter -k GN-dNSName ist zwar theoretisch optional, praktisch sollte er aber immer verwendet werden. Mit diesem Parameter wird ein Subject Alternative Name (SAN) angegeben. Dieser wird verwendet damit das Zertifikat gegenüber dem Hostnamen vom Client verifiziert werden kann. Spätestens seit google 2017 die Verwendung mittels des Webbrowsers chrome erzwungen hat (heise: Chrome blockt Zertifikate mit Common Name), sollte der Parameter verpflichtend verwendet werden.

Zum Abschluss wird der Distinguished Name (DN) in Anführungszeichen angegeben. Theoretisch könnte dieser leer angegeben werden, wenn gleichzeitig ein Subject Alternative Name angegeben wird. Man kann aber davon ausgehen, dass viele Implementierungen mit einem leeren DN nicht zurechtkommen. Es sollte zumindest der Common Name (CN) angegeben werden.

Der Parameter -x wurde in diesem Beispiel nicht angegeben, ist aber verpflichtend. Mit ihm wird das Kennwort angegeben, mit dem der Zugriff auf die PSE geschützt wird. Ohne Kennwort kann unter Umständen die PSE auf Betriebssystemebene von Dritten manipuliert werden. Wenn man trotzdem kein Kennwort angeben möchte, dann muss die Abfrage mit ENTER leer bestätigt werden.

In diesem Beispiel wurde der Zertifikatsrequest (—–BEGIN CERTIFICATE REQUEST—– … —–END CERTIFICATE REQUEST—–) auf der Kommandozeile ausgegeben. Man kann diesen Certificate Signing Request (CSR) an eine interne Certification Authority (CA) per „copy and paste“ (inklusive der —- BEGIN und END —- Zeilen) und per Mail an einen entsprechenden Verantwortlichen weiterleiten.

Das Signieren ist fast Pflicht wenn der Server für normale Benutzer erreichbar sein wird. Wenn zum Beispiel die SAP WebGui darüber angesprochen wird. Das Zertifikat der internen Root CA und gegebenenfalls weitere Sub CAs muss dafür aber, zum Beispiel per Gruppenrichtlinie bei Windows, auf dem PC des Benutzers installiert werden. Das hilft dann sofort bei den internen Browsern wie Edge oder dem Internet Explorer. Beim Einsatz von Chrome oder Firefox müssen zusätzliche Maßnahmen ergriffen werden.

Wenn man den CSR als Datei weitergeben möchte, gibt man den Parameter -r <dateiname> an. Als Dateiendung hat sich csr als praktisch erwiesen. Dies ist aber nicht entscheidend.

ts1adm@/usr/sap/TS1/D00/sec $: sapgenpse gen_pse -p SAPSSLS -a RSA:4096:SHA256 -k GN-dNSName:sapserver.example.com -k GN-dNSName:www.sapserver.example.com -r request.csr  "CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE"
ts1adm@/usr/sap/TS1/D00/sec $: cat request.csr
-----BEGIN CERTIFICATE REQUEST-----
MIIE6TCCAtECAQAwVjELMAkGA1UEBhMCQVQxEzARBgNVBAoTCk15IENvbXBhbnkx
EjAQBgNVBAsTCVNBUC1CYXNpczEeMBwGA1UEAxMVc2Fwc2VydmVyLmV4YW1wbGUu
...
+4lJtsZDc2+9P4cSjK3UlLcwkatMZtBocZF9d4i8BnzYWbU2OO6zRxfsO1UUmKzy
zcqrsdHyTcXW9K/WWgCZ12nkAeBix2eWjf2rlIXRcjYwzsCFaPigEU/idRjGtI4g
N3tjrenMJqafYp0mhQ==
-----END CERTIFICATE REQUEST-----
ts1adm@/usr/sap/TS1/D00/sec $: 

Selbstsigniertes Zertifikat

Im Grunde hat man mit der oben genannten Erstellung der PSE bereits ein selbstsigniertes Zertifikat. Dies Zertifikat wird sehr wahrscheinlich Browser Warnungen hervorrufen. Diese Warnung kann man ignorieren oder mit dem Import, und damit einer manuellen Vertrauensstellung, dieses Zertifikat als vertrauensvoll hinterlegen.

Dies kann sinnvoll sein, wenn man ein temporäres Testsystem aufbaut und der Signing Request den Aufwand nicht lohnt.

In diesem Fall kann man die Erstellung der PSE mit dem Parameter -noreq erstellen. Damit wird kein CSR ausgegeben.

ts1adm@/usr/sap/TS1/D00/sec $: sapgenpse gen_pse -p SAPSSLS -k GN-dNSName:sapserver.example.com -k GN-dNSName:www.sapserver.example.com -noreq  "CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE"
Please enter PSE PIN/Passphrase:
Please reenter PSE PIN/Passphrase:

!!! WARNING: For security reasons it is recommended to use a PIN/passphrase
!!! WARNING: which is at least 8 characters long and contains characters in
!!! WARNING: upper and lower case, numbers and non-alphanumeric symbols.

ts1adm@/usr/sap/TS1/D00/sec $:

Zertifikatsrequest erneuern

Wenn ein Zertifikat erneuert werden soll, dann muss nicht zwingend eine neue PSE erstellt werden. In vielen Fällen möchte man nur das Gültigkeitsdatum erneuern und die vorhandenen Einstellungen übernehmen.

ts1adm@/usr/sap/TS1/D00/sec $: sapgenpse gen_pse -p SAPSSLS  -j -onlyreq

-p SAPSSLS
-j 
-onlyreq

Mit dem Parameter -j werden die Subject Alternative Names (SAN) übernommen. Der Parameter -onlyreq ist der eigentliche Aufruf für die Zertifikatserneuerung. Wenn dieser Parameter gesetzt wird, werden auch zusätzliche Parameter wie zum Beispiel der Distinguished Name oder der Algorithmus ignoriert.

ABER, ein „onlyreq“ ist nicht die Empfehlung, da hiermit auch der „Private Key“ der alte bleibt. Eine Neuerstellung der PSE bietet immer die Möglichkeit, neue sichere Parameter zu setzen (und auch kompromittierte Keys auszutauschen).

Im folgenden Screenshot wurden bewusst zusätzliche Parameter mit übergeben. Mit dem Parameter -v (verbose) wird dann auch ersichtlich, dass der „Signed Part“ den alten Distinguished Name umfasst.

Tipp: Man kann den oben aufgeführten Befehl auch mit dem Parameter -r <dateiname> erweitern und den CSR in eine Datei schreiben. Dann kann man auf einem *NIX System, auf dem standardmäßig openssl installiert ist, diesen CSR auch mittels des Befehls openssl req -in mycert.csr -noout -text nachträglich prüfen. Alternativ kann man auch Online, zum Beispiel bei https://www.sslshopper.com/csr-decoder.html, den CSR anzeigen lassen.

Zertifikat (certificate response) importieren – sapgenspe import_own_cert

Wenn der CSR von einer CA unterschrieben wurde, muss dass dann fertige Zertifikat noch importiert werden. Dabei muss die komplette Zertifikatskette importiert werden. Weiterhin ist zu beachten, dass das Zertifikat, die Certificate Response, mit dem Public Key des Certificate Signing Requests übereinstimmen muss. Ich kann also keine beliebiges Zertifikat importieren, nur weil der Distinguished Name übereinstimmt ;-).

ts1adm@/usr/sap/TS1/D00/sec $: sapgenpse import_own_cert -p SAPSSLS -v -c /tmp/mycert.cer -r /tmp/SubCA.cer -r /tmp/RootCA.cer -x psepin

-p SAPSSLS 
-v 
-c /tmp/mycert.cer 
-r /tmp/SubCA.cer 
-r /tmp/RootCA.cer 
-x psepin

Die Angabe der PSE mit dem Parameter -p ist verpflichtend. Mit -v werden erweiterte Meldungen ausgegeben. Das eigentliche Zertifikat wird mit dem Parameter -c angegeben. Hier kommt es auch darauf an in welchem Format einem das Zertifikat zur Verfügung gestellt wird.

Das PEM Format kann man bereits beim Zertifikatsrequest erkennen. Dort beginnt der Request mit —–BEGIN CERTIFICATE REQUEST—–, das Zertifikate beginnt mit —–BEGIN CERTIFICATE —–. Die Endung kann dabei variieren. Typisch sind .cer, .crt, .pem, .key. Man kann den auch leicht mit einem Texteditor anzeigen lassen.

Diese Formate beinhalten immer nur ein Zertifikat und nicht die Zertifikatskette. Die Zertifikatskette muss man daher mit dem Parameter -r vervollständigen.

Mit einem P7B Zertifikat, welches in der Regel auch diese Endung hat, bekommt eine binäres Zertifikate, welches die gesamte Zertifikatskette enthält. Mit so einem Zertifikat muss die Zertifkatskette nicht manuell mit dem Parameter -r erweitert werden.

Im Abschnitt Weiterführende Links gibt es einen Link der die unterschiedlichen Formate näher erläutert.

Kennwortfreier Zugriff auf PSE – sapgenpse seclogin

Um die PSE zu verwalten, benötigt man typischerweise eine PIN. Der Zugriff ohne PIN würde vollen Zugriff auch auf den privaten Key erlauben, was ein Sicherheitsrisiko darstellt.

Trotzdem gibt es manchmal die Notwendigkeit, einen Zugriff einzurichten, ohne dass das Kennwort bekannt ist. Beim SAP Hostagent zum Beispiel, läuft der Prozess unter dem Benutzer sapadm. Die Einrichtung der PSE wird aber unter einem anderen Benutzer durchgeführt.

ts1adm@/usr/sap/TS1/D00/sec $: sapgenpse seclogin -p SAPSSLS -O sapadm -x psepin

-p SAPSSLS 
-O sapadm 
-x psepin

Dies funktioniert aber nur, wenn die Credentials nicht mit LPS geschützt wurden. Dann kann man diese Credentials nicht für einen anderen Benutzer angeben.

Diese Credentials werden in der Datei cred_v2 abgelegt. Falls der Pin einer PSE geändert wird, müssen die Credentials erneut hinterlegt werden.

Wenn man mal prüfen möchte, welche Benutzer gespeicherte Credentials haben, ist dies nicht so ganz einfach. Grundsätzlich kann man mit:

ts1adm@/usr/sap/TS1/D00/sec $: sapgenpse seclogin -l

, sich die gespeicherten Credentials anzeigen lassen. Der Haken ist nur, dass keine Benutzernamen hinterlegt sind.

running seclogin with USER="ts1adm"

 0 (LPS:OFF): DNS=sapserver.example.com, CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE
         (LPS:OFF): /usr/sap/TS1/D00/sec/SAPSSLS.pse
      NOT readable for ts1adm

 1 (LPS:OFF): DNS=sapserver.example.com, CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE
         (LPS:OFF): /usr/sap/TS1/D00/sec/SAPSSLS.ps

Man sieht hier zwei Einträge, beginnend mit Index 0, der für den abfragenden Benutzer ts1adm „NOT readable“ ist. Man kann hier nur Benutzer mit dem Befehl sapgenpse seclogin -l -O sapadm „testen“:

sapgenpse seclogin -l -O sapadm
 running seclogin with USER="s4xadm"
 listing credentials for secondary user "sapadm" ...

 0 (LPS:OFF): DNS=sapserver.example.com, CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE
         (LPS:OFF): /usr/sap/TS1/D00/sec/SAPSSLS.pse

 0 (LPS:OFF): DNS=sapserver.example.com, CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE
         (LPS:OFF): /usr/sap/TS1/D00/sec/SAPSSLS.pse
      NOT readable for sapadm


 1 readable SSO-Credentials available (total 2)

Private Key exportieren – sapgenpse export_p8

Für den Export des privaten Schlüssels (inkl. Zertifikat) stehen zwei Formate zur Verfügung: einmal PKCS 8 und PKCS 12, auch als Dateiendung .p12 oder .pfx bekannt.

Mit PKCS 8 wird eine Base64 dekodierte Datei PEM Datei erzeugt. Der Inhalt kann dann z. B. mit cat eingesehen werden. Beim Export sollte, im Gegensatz zu meinem Beispiel, mit dem Parameter -z die erzeugte Datei mit einem Kennwort geschützt werden.

ts1adm@/usr/sap/TS1/D00/sec $: sapgenpse export_p8 -p SAPSSLS -z "" server.pem

!!! WARNING: For security reasons it is recommended to use a PIN/passphrase
!!! WARNING: which is at least 8 characters long and contains characters in
!!! WARNING: upper and lower case, numbers and non-alphanumeric symbols.

ts1adm@/usr/sap/TS1/D00/sec $: cat server.pem
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCeRkFg5nXMSvL4
...
6ArXXIkAMfBUp2dkA+hbwlFhYpgbZ+QZdeC47YGfhRnWGh9DFahvH26KTxHdoUOx
YGjG+ck0E3tHhmey+AXC/Fs=
-----END PRIVATE KEY-----
Certificate:
 Subject:                              DNS=sapserver.example.com, CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE
 Issuer:                               DNS=sapserver.example.com, CN=sapserver.example.com, OU=SAP-Basis, O=My Company, C=DE
 Serial Number:                        0A:20:22:08:17:07:48:01
-----BEGIN CERTIFICATE-----
MIIDkzCCAnsCCAogIggXB0gBMA0GCSqGSIb3DQEBCwUAMIGLMQswCQYDVQQGEwJE
...
NQglv0y8uKVR6gX1wUK7CaKZb3QvvoXi7GlxcMnSojlC0YICFKI0JukMQVO7Pq7g
lG13VaHAHA==
-----END CERTIFICATE-----

Mit PKCS 12 Dateien bekommt man einen binären Export, und ein Archiv File, welches kryptografische Objekte in einer einzigen Datei speichern kann. Im Gegensatz zu PKCS 8 kann es alle Zertifikate der „Chain of Trust“ exportieren und aufnehmen. Somit auch das Root Zertifikat und alle Intermediate Zertifikate.

Warum sollte man eine PSE exportieren? Nun, in diese Situation kommt man relativ schnell, wenn man SAP Netweaver Java Server betreibt. Netweaver Java kann bei der Zertifikatserstellung, keinen Subject Alternative Name erzeugen. Damit erzeugt man keine gültigen Zertifikate. Ein offizieller Weg ist es wie oben beschrieben eine temporäre PSE zu erzeugen und diese zu exportieren.

Nachtrag: Neuerdings kann man ab Netweaver 7.50 SPS 25 Mit Netweaver Java SAN Zertifikate erzeugen. Siehe „Weiterführende Links“.

Begriffsdefinitionen

PSE = die Personal Security Environment ist ein sicherer Ablageort für öffentliche und private Schlüssel.

Weiterführende Links

1848999 – Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB)

510007 – Additional considerations for setting up SSL on Application Server ABAP

2488621 – Create certificate with SAN Attribute outside of NWA

3202648 – Creating a Key Pair and Public-Key Certificate With Subject Alternative Name

help.sap.com: SAP ABAP Systemsicherheit NetWeaver 7.4

Digicert: What are the differences between .P7B (PKCS#7) .PFX/.P12 (PKCS#12) .PEM, .DER, .CRT, .CER Certificates?