Skip to Content

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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’

  1. Enter PEM pass phrase:<enter private key password>
  2. 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’

  1. Enter PEM pass phrase:<enter private key password>
  2. 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”

  1. 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:

/wp-content/uploads/2013/09/image_20130923_194451_287009.png

/wp-content/uploads/2013/09/image_20130923_194538_287010.png

/wp-content/uploads/2013/09/image_20130923_194732_287011.png

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.

To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

    1. Olivier CHRETIEN

      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.

      (0) 
        1. José M. Prieto Post author

          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

          (0) 
  1. Hailin Ma

    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

    (0) 
  2. Olivier CHRETIEN

    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

    (0) 
  3. Nicola Blasi

    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

    (0) 
    1. José M. Prieto Post author

      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

      (0) 
  4. Sreenath Middhi

    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

    (0) 
    1. José M. Prieto Post author

      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

      (0) 
      1. Sreenath Middhi

        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)

        (0) 
        1. José M. Prieto Post author

          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:

          Image 1.png

           

          Cheers.

          José M. Prieto

          (0) 
  5. Gabriel Bertrand

    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

    (0) 

Leave a Reply