OK, now it will get complicated. Certificate based logons do not really like reverse proxies. First step is to ensure that the client has a certificate that is accepted by the SAP NetWeaver ABAP PSE. For this, the certificate must be signed by a CA that the ABAP PSE trusts.
Log on the WD admin and select PSE Management
Select Recreate PSE.
In the DN field, use the name of the WD: CN=wd.tobias.de. The other information is optional, but should be added.
Right now, the certificate is created and the PSE has a private key, but the certificate is self-signed. To have an official certificate, it must be signed by a CA. To do this, select: “Create a CA Request” to create a CSR that will be send to the CA.
Create CA Request
Save the output in a TXT file, send it to your CA, let it get signed. Then, go back to WD admin and import the CA response.
The client PSE updates the issuer information. Now there must be shown the DN of the CA. In my case: C=BR, O=EJBCA, CN=ca.tobias.de
In case your ICF will serve only as a HTTPS server, you do not need to do this. In case you want your ABAP server to connect to another web server, this may be of interest. In that case, your ABAP server acts as a client and will receive a server certificate, just like your browser does. While a browser comes with a pre-installed list of CAs, the PSE does not have this. Therefore, ABAP will reject the server certificate received when opening a TLS connection. To make ABAP accept the certificate, either the server certificate must be imported or the CA certificate. Importing each server certificate is not the best approach (number of servers, lifetime, management), importing the CA certificate will make ABAP accept connects too, as long as the received server certificate was issued by this CA.
Open the SSL server standard PSE and switch to edit mode. Click on import certificate
Select the tab File and give the path to the CA certificate.
Check the information of the certificate.
If everything is OK, add the certificate to the certificate list.
CA certificate is imported into the PSE. With this, the PSE can validate successfully each certificate received and that is signed by the CA.
After the server certificate is installed, ICM should automatically make use of it. To see if SSL/TLS connections are now working, two tests should be executed:
Check SSL port setup
Access service using TLS
1. Making Sure the SSL Port is set up correctly
This step checks that ICM is configured to accept TLS connections. SAP Help
Select: Goto from the menu and then Services.
Check that HTTPS is listed and note the port number. Here: 8100.
2. Testing the Connection for SSL Server Authentication
With ICM configured to accept TLS connections on port 8100, the last test is to check if it works with a browser. SAP Help. Open a service in your web browser. To check that the service Works, open it first in normal HTTP.
After the CA issued the certificate, it must be imported into the PSE that issued the CSR. During the import step a verification of the private / public key will happen. This ensures that you import the right public key into the PSE. This also means that you cannot use another PSE for the CSR, as the private key would be different. SAP Help
Switch on edit mode and select import certificate.
Inform the path to the CRT.
Select load as local file. If the CA exported the certificate as P7B, the content is in Base64 format. If the CA gave you another format, you`ll have to transform the certificate first to Base64. Would be nice if the import wizard of STRUST would do all that work for you, but somehow Basis guys must also defend their working time …
Confirm the import. To see if the certificate was imported, double click on Subject
This shows the certificate information in the certificate section.
The PSE contains now a private key and a valid public key, signed by a CA. Now ICF can use this certificate without having browsers complain about the certificate.
The certificate request created in the previous step must be send to a CA. The CA is responsible to create a valid server certificate based on the information provided by the CSR.
Important: the certificate emitted by the CA must follow the PKCS#7 certificate chain format. The response file must contain the public key certificate of the ABAP server as well as the CA’s root certificate. SAP Help
The following screenshots are taking from my own CA.
Add an end entity for the server.
Save as p12 (PKCS#7)
You now have a P7B file that contains the signed certificate for the server in Baes64 format.
In the previous step a new PSE for SSL server was created, but the containing server certificate is self-signed. This means that no sane web browser will accept your certificate without showing a warning message to the user. To have a valid server certificate, it must be signed by a CA. To do so, a certificate request must be created. SAP Help
Open SSL Server Standard node and select server
Create a certificate request.
Copy content to a file (via clipboard) and send it to your CA.
You now have the CSR file for the server PSE that can be submitted to a CA.
SAP stores certificates in PSE files (for the Java guys: JKS). By default, there are several PSEs available, one for each use case (system, SSL, web service, etc). A PSE has a subject which stands for the name of the server. Changes are good that the subject value created by SAP does not match your reality. The following steps show how to create a PSE for your SSL server. SAP Help
Change into edit mode:
Select the SSL Server PSE:
Right click to open the context menu and select replace
Give information about the new PSE. This creates a private and public key for the server CN informed for this PSE. The key will be automatically self-signed, but as the PSE contains the private key, it is no problem to create a certificate request and get the certificate signed by a CA.
The data informed here MUST match the data of the HTTPS server. The name field is the CN of the certificate; therefore this field MUST be the same as the FQDN of the server. That is, when the server is accessed by browsers as https://nwgw74.tobias.de, the field MUST be nwgw74.tobias.de.
Confirm the information. Make sure the CN name is correct. This changes the PSE for SSL Server.
You now have a PSE with a private and public key for the CN nwgw74.tobias.de. This certificate is self-signed. While you can now access ICF via HTTPS, each and every browser will give you a warning message that the certificate used is not trustworthy. To change that, a CSR must be created and signed by a CA.
You now have a PSE for the server nwgw74.tobias.de with a private key and a self-signed certificate.
For ICM to work with SSL, some parameters must be set in the profile. These parameters define which PSE and algorithms to use. Normally these parameters are already set to default values. To see if these are acceptable to you and match the location of your CommonCryptoLib 8 installation, you can use transaction RZ11. SAP Help, Central note for CommonCryptoLib.
Here you can enter the name of a parameter and see the currently configured value of it.
List of parameters and their values
Let the world know