Generate SSL certificates with OpenSSL for

SAP systems
FollowRSS feedLike
2 Likes 12,679 Views 15 Comments
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:3
b: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:e
d:76:85:e3:24:
62:df:a6:26:fa:96:f7:8a:ec:19:a0:81:a2:9
1: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:8
1: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:2
f: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:1
d: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=L
ab Root CA
issuer=/DC=local/DC=qosit/DC=lab/CN=La
b Root CA
—–BEGIN CERTIFICATE—–
…
base64 encoded certificate omitted
…
—–END CERTIFICATE—–
subject=/DC=local/DC=qosit/DC=lab/CN=L
ab Enterprise CA 1
issuer=/DC=local/DC=qosit/DC=lab/CN=La
b Root CA
—–BEGIN CERTIFICATE—–
…
base64 encoded certificate omitted
…
—–END CERTIFICATE—–
subject=/C=ES/O=qosITconsulting/OU=SA
P/CN=eee.lab.qosit.local
issuer=/DC=local/DC=qosit/DC=lab/CN=La
b 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.

Alert Moderator
Assigned tags
Security
certificates
encryption
netweaver
openssl
pki
pse
security certificate
ssl/tls
x.509
View more...
Related Blog Posts
Manage your SSL Certificates with
Portecle
By Hüseyin Bilgen, Apr 06, 2015
TOP 10 SSL Security Vulnerability and
Solution - PART 1
By Karthick Srinivasan, May 07, 2017
SSL: Signed vs Self-Signed Certificates
By Hüseyin Bilgen, Sep 29, 2013
Related Questions
Is it possible to have the same SSL
certificate for two QA systems hosted in
the same server?
By Erika Bustamante, Apr 27, 2017
PAM(idm) for SAP systems
By Mukun Dan, Nov 27, 2018
FREE SSL CERTIFICATE FOR
WEBDISPATCHER
By Former Member, Feb 11, 2018
15 Comments
You must be Logged on to comment or
reply to a post.

Former Member
September 30, 2013 at 1:40 pm
Great and useful document!,

Thank you Jose!

Like(0)

Former Member
October 1, 2013 at 8:53 pm
Very useful to get certificates with subject
alternative names, good work.
Like(0)

Former Member
October 3, 2013 at 3:31 pm
Hello,

It is possible to generate certificates with

Alternative Subject Names with
transaction STRUST from Netweaver 7.31.
The trick is to enter 2 different CN
separated by comma in the DN field.
After the certificate is signed by your PKI,
when you import the signed certificate
(p7b) into STRUST, only the first CN is kept
but you have now 2 dNSName entries in
the “Subject (Alt.)” field. You can then use
successfuilly the generated pse file on a
SAP Web Dispatcher.
Like(0)

Former Member
October 3, 2013 at 4:19 pm
Good to know, thanks.
Like(0)

Former Member Post author

October 3, 2013 at 8:53 pm
Hi Oliver,

I didn’t know of that trick. Thanks for

sharing.
Cheers,
José M. Prieto
Like(0)

Former Member Post author

October 4, 2013 at 10:35 am
Hi Oliver,

Let me also pointed out that OpenSSL let

you add other X.509 extensions other
than Subject Alternative Names. For
instance, issue certificates for other
purposes other than server authentication
(e.g. email protection) which sapgenpse
may not allow to do.

Cheers,
José M. Prieto
Like(0)

Former Member
October 23, 2013 at 3:16 pm
Hi Olivier:

We got error message when we input two

CN seperated by comma in the Name field
in Replace PSE windows in transaction
STRUST. would you please suggest which
service pack or SAP note in SAP NW 7.31
will be deployed to generate certificates
with Alternative Subject Names?

Thanks,
Hailin Ma
Like(0)

Former Member
October 24, 2013 at 7:55 am
Hi Hailin,
I don’t know the minimum SP but it works
on our ECC6 EHP6 system SP 6 based on
Netweaver 7.31 SP 6 with a 720 PL 401
kernel and a 5.5.5C SAPCryptolib.
This release is also able to check
certificates revocation.

Regards,
Olivier
Like(0)

Nicola Blasi
March 30, 2015 at 12:20 pm
Hi
very useful document
anyway i have a problem when during
import using strust ,i have more than 1
application to trust in SSLserver standard.
First application is ok ..but when I do the
same procedure for second application it
overwrites the first one …and so on…
How can i do for multiple applications?
Thanks
Nick
Like(0)

Former Member Post author

October 29, 2015 at 9:14 pm
Hi,
Not sure ehat you mean to be honest. I
guess you mean you need to import other
certificates into the PSE certificate list as
trusted ones, right? If so this is not
covered by this procedure however you
achieve this either on STRUST or via
sapgenpseat command line.

Cheers.
José M. Prieto
Like(0)

Sreenath Middhi
October 27, 2015 at 1:53 pm
Hi
Nice blog but it appears that SAP WAS
needs to be on 731 and above to get the
SAN’s through Open SSL?

I tried on my PI which is on 730; it didn’t

work
Like(0)

Former Member Post author

October 29, 2015 at 9:06 pm
Hi,

It should work with 7.30 as well. In fact

this more SAPCryptoLib release
dependant than NW release dependant.
So if you SAPCryptoLib release is updated I
guess you did a mistake in any of the steps
described in the post.
Could you maybe paste the error you are
getting? Perhaps I can then help.

Thanks.
José M. Prieto
Like(0)

Sreenath Middhi
October 30, 2015 at 12:31 am
Hi Jose,
I followed all the steps as mentioned;
created SAPSSLS.pse. when I import the
pSE, it doesnot show me the Subject
Alternate name. I imported the same one
into ABAP (on 740 ) ; I can see subject
alternate name.
note – 1386889 says only version 731 has
SAN feature (though for client pse)
Like(0)

Former Member Post author

October 31, 2015 at 12:08 am
Hi Sreenath,

I see what you mean now. The fact that

you don´t see field “Subject Alternate
Name” when displaying PSE in STRUST
(that field is really only available on newer
NW releases) does not mean SAN is not
set. Indeed it is if you follow correctly my
procedure.
You can also doublecheck SAN is set if you
display SSL server certificate information
in your browser when going to a HTTPS
URL served by that server (“Details” tab
and then field “Subject Alternative
Name”).

For instance:

Cheers.
José M. Prieto
Like(0)

Gabriel Bertrand
August 24, 2017 at 6:24 pm
Jose, followed the steps and was easy to
setup using openssl. But how does it work
If there are mutliple app servers for ABAP
, one central (host_a) and multiple app
server (host_b, host_c etc) and we follow
the steps, ie create key/csr, sign, then
create p12 file and generate the pse file in
each host server.
Now in strust how do we import each of
the individual servers. When we import
the first one (central instance), it also
creates an entry for each of the app
servers. If try to import the one for app
server, it overwrites the one from db
server and all the servers show the DN as
the name of the pse file just imported. So
how do we install this when we have
multiple pse files. Please let know. Thanks.
Regards
Gabriel