Why Email Signature?
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. It does not matter from which client you send your e-mails. Whether from Microsoft Outlook, Outlook from the Office 365 package, or other systems. 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. This article provides you with all the information about how to sign your messages.
E-Mail Signature and Encryption
In principle, e-mails are sent in plain text. This e-mail can be read or modified on the way to the recipient. But you don’t have to encrypt every mail the same way. As a rule, simply a digital signature is sufficient. This ensures the integrity of the sender and excludes tampering.
Encryption
Basically, there are two common methods used for e-mail encryption: 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.
Signing function
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 to 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.
Certificate classes
Special protection is provided here by so-called SMIME certificates. These e-mail signature certificates guarantee the authorship and immutability of the content. This provides additional protection by encrypting the content. There are many providers of such certificates on the Internet. The following certificate classes are distinguished. 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: The extract from the commercial register or the identity card is also checked. Class 4: Requires a personal appearance at the certification authority to verify certain original documents
Implementation of signature in SAP
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 one 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.
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=Bavaria, C=DE, EMAIL=max.mustermann@munich-enterprise.com (It is 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)
Creating a certificate request
An SMIME identity is now completely created 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 not be deleted and recreated after applying for 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.
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 issuing CA in our case is Certum: Order with CSR file
Importing certificate into the SAP system
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 with the same authorization authority (CA). The root and intermediate certificates only need to be deposited once.
Create certificates on the database (root and intermediate distortion.)
Transaction STRUST Menu>certificate->database
- to lay out
- For all cerifia
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.
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
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.
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 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 Example: 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 Example: openssl pkcs -in test.p12 -out output.txt -nodes
Use in other SAP mandates or systems
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.
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.
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.
SMIMIE PSE in the new tenant / system import
Transaction STRUST Menu>PSE->Import Select PSE file from local file. Menu>PSE >Save as Then mark SMIME and select the created SMIMIE identity. to store!
