1. Why email signature?

In principle, the email signature is of interest to everyone. Whether it’s businesses, private users or government agencies. They all need to trust the identity of their communications partner. Everyone wants to be able to rely on the secure and confidential delivery of messages and the data they hold.

By using trusted digital certificates issued on a person’s verified identity, a signature confirms the origin and authenticity of a message. Creating and using signatures thus forms the foundation for the confidentiality of the information.

Basically, there are two common methods of e-mail encryption and signing: S/MIME and PGP. S/MIME (Secure/Multipurpose Internet Mail Extensions) has been around since 1995, PGP (Pretty Good Privacy) existed a little earlier, so since 1991. So to speak, old hats. Neither S/MIME nor PGP have been cracked so far and are considered safe by experts. Both S/MIME and PGP are based on the same principle, so-called hybrid encryption. There is a private key and a public key (certificates at S / MIME). To send someone an encrypted email, you need the recipient’s public key and your own private key. Although the operating principle of both methods is comparable, S/MIME and PGP are not compatible. In the end, you are forced to either convince all communication partners of the standard used or drive two tracks and use S/MIME and PGP variables.

1.1. Signing

However: S/MIME offers a signing functionin addition to encryption. A message remains visible to all, but a cryptographic signature is added that can be verified by the recipient. If the signature is in order, it means that the content of the email has not been changed. But there is another advantage for e-mail encryption with S/MIME: The procedure is already an integral part of many mail programs, whether on the desktop or on mobile devices.

1.2. Certificate classes

Class 1: Only whether the stored e-mail address exists.

Class 2: Contain not only the e-mail address but also the name and the company or organization. In this case, it is confirmed in writing that the information is also correct

Class 3: In addition, the commercial register extract or the identity card is checked.

Class 4: Requires a personal appearance at the certification authority to verify certain original documents

2. Implementation in SAP

2.1. Creating a SMIME Identity

A SMIME identity represents an email address in the SAP system. This email address should be assigned to a user who acts as the sender of an email.

Transaction STRUST

STRUST Environment – SMIME Identities

New entry for a SMIME identity (usually represents a user)

  • S/MIME Example ZSTRUC
  • Application Example ZMS

Logical name is left blank (filled by reading the certificate)

This creates a new entry SMIME ZMS in the Trust Manager.

2.2. Create PSE to a SMIME identity

Mark SMIME ZMS and press right mouse button.

Create PSE:

  • Name: Max Mustermann (Important)
  • Org.: Empty
  • Company: Department
  • CA: O=munich enterprise sotfware GmbH, L=Groebenzell, S=Bayern, C=DE, EMAIL=max.mustermann@munich-enterprise.com (Important that the string is entered in the same way)
  • O = Company
  • L = City
  • S = Region
  • C = Country
  • Email = mail address (which is certified)
  • Algorithm: RSA with SHA 256 (important)
  • Key length: 2048 (important)

2.3. Creating a certificate request

Now a SMIME identity has been created completely in the SAP system. The key pair with “Private Key” and “Public Key” (Certificate Request) are stored in the SAP System.

Important: This SMIMIE identity should no longer be deleted and recreated after requesting a certificate. Otherwise, the certificate may no longer match the key pair you created.

Transaction STRUST

  • Double-click from the PSE of the SMIME identity
  • Then create certificate request
  • Result: Certificate Request (CSR – File)

This file can then be saved to a local text file using the button.

2.4. Order a certificate

With these certificate requirements, you can order a certificate from the certificate providers (CA). After validation, you will receive the certificate with the corresponding root certificate and one or more intermediate certificates.

In our example, we ordered the certificate from the PSW Group. The exhibiting CA in our case is Certum:

Order with CSR file

2.5. Importing certificate into the SAP system

2.6. Root Certificate and Intermediate Certificates

First, the root certificate and the corresponding intermediate certificates must be stored in the SAP system.

Important: Multiple email addresses are certified at the same authorization agency (CA). The root and intermediate certificates only need to be deposited once.

2.6.1. Create certificates on the database (root and intermediate distortion.)

Transaction STRUST


  • to lay out
  • For all cerifia

2.6.2. Read certificates

  • Mark System PSE.
  • Then import certificate via button.
  • Import only root and intermediate certificates at a time.
  • These certificates are included in the certificate overview.

2.6.3. Deposit certificates in the data back

Perform this step for each certificate.

Double-click on the desired certificate.

Menu- Certificate->Export

  • Then select data back
  • Fill in with the corresponding ly pre-created entry

2.7. Read in sMIME certificate

Finally, we read the certificate for the corresponding email address.

Transaction STRUST

Double-click from the PSE of the SMIME identity:

  • Read in the certificate response
  • Backing up from local file
  • Read in the certificate
  • to store

Signed mails can now be sent.

2.8. Exporting the private key of a SMIME identity

The private key is necessary if you want to use the certificates in wide mail systems such as Outlook.

You can check on an ABAP > stack > by entering the transaction STRUST Environment Display SSF Version whether the SAPCRYPTOLIB is installed and in which version. Alternatively, you can run the sapgenpse command on the command line.

Exporting the PSE File to a PKCS-12 File:
sapgenpse export_p12 -p

sapgenpse export_p12 -p sapssl.pse test.p12

With the free OpenSSL you can now extract the private and public key:
openssl pkcs12 -in -out -nodes

openssl pkcs -in test.p12 -out output.txt -nodes

2.9. Use in other SAP mandates or systems

2.9.1. Root and Intermediate Certificates Other mandates

The root and intermediate certificates are system-wide. These do not have to be created and imported in other companies. Other systems

The root and intermediate certificates must be entered into additional SAP systems. Here we proceed as described in point 2.6.

2.9.2. Create SMIME Identity

In other clients or in other systems, a SMIME identity must then be created as described in point 2.1.

Attention: execute only point 2.1.

2.9.3. SMIMIE PSE Exports

The created SMIME identity with the certificate read in we now exported.

Transaction STRUST

Double-click from the PSE of the SMIME identity.

Then save to local file.

2.9.4. SMIMIE PSE in the new tenant / system import

Transaction STRUST


SELECT PSE file from local file.

Menu>PSE->Backing up as

Then select SMIME and select the created SMIMIE identity.

to store!