Let’s go straight to the point. You probably did know already but for those of you who did not yet you can generate your Secure Socket Layer (SSL) certificates for SAP systems using the well-known OpenSSL suite. Thus, if you stick around, this is indeed what I am going to show you in this blog following as pragmatic way as possible.
I have to say that you can generate SSL certificates right away using tools delivered by SAP: transaction STRUST for ABAP, command line program sapgenpse or the Key Storage Service for Java. Furthermore, if you know how this process works using those SAP tools, or even though you are not, you should be wondering why I do need to bring OpenSSL into the scene to do something I already can do without it. And you probably right and do not need to lose your time reading through this blog. However I will try to give you next several reasons which for me justify this blog:
- You simply have a second alternative other than the one proposed by SAP.
- You are used to OpenSSL for this kind of tasks. In fact this is the tool many web server administrators use to generate the SSL certificates. You can ask your Apache web server administrators if you don’t believe me.
- You want to make use of any X.509 extensions which SAP tools do not support. For instance, Subject Alternative Names certificates.
- You don’t have your SAP system installed yet, and hence no access to SAP tools whatsoever. Nonetheless you would like to have some work done in advanced like for instance request and sign up the SSL certificates.
This task is delegated to some other groups within your IT organization who based upon information sent over by SAP BASIS team members when requested they reply with an already signed certificate, in PKCS#7 format for instance, which must be uploaded into your SAP somehow.
Foundations
Let’s begin with a fundamental concept: what is the generation of SSL certificates all about?
Firstly SSL is based on a hierarchical model of trust where Certificate Authorities, or shortly CAs, are the very fundamental entities on which both parties involved in a SSL communication must know and trust. If any of them does not known about it or does not trust, SSL will not work (well it will not make sense rather than it will not work) since basically they can’t thereby trust on what client or server are claiming to be. Mathematically speaking that trust is computed as digital signatures bound to the SSL certificates.
CAs can be essentially either internal or external to your IT organization. Which one to pick depends fundamentally on whether your SSL server will be accessible from outside. If it is going to be generally available for the whole Internet community, an external CA provider is a must. Examples of internal CAs are Microsoft’s Active Directory Certificate Services (AD CS) which can be added as a role to a subset of your Windows servers. OpenSSL suite can also be used to manage the tasks of a CA and thus be eventually used for implementing your internal CAs. Other than internal ones, you also have the chance to outsource this task to external or public CAs which are normally universally known worldwide and most used Internet browsers trust on already. You have a nice bunch of CA providers out there you have to pay for their services in most cases. For instance you can pick among GeoTrust, Thawte, DigiCert, VeriSign, Comodo, SwissSign, GlobalSign, Symantec and some others. However you also have a few free options like StartCom or CAcert.org.
Bearing in mind this model of trust, no matter which tool you use, the process of generating SSL certificate is fundamentally as follows:
- The SSL server owner generates a private and public key pair according to the rules of a given encryption algorithm and with a given size of bits. That key pair will make up the two fundamental pieces of your final SSL certificate.
- The public key along with some other information about the subject who owns the certificate is sent out to the CAs in the form of the so-called PKCS#10 Certificate Signing Request or shortly CSR. The CAs are normally more than one according to the hierarchical model of trust established by SSL.
- Those CAs whether they are public or private ones validate the information received and sign the CSR request up as an act of trust on the given subject (i.e. the SSL server). The signed CSR eventually becomes your digital signed certificate which is returned back to the SSL server owner.
- Once SSL server owner receives that signed digital certificate, he or she will have a fully functional SSL certificate ready to be deployed on the SSL server.
During the SSL handshake at the beginning of the connection establishment, the SSL server will send out its SSL digital certificate to the client which essentially contains the public key and the digital certificate signature by the CAs. If client trusts on same CAs (i.e. it can verify the digital signature inside) it will become the proof the SSL certificate is a valid one and the SSL server is who they claim to be. This is known as the server authentication. Note that same process can be also applied in the other way around if required which is known as client authentication.
Our Practical Scenario
As I mentioned earlier I would try to be as pragmatic as possible. So let us assume in this blog we want to create two new SSL certificates for following SAP systems:
- EEE, a backend SAP ERP system consisting of a single ABAP instance running on hostname eee.lab.qosit.local which is accessed through the DNS alias erp.lab.qosit.local. ICM HTTPS port is set to TCP/8400.
- PPP, a SAP Portal system consisting of a single Java instance running on hostname ppp.lab.qosit.local which is externally accessed via the DNS alias portal.lab.qosit.local and standard HTTPS port (TCP/443).
To make this case kind of real exercise let us assume as well that even though the regular access point for final users are throughout hostnames erp.lab.qosit.local and portal.lab.qosit.local respectively, there is also the need to access them using real ones, i.e. eee.lab.qosit.local and ppp.lab.qosit.local.
Let’s also assume we have also a Linux box with a full OpenSSL suite installed. However OpenSSL is available for many other OS and syntax should be easily translated to those ones.
Configuration File
First step we need to carry out is the creation of a configuration file where we will set certain OpenSSL parameters required to generate CSR requests. It is essentially a text file with an INI-like format. For further details about the format and generics of this file you must go to the OpenSSL website (see reference [1] below).
We must use OpenSSL command req for the generation of a PKCS#10 certificate request. The full documentation is available at the OpenSSL website (see reference [3] below). We start then writing a section in the configuration file as follows:
1. [req]
2. distinguished_name = req_dn
3. req_extensions = req_exts
Basically we are telling OpenSSL to take up the information in order to build up the subject distinguished name (DN) out of a section called req_dn (line 2) within same configuration file. Also we want to make use of certain certificate extensions according to X.509 standard that we will be setting up within another section called req_exts (line 3).
In this particular example, we are only assigning following fields of the subject DN: Common Name, Organizational Unit, Organization Name and Country. Therefore our section req_dn will look like this:
5. [req_dn]
6. commonName = “CN”
7. commonName_default = “enter you CN (mandatory)”
8. organizationalUnitName = “OU”
9. organizationalUnitName_default = “SAP”
10. organizationName = “O”
11. organizationName_default = “qosITconsulting”
12. countryName = “C”
13. countryName_default = “ES”
However there are some others you may want to set as well (e.g. email address). For further details you better refer to the OpenSSL official documentation (see reference [3] below).
Other than this, you might have realized already that to meet the requirements given above we will need to generate both SSL certificates in such a way they will be valid no matter which hostname is used for sending the HTTP requests (each SAP system can be reached in fact via two different hostnames). This can be achieved by means of a X.509 extension called Subject Alternatives Names or shortly SAN. We set that extension and some others in section req_exts which will look like this:
14. [req_exts]
15. basicConstraints = CA:FALSE
16. subjectKeyIdentifier = hash
17. keyUsage = digitalSignature, keyEncipherment
18. extendedKeyUsage = serverAuth
19. subjectAltName = $ENV::req_exts_SAN
Full documentation about X.509 v3 extensions is available at the OpenSSL website (see reference [2] below). In our case we are telling OpenSSL that this is not a CA certificate (line 15), to be compliant with RFC 3280 in terms of certificate path reconstruction (line 16), what the intended usage of the certificate is (lines 17 and 18) and finally some other subject alternative names generated CSRs will be valid for (line 19). Note the special values in the format of $ENV::<name> in line 19. This is a nice feature of OpenSSL configuration file that allows you to expand values of environment variables, <name> in that case. We will see later why we set those values in this way.
Generate PKCS#10 Certificate Requests
Let’s assume you save the OpenSSL configuration settings into file sap-certs.conf. We can now generate a PKCS#10 certificate requests using OpenSSL command req. On one hand, for SAP system EEE, we will use following command (in red our inputs):
$ env req_exts_SAN="DNS:erp.lab.qosit.local" \
> openssl req -config sap-certs.conf \
> -newkey rsa:2048 -keyout eee-key.pem -out eee-req.pem
Generating a 2048 bit RSA private key
......+++
...........................................+++
writing new private key to 'eee-key.pem'
- Enter PEM pass phrase:<enter private key password>
- Verifying - Enter PEM pass phrase:<repeat private key password for verification>
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
CN [enter your CN (mandatory)]:eee.lab.qosit.local
OU [SAP]:
O [qosITconsulting]:
C [ES]:
Let me explain you something about this command:
- According to the settings in our configuration file, OpenSSL prompts you to input the values to build up the subject DN, i.e. CN, OU, O and C.
- A new RSA private key of size 2048 bits will be created according to option -newkey.
- Note how we set the environment accordingly using Linux command env. Being more specific, we are setting variable req_exts_SAN to value DNS:erp.lab.qosit.local so that parameter subjectAltName in sap-certs.conf expands to this value (remember we set this parameter as $ENV::req_exts_SAN in that file). This is a nice way to use file sap-certs.conf as a template for issuing OpenSSL commands.
- Values of parameter subjectAltName can take several different formats and I will encourage you to go to the OpenSSL documentation for further details (see reference [2] below). However in this case the certificate we are generating will be valid, in addition to the given CN, for hostnames which response to a DNS record erp.lab.qosit.local.
Out of this command two files will be created:
- eee-key.pem which contains the EEE private key so guess what? Keep it secret!
- eee-req.pem which contains the CSR in PKCS#10 format to be sent to the CAs
Likewise, we can generate the CSR request for system PPP:
$ env req_exts_SAN="DNS:portal.lab.qosit.local" \
> openssl req -config sap-certs.conf \
> -newkey rsa:2048 -keyout ppp-key.pem -out ppp-req.pem
Generating a 2048 bit RSA private key
............+++
.............+++
writing new private key to 'ppp-key.pem'
- Enter PEM pass phrase:<enter private key password>
- Verifying - Enter PEM pass phrase:<repeat private key password for verification>
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
CN [enter your CN (mandatory)]:ppp.lab.qosit.local
OU [SAP]:
O [qosITconsulting]:
C [ES]:
We will be have two new files, the private key ppp-key.pem and the CSR request itself ppp-req.pem, this time for system PPP.
Check Certificate Requests
You can verify whether a CSR is ok with following command:
$ openssl req -verify -in eee-req.pem -noout
verify OK
You can also display the details about those CSR with following command:
$ openssl req -in eee-req.pem -text -noout
Certificate Request:
Data:
Version: 0 (0x0)
Subject: CN=eee.lab.qosit.local, OU=SAP, O=qosITconsulting, C=ES
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ae:71:bc:45:cd:3f:f2:1a:d7:92:2d:25:fa:72:
b7:5a:b5:e0:00:c5:ad:d5:de:de:21:c4:f9:b4:27:
07:5b:48:1c:03:60:eb:e0:fd:1b:c7:cc:b7:07:27:
21:ab:f2:13:3a:39:b4:ed:84:a1:08:62:ce:94:98:
a9:55:c1:54:e0:b0:72:44:a7:60:b2:e5:47:3b:a0:
04:96:82:fb:92:5e:a1:4b:ec:5d:a4:b7:53:f5:44:
54:84:b1:63:79:5e:7a:11:d8:0f:bd:8b:8e:48:ba:
11:1c:e6:e3:01:ad:48:13:d7:81:7d:ff:0c:e4:d3:
5b:52:d9:2f:a1:e4:8e:2b:76:35:ea:37:5a:71:65:
60:fc:89:52:1d:78:3d:c2:fe:b7:f6:cb:3b:4c:66:
ed:3b:3d:10:02:d2:68:f6:ff:2f:97:de:8b:22:3b:
97:29:3c:e9:4b:92:e5:b4:87:91:b1:06:7d:07:4a:
06:89:ab:e1:6b:0f:41:04:e7:b8:81:0b:1d:74:61:
6c:9b:f5:2a:dd:82:74:fd:16:da:d3:f2:62:8e:df:
6b:7b:86:b6:60:9b:4e:c2:99:f8:da:bb:95:08:55:
cd:c3:e6:70:9f:16:aa:66:92:d0:f4:d2:75:bf:21:
59:bf:ac:d0:6e:ae:fe:3b:6c:cd:54:07:c3:19:a0:
6f:2d
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment, Key Agreement
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:erp.lab.qosit.local
Signature Algorithm: sha1WithRSAEncryption
85:10:81:a3:74:15:2e:9b:2c:76:38:5a:66:7a:6a:9b:5d:70:
bf:09:4d:06:15:4f:d5:4f:62:8f:b0:2a:d8:ed:76:85:e3:24:
62:df:a6:26:fa:96:f7:8a:ec:19:a0:81:a2:91:ba:c9:97:fd:
a0:b2:3a:43:0c:16:bd:a0:b4:68:1a:d0:a7:ae:f7:19:c9:45:
92:d9:0c:d3:f5:a5:82:dd:3f:38:0c:99:d0:6c:1c:a4:58:e9:
6f:c1:4a:67:ba:e5:30:86:43:53:e8:bb:ab:d8:37:fe:d0:4c:
ed:f6:99:70:5e:56:3f:e1:a8:9f:ec:cc:3f:81:98:38:f2:02:
ad:5a:7f:08:e8:5d:48:a8:1e:29:72:6c:81:f7:20:80:cd:2e:
55:0c:49:73:4c:4f:ac:bd:a5:ef:54:a6:5c:2f:3f:d8:2b:12:
46:8e:f4:03:62:84:40:4a:27:f4:6d:68:f1:e9:4f:1a:1a:0b:
32:75:7f:b1:5a:48:2e:98:a1:7f:70:3d:66:19:f5:9d:e1:a7:
2a:d4:f7:77:fe:e2:f2:06:0e:00:8c:01:3c:1d:ba:ad:82:81:
1b:e4:17:9f:ae:ea:85:67:e0:0b:4a:1a:75:ec:96:88:0f:90:
6c:35:3b:ad:e1:29:2a:fd:11:45:2b:f0:fb:6c:c7:bd:0f:77:
0e:1f:6c:0e
Certificate Authority Signature
Now it is time to send out both CSR requests to the CAs. They can be within your IT organization or hired externally. They will then sign them up and convert your CSR requests into full-fledged digital certificates.
Very important to note here and bear it in the very deep of your mind: never ever send out private keys to anybody! Otherwise you may seriously compromise your SSL server. The responsible teams administering your CAs will only need the CSR requests to do their work.
Now is time to relax and have a cup of coffee till you get back a response from the CA responsible team.
Extract Certificates Issued by CAs
Did you get the response from your CAs? You probably get PKCS#7 files, one for each of the CSR you sent over on previous section. This is a standard described on RFC 2315 which is normally used as a container for cryptographic data such as digital signatures or encrypted messages. Digital certificates issued by CAs are essentially data digitally signed so this format suits perfectly for certificate dissemination.
So let’s assume you got following two PKCS#7 files from your CAs:
- eee.p7b which is the digital certificate issued by your CAs for system EEE
- ppp.p7b same as eee.p7b but this time for system PPP
Into the PKCS#7 files you may find more than one certificate. This is because people responsible for your CAs included the whole certificate chain from the Root CA down up to your digital certificate. This can be easily seen using OpenSSL as follows (some output has been omitted):
$ openssl pkcs7 -inform der -in eee.p7b -print_certs
subject=/DC=local/DC=qosit/DC=lab/CN=Lab Root CA
issuer=/DC=local/DC=qosit/DC=lab/CN=Lab Root CA
-----BEGIN CERTIFICATE-----
…
base64 encoded certificate omitted
…
-----END CERTIFICATE-----
subject=/DC=local/DC=qosit/DC=lab/CN=Lab Enterprise CA 1
issuer=/DC=local/DC=qosit/DC=lab/CN=Lab Root CA
-----BEGIN CERTIFICATE-----
…
base64 encoded certificate omitted
…
-----END CERTIFICATE-----
subject=/C=ES/O=qosITconsulting/OU=SAP/CN=eee.lab.qosit.local
issuer=/DC=local/DC=qosit/DC=lab/CN=Lab Enterprise CA 1
-----BEGIN CERTIFICATE-----
…
base64 encoded certificate omitted
…
-----END CERTIFICATE-----
Each section beginning with -----BEGIN CERTIFICATE----- and ending with -----END CERTIFICATE----- is a base64 encoded certificate (however note that the base64 encoded texts have been omitted from output above). You can even see to whom they belong and who issued it looking at the two lines just before -----BEGIN CERTIFICATE-----. You can also reconstruct the full certificate chain looking at who issued each certificate. For instance, in this case:
/DC=local/DC=qosit/DC=lab/CN=Lab Root CA
/DC=local/DC=qosit/DC=lab/CN=Lab Enterprise CA 1
/C=ES/O=qosITconsulting/OU=SAP/CN=eee.lab.qosit.local
We do need to separate each one of those certificates into different PEM files. You can use for that any text editor you like. Add the option -out <file> to the command above and that output will be redirected to <file>. But recall it is pretty import to copy and paste exactly from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- both lines included.
In our particular example, we will get four new files out of this process:
- eee-cert.pem which contains the signed digital certificate issued for system EEE in PEM format
- ppp-cert.pem same as above for system PPP
- labrootca.pem which contains the digital certificate of our Root CA in PEM format
- labentca.pem which contains the digital certificate of our Intermediate CA in PEM format
Note that we only need to extract the Root CA and Intermediate CA certificates once even though same certificates will be contained within both eee.p7b and ppp.p7b. This is why we only get four files instead of six.
You can check out whether you extracted the certificates in the right way by display the X.509 structure as follows:
$ openssl x509 -in eee-cert.pem -text -noout
Finally you need to save the certificate chain together into a single file, CAchain.pem, to be used for validating our final certificates. After you have extracted them from the PKCS#7 files, you can easily do this as follows:
$ cat labentca.pem labrootca.pem > CAchain.pem
Create PKCS#12 Certificates
Our target at this stage is to create both PKCS#12 files so that we can import them into either a SAP PSE or into the SAP Java key storage. PKCS#12 is a file format used as container for storing whole certificates including both private and public keys. For this reason, they are normally protected using a symmetric key (a password).
For that purpose we will need the digital PEM certificates for EEE and PPP extracted earlier, the certificate chain in CAchain.pem and the private keys generated previously along with the passwords you typed in when prompted to do so. Then we can generate a complete PKCS#12 file for system EEE as follows (in red our inputs):
$ openssl pkcs12 -export -chain -CAfile CAchain.pem \
> -in eee-cert.pem -inkey eee-key.pem -out eee.p12
Enter pass phrase for eee-key.pem: <enter private key password>
Enter Export Password: <enter P12 password here>
Verifying - Enter Export Password: <repeat P12 password for verification>
Note that you require to type a password three times: first one is the password you used to protect your private key when key pair was created early on and the second and third ones are the password to protect the PKCS#12 file itself.
You must do exactly the same for system PPP:
$ openssl pkcs12 -export -chain -CAfile CAchain.pem \
> -in ppp-cert.pem -inkey ppp-key.pem -out ppp.p12
Enter pass phrase for ppp-key.pem: ****
Enter Export Password: ****
Verifying - Enter Export Password: ****
Deploy Certificates into SAP
The process is slightly different depending on whether you deal with an ABAP or Java stack. This is basically because ABAP stacks use Personal Security Environment (PSE) to store certificates deployed in your SAP system while Java ones use service Key Storage for that purpose.
Deployment in ABAP Stacks
Let’s start with our ABAP that is with system EEE. Firstly we use tool sapgenpse to import our PKCS#12 certificate in eee.p12 to a PSE file eee-SAPSSLS.pse. This tool is part of the SAP kernel and should then be available at the EEE installation. However you can also have a standalone version at your local PC. You will need to download the SAP Cryptographic Software (if allowed to) for your platform from the download center at SAP Marketplace. Since we are using a Linux box, within the archive for Linux you willonly need to extract executable sapgenpse and the SAP cryptographic shared library libsapcrypto.so into same directory.
You can now run sapgenpse as follows (in red our inputs):
$ env LD_LIBRARY_PATH=. SECUDIR=. ./sapgenpse import_p12 \
> -p eee-SAPSSLS.pse eee.p12
import_p12: MISSING password for PKCS#12 file "eee.p12"
- Please enter PKCS#12 encryption password:<enter P12 password>
PKCS#12/PFX file contains 1 keypair:
1. FriendlyName = "<none>"
X.509v3 (type=Both) RSA-2048 (signed with sha256WithRsaEncryption)
Subject="CN=eee.lab.qosit.local, OU=SAP, O=qosITconsulting, C=ES"
Issuer ="CN=LabRootCA, DC=lab, DC=qosit, DC=local"
Choose a PIN for your new PSE "./eee-SAPSSLS.pse"
Please enter PIN:<enter PSE PIN>
Please reenter PIN:<repeat PSE PIN for verification>
Recall sapgenpse requires environment variable SECUDIR to be set accordingly. The standard location where that variable points to is $(DIR_INSTANCE)/sec. However we are setting SECUDIR to current directory for our standalone sapgenpse. Additionally we need to set variable LD_LIBRARY_PATH accordingly so that sapgenpse is able to find libsapcrypto.so. It will then create a new PSE file eee-SAPSSLS.pse within SECUDIR directory, according to option -p, containing the EEE’s key pair in PKCS#12 file eee.p12. Recall our PKCS#12 files already contain the full certificate chain so no need to give any extra information to sapgenpse.
At this point we have a PSE file ready to be used as a SSL server PSE. We do need to log in onto EEE system via SAPGUI, go to transaction STRUST, click on option File at the left pane and choose PSE file eee-SAPSSLS.pse. It will then be loaded into STRUST (see DN in Own Certificate section). Then go to menu PSE, choose Save as… and select SSL Server. Confirm replacement (only if a PSE exists already within SSL server) and voilà.
After you restart the ICM server, the new SSL certificate will be deployed in your ABAP stack and visible when going to either https://erp.lab.qosit.local:8400 or https://eee.lab.qosit.local:8400.
Deployment in Java Stacks
Time now for system PPP. Depending on the version of your Java stack you will need to open up either Visual Administrator (SAP NetWeaver earlier than 7.3) or SAP NetWeaver Administrator (SAP NetWeaver 7.3 and higher). We are going to assume our PPP is a NetWeaver 7.3 Java stack. In any case, process is very similar and for sure you can deduce how to do for older stacks out of next steps.
So let’s open up the SAP NetWeaver Administrator at http://ppp.lab.qosit.local/nwa and go to Configuration > Security > Certificates and Keys. Select the key storage view service_ssl. Each certificate <cert_name> in that view must have two entries:
- <cert_name> containing the private key part
- <cert_name>-cert containing the public key part
Other than this, in addition to create new entries in there, SAP gives you the chance to import them from files. Private key entries can be imported from PKCS#12 files. Public key ones can be imported from X.509 certificates instead. Moreover, when importing from files, <cert_name> is determined directly from the filename.
Keeping this in mind, we have all ingredients for cooking a yummy cake:
- We have a PKCS#12 file we can use to import the private key part: ppp.p12
- We have a X.509 certificate we can use to import the public key part as well: ppp-cert.pem
- We need to rename both files accordingly so that we get the certificate name we wish, for instance if we want the certificate name looks like ppp-ssl-server, we will need to rename those files as follows:
- ppp.p12 to ppp-ssl-server.p12
- ppp-cert.pem to ppp-ssl-server-cert.pem
You can now click on button Import Entry to import each part of the certificate choosing the type of file being imported accordingly for each type of key:
You can now copy those entries into the corresponding ICM SSL Server key storage view by going to Configuration à Security à SSL and then select your SSL access point.
After you restart the ICM server, the new SSL certificate will be deployed in your Java stack and visible when going to either https://portal.lab.qosit.local or https://ppp.lab.qosit.local.
- SAP Managed Tags:
15 Comments
