See the blogs below for more details on using the XPI Inspector tool:

1) Using XPI Inspector to troubleshoot HTTP SSL connections (Part 1 – Server Authentication)

2) Using XPI Inspector to troubleshoot HTTP SSL connections (Part 2 – Client Authentication)

If you need to download/deploy the XPI tool, see note 1514898 XPI Inspector for
troubleshooting XI, for details on using the XPI tool (user guide is attached to the note).

Also the notes below document some known issues with this functionality:

2663563 PI REST receiver channel ping fails

2751626 Ping on REST receiver/poller channel is not working properly
2295804 REST Receiver channel ping is failing when HTTPS protocol is configured

SAP PO TLS and ciphers: an overview

Setting the right settings for TLS and cipher parameters for SAP PO can be difficult, as an
overview of information available is mainly spread across a variety of notes by SAP. Currently,
there’s more and more systems switching security levels to mandatory TLS 1.2 policy, as well as
requiring higher security ECDHE and ECDSA ciphers. Setting the right parameters can be difficult
for consultants, as different security requirements are set by different customers. Similarly, for
developers at end clients, information on setting the different parameters might not be easily
available, as information on parameters being spread through the various SAP notes. Subsequently,
here is an overview of TLS, ciphers, and available parameters.

There are several topics for TLS version and ciphers which can be important to set the right parameters:

 TLS version
  Ciphers used

 Testing allowed TLS versions and ciphers

 Testing SAP PO TLS version and cipher compatibility

 Enabling TLS version

 Ciphers supported by default

 Enabling additional cipher types using SSLContext.properties file

 Enabling DHE ciphers

 Enabling ECDHE and ECDSA ciphers

 Example SSLContext.properties file

TLS version
Most systems are using TLS 1.2, although some systems are still supporting TLS 1.0 and 1.1. When SSL
is displayed when testing TLS version used, SSL versions are similar to different TLS versions. SSL 3.1 is
equal to TLS 1.0, SSL 3.2 is the same as TLS 1.1 and SSL 3.3 is equal to TLS 1.2.

Ciphers used

SAP PO supports three types of ciphers:

 Default available

 DHE ciphers

 Elliptic curves

Default available are TLS RSA and SSL RSA ciphers, these can be identified by cipher name starting
with TLS_RSA or SSL_RSA (for example TLS_RSA_WITH_AES_128_GCM_SHA256). Similarly,
DHE ciphers can be recognized by cipher name starting with TLS_DHE (for example
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256). Elliptic curve ciphers can be identified by cipher
name starting with either TLS_ECDHE or TLS_ECDSA (e.g
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).

SAP PO by default supports all ciphers with a length of 128 bits, these can be identified by 128 following
the cipher name (for example TLS_RSA_WITH_AES_128_CBC_SHA). All 256 bit ciphers use a longer
key, and can only be used if unlimited strength policies are enabled.

Testing allowed TLS versions and ciphers

Allowed TLS versions and ciphers for a connection can be tested using the SSL test service by SSL labs:

https://www.ssllabs.com/ssltest/
Testing SAP PO TLS version and cipher compatibility

TLS version and cipher compatibility in SAP PO can be tested using XPI Inspector (example 11).
Enabling TLS version

From SAP PO 7.5 SP05 or higher, all TLS versions (up to TLS 1.2) are supported. In any other versions
of SAP PI/PO, TLS 1.0 and 1.1 are supported by default. TLS 1.2 can be enabled by patching or SP
update.

Minimum SP level (with patching):

  SAP PI 7.10 SP18

 SAP PI 7.11 SP12

 SAP PI 7.30 SP13

 SAP PI 7.31 SP08

 SAP PI/PO 7.4 SP03

 SAP PO 7.5 SP00

Ciphers supported by default

By default, SAP PO supports all 128bit TLS RSA and SSL RSA ciphers. 256bit ciphers are enabled by
default depending on JVM version (6.1.107, 7.1.055, 8.1.036 or higher) of SAP PO, or can be enabled on
lower JVM versions by downloading and installing unlimited strength policy files.

Enabling additional cipher types using SSLContext.properties file

Any additional ciphers can be enabled, when available in SAP PO version, by adding these to
the SSLContext.properties file. When modifying the SSLContext.properties file, at least parameters
client.allowLegacyRenegotiation=true (allow renegotiation of ciphers), extension=signature_algorithms
and extension=server_name.noncritical (send signature algorithms and server name initiating the
connection) should be present.
Preferred ciphers can be used by modifying SSLContext.properties file and manually adding ciphers, by
adding cipherSuite=<name of cipher> to the file.

When modifying SSLContext.properties file with preferred ciphers, all other ciphers are no longer
enabled. If default ciphers should remain enabled, these should be manually added as preferred ciphers to
the modified SSLContext.properties file.

Enabling DHE ciphers

DHE ciphers are supported by default if TLS 1.2 is available in SAP PO. However, DHE ciphers have to
be added manually to the SSLContext.properties file to be available.

Enabling ECDHE and ECDSA ciphers

ECDHE and ECDSA ciphers are supported in SAP PO 7.5 SP08 (with patching) or higher. Lower
versions of SAP PI/PO do not support ECDHE and ECDSA ciphers.

To be enabled, a modified SSLContext.properties file is required, adding parameter

extension=elliptic_curves.

Example SSLContext.properties file

An example SSLContext.properties file enabling all for SAP PO available ciphers, except ECDSA, can be
found in note 2708581 (example 3). Availability of non-default (DHE, ECDHE etc) and 256bit ciphers is
still dependent on SAP PO version and parameters set.
Hopefully this blog has been useful in explaining the different TLS versions and cipher types, testing
these, as well as the parameters for TLS version and ciphers in SAP PO.

Overview of SAP notes used:

 2284059: default ciphers, DHE ciphers, TLS 1.2 upgrade

 1240081: unlimited strength policy files

 0002246884: finding JVM version

 2708581: ECDHE and ECDSA ciphers, examples of modified SSLContext.properties file

 2569156: modify SSLContext.properties file

 1514898: XPI Inspector

Further reading:

 https://blogs.sap.com/2017/06/09/chronicles-of-a-tls-1.2-upgrade/
  https://quachtd.com/troubleshoot-tls-1-2-with-elliptic-curve-cryptography/

Using XPI Inspector to troubleshoot HTTP SSL connections (Part 1 -

Server Authentication)

Introduction

HTTPS (HTTP over SSL) connections are sometimes a bit tricky to establish. There have been
quite a number of threads opened on SCN recently regarding SSL related errors. Below are some
of the common errors that could occur when trying to establish an outbound SSL connection
from PI.
Errors

SOAP: Call failed: iaik.security.ssl.SSLCertificateException: Peer certificate rejected by ChainVerifier

SOAP: Call failed: iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: handshake failure

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed:

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

SAP's troubleshooting tool, XPI Inspector is one of the most useful tool to troubleshoot SSL
connections. In this blog I will share an example of an SSL related error and how to utilize XPI
Inspector to troubleshoot and resolve the issue.

Prerequisite

XPI Inspector does not come pre-installed in the PI system. To install and use it, please refer to
the following SAP Note:-

1514898 - XPI Inspector for troubleshooting XI

For more details about XPI Inspector, refer to the following blog:-
Michal's PI tips: XPI inspector - help OSS and yourself

Step by Step Guide

In this example, we will use a SOAP receiver channel with an HTTPS target URL. For simplicity
sake, we will use SCN as the target system (even though it is not a SOAP web server!).

Step 1 - Set up receiver channel

Populate SCN's URL into the SOAP receiver channel's setting. Ensure that the iFlow/ICO is
configured correctly and activated.

Step 2 - Launch XPI Inspector and start test

XPI Inspector can be accessed from the following URL of the PI system

http://host:port/xpi_inspector

Select Example 11 for Authentication, SSL & PP. Populate the SSL Server URL and any proxy
server if necessary.

Once everything is ready for testing, click the Start button and then trigger the scenario for the
iFlow/ICO in step 1. Once the scenario is completed, click Stop.
Step 3 - Analyse the results

After XPI Inspector has gathered all the logs, it will present a results page. Under
section Performed Checks > Verify Remote SSL Server Certificate, the SSL debug logs are
shown.

In the example below, it shows that the chain verification failed because no trusted certificate
was found.
In the Performed Checks > Is Remote SSL Server Certificate Trusted section, more details of the
certificate and the chain are shown.

The analysis shows that none of the certificates has a CA (Certificate Authority) that is trusted. It
means that there is no corresponding certificate for the CA in the TrustedCAs view in NWA's
keystore.
Step 4 - Retrieve the server's Root CA certificate

In order to establish the SSL trust with the server, we need to retrieve the Root CA's certificate
and import it into NWA's keystore.

First of all, we need to retrieve the certificate. This can be done by entering the HTTPS URL into
a web browser and viewing the certificate details. The example shown below is using Google
Chrome where we can view the certificate information by clicking on the padlock icon on the
browser.

After the certificate is displayed, switch to the Certification Path tab, select the top most entry of
the path as it represents the Root CA. Click View Certificate to view the CA's certificate.
The Root CA certificate is displayed in another window and normally this is a self-signed
certificate by the CA itself.
Switch to the Details tab and select Copy to File to save a version of the certificate on the local
PC. It can be saved in the DER encoded binary X.509 format.

Alternatively, the certificates are also accessible via the hyperlinks on the XPI Inspector results
page.

Step 5 - Import Root CA certificate into NWA's keystore

Now that we have the Root CA, we can import it into the keystore in NWA. The keystore can be
accessed in NWA> Configuration > Security > Certificates and Keys.

Specifically, we want to import the Root CA certificate into the TrustedCAs view of the
keystore. Refer to the following article on importing the certificate. We will only be importing
the X.509 certificate.

Adding Certificates to PI
After completing the import, the Root CA certificate can be viewed as an entry in NWA.

Step 6 - Stop and restart receiver channel

Per SAP Note 1829329, the SOAP receiver channel caches the certificate upon channel start up.
As such, it is recommended to stop the channel and restart it so that the channel's cache is
updated with the new certificate.

Step 7 - Repeat XPI Inspector test

Now that the Root CA certificate is in place, the XPI Inspector test can be repeated.

In the results page, we can see now that the trusted certificate is found and the chain verification
is successful. Therefore the SSL handshake completes successfully.
Additional Example

Here is an additional example of an XPI Inspector debug log for another SSL issue. In this case,
the SSL handshake failed but not because the chain verification failed. After the chain
verification, the server requested the client to present the client's certificate for authentication.
However, the client sent an empty one causing the handshake to fail.
For this scenario, usage of client certificate for authentication is mandatory and therefore the
resolution is to configure a valid client certificate to be used in the receiver channel.

For a thorough example on client authentication, check out the second part of this blog series
- Using XPI Inspector to troubleshoot HTTP SSL connections (Part 2 - Client Authentication).

Conclusion

As shown, XPI Inspector is very useful to troubleshoot SSL related issues. As a matter of fact, I
personally would use it at the beginning of a development that involves HTTPS connection
before even designing or developing.
3057117 - Peer certificate rejected by ChainVerifier - EC signed
SHA256withRSA server certificate server certificate not capable
for ECDHE_ECDSA key exchange algorithm!
Symptom
 An SSL/TLS connection to an external server from the AS Java fails with "Peer certificate
rejected by ChainVerifier" error.
 An SSL trace with IAIK debug records (see SAP KBA 2673775) shows the following
messages:

[...]
ssl_debug(7): Starting handshake (iSaSiLk 5.106)...
ssl_debug(7): Sending v3 client_hello message to <hostname>:<port>, requesting version
3.3...
[...]
ssl_debug(7): Received v3 server_hello handshake message.
[...]
ssl_debug(7): Received certificate handshake message with server certificate.
[...]
Signature Algorithm: SHA256withRSA
[...]
ssl_debug(493): ChainVerifier: EC signed SHA256withRSA server certificate server
certificate not capable for ECDHE_ECDSA key exchange algorithm!
[...]
<...> Peer certificate rejected by ChainVerifier <...>
[...]

Environment
 SAP NetWeaver Application Server Java as of 7.1X version
 SAP Process Integration (PI)

Reproducing the Issue

1. Setup SSL connection with customized SSL Config file from AS Java to remote system.
2. Connection fails.
3. Reproduce the issue while collecting SSL Trace.
4. The relevant traces displayed in the symptom can be seen.

Cause
The target server uses a certificate where EC key is signed with SHA256withRSA algorithm. In case
of using ECDHE_ECDSA, the server's certificate MUST contain an ECDSA capable public key and
be signed with ECDSA encryption algorithm.

Resolution
You can consider the following workarounds:

Option 1:

Contact the target server's administrators to create a certificate signed with ECDSA encryption
algorithm. Once it has been done, import the server certificate chain into AS Java's TrustedCAs
keystore view as per SAP KBA 2056672 - How to import server certificates in PI system.

Option 2:

Check whether backend (SSL server) system supports ECDHE_RSA or RSA Cipher Suites. If so,
exclude/Remove ECDHE_ECDSA ciphers (examples as below) on AS Java (SSL client), only
enable matching ECDHE_RSA And RSA Cipher Suites in SSLContext.properties as mentioned in
SAP Note 2708581 - ECC Support for Outbound Connections in SAP NW AS Java - Example
Profile 2, restart the java server nodes afterwards.

cipherSuite=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
cipherSuite=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
cipherSuite=TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
cipherSuite=TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

Option 3:

Add chainVerifier.checkExtensions=false parameter in SSLContext.properties, save the config file

and restart AS Java to validate changes. This parameter does not deactivate the chain check. It
deactivates only the extension check in TLS library. Seeing that there is more detailed extension
check on the level above TLS library, adding this option is not considered as a security risk.

2538934 - Handshake is failing in AS Java when connecting to a

server which only supports TLS_ECDHE ciphers

The IAIK library, which is used by some of PI Adapters (Rest, SOAP, Axis, ISpeak), only
supports TLS_ECDHE ciphers since NetWeaver AS Java release 7.50 Support Package 08, as it
was introduced in SAP Note 2708581 ECC Support for Outbound Connections in SAP NW AS
Java

In older versions, ECDHE and ECDSA ciphers are not supported at all.

Resolution

For your PI/PO system support TLS_ECDHE ciphers, you should upgrade/update your system
to NetWeaver AS Java release 7.50 Support Package 08 or higher and apply the necessary patch
levels. The system should be in a version where SAP Note 2708581 is implemented.
After that, adjust the SSLContext.properties file as described in SAP Note 2708581 so the
TLS_ECDHE ciphers are enabled in your system. They are not enabled by default. You need to
maintain the configuration according to the Example Profiles based on your system
requirements.

For more how to maintain the SSLCOntext.properties file as well as setup the JVM parameter
that points to it, see KBA:
2569156 How to get and validate SSLContext.properties file
2693382 Cannot read config file SSLContext.properties

Workarounds:

A) If your system is at a version lower than the ones in SAP Note 2708581, contact the target
server and ask them to activate more cipher suites to resolve the problem.

Cipher suites supported in the default configuration:

TLS_RSA_WITH_AES_256_GCM_SHA384 *
TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 *
TLS_RSA_WITH_AES_256_CBC_SHA256 *
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 *
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA *
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA *
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_RC4_128_SHA

* This suite is only available if Java Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy Files are installed (see SAP Note 1240081 Java Cryptography Extension
(JCE) Jurisdiction Policy Files).

For more information, see SAP Note 2284059 Update of SSL library within NW Java server

If you need some arguments you can point them to TLS spec under tools.ietf.org defining
mandatory cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA.

B) In case you cannot upgrade/update your system and the target server is not willing to add
more ciphers, then you can configure a reverse proxy between PI/PO and the target server. It is
possible to use a SAP Web Dispatcher or any other 3rd party solution. The reverse proxy will
create a new TLS connection to the target server and if configured correctly it will be able to
handle the TLS_ECDHE cipher suites. This workaround also applies for lower system versions.
(The BC-JAS-SEC-CPG component in this case is not relevant, as there is no TLS in the AS Java
using this configuration. The AS Java will operate just plain text connections. The TLS will
terminate in the WebDispatcher node).

C) Installing a non-central Adapter Engine on release 7.50 and linking this to the central PI
system (still on release 7.40 or 7.3) can also be used to workaround this situation. You can then
run the interface via the 7.50 Decentral Adapter Engine, simply by changing the Adapter Engine
used in the Receiver Communication Channel in the Integration Builder Directory. Refer to KBA
3218132 Workaround for new PI/PO Adapter features not available in older SP's or Releases, for
more details on this option.
Using XPI Inspector to troubleshoot HTTP SSL connections (Part 2 -
Client Authentication)

Introduction

In my previous blog Using XPI Inspector to troubleshoot HTTP SSL connections (Part 1 - Server
Authentication), I covered the example of troubleshooting SSL server authentication issues using
XPI Inspector. In this second part, I will share an example related to client authentication.

Step by Step Guide

At the end of the first blog, I provided an example on an XPI Inspector debug log for a client
authentication issue. In that example, the SSL handshake requires a mandatory client certificate
to be presented by the client to the server. The handshake failed because no client certificate was
presented.

For the example in this blog, I will extend that scenario by configuring client authentication in
the receiver channel.

The actual generation and/or CSR signing of the client certificate to be used is out of scope for
this blog. This is because this process is dependent upon the actual system being accessed, i.e.
some systems generates the certificate for you, whilst others might require you to provide a CSR
signed certificate.

For the purpose of this example, we will assume that the certificate is already generated and
available.

Step 1 - Verify client certificate in NWA

First, we verify that the client certificate is available in the keystore in NWA > Configuration >
Security > Certificates and Keys.
Step 2 - Configure receiver channel with client authentication

Check View Certificate Authentication and select the Keystore Entry and Keystore
View corresponding to the above private key.

Step 3 - Launch XPI Inspector and start test

Similar to the steps in the example on the previous blog, launch XPI Inspector and perform the
test using Example 11. Populate the client certificate's keystore view and entry accordingly.

Once everything is ready for testing, click the Start button, then trigger the respective end-to-end
scenario. Click Stop once the scenario is complete and wait for the results to be gathered.
Step 4 - Analyse the results

At the results page, we can analyse the SSL debug logs under the Verify Remote SSL Server
Certificate section. As shown in the example below, server authentication was successful as the
certificate chain was trusted.

However, during the client authentication part of the handshake it encountered the following
error:
SSLException while handshaking: Peer sent alert: Alert Fatal: decrypt error

Further details of the error can be viewed in the Verify Local SSL Client Key Pair section. As
shown below, there seems to be some decryption error due to invalid padding.

Signature decryption error: javax.crypto.BadPaddingException: Invalid PKCS#1 padding: no

leading zero!
Step 5 - Resolve certificate issue

This particular example is a little tricky because the error description is somewhat cryptic! The
resolution steps for this error is buried deep in an attachment on SAP Note 1296330 - Security
Troubleshooting Guide for NetWeaver J2EE 640/700.

It seems that the issue is possibly due to the Self Signed CA (of the client certificate) being the
first entry instead of normally being the last entry. In order to rectify this, the certificate needs to
be exported and reimported in the correct order.

Export keystore entry as a PKCS#8 Key Pair. Click the download link to save each file as a
separate file (.p8 and .crt files).

Delete or rename the existing entry in the keystore.

Import the .p8 file as a PKCS#8 Key Pair. Add the .crt files (that was downloaded above) as
PKCS#8 certificates. Ensure that they are added in the order of intermediate to root. For the
example below, since there are only two certificates, the root (self signed CA) certificate is
added last.

Step 6 - Stop and restart receiver channel

After the NWA keystore has been updated with the certificate, stop and restart the receiver
channel to clear the previous certificate that was cached by the channel.

Step 7 - Repeat XPI Inspector test

Repeat the test as per step 3 and analyse the results.

As shown in the results page, the verification of the client certificate is now successful. Note that
the self signed CA certificate is now the last entry in the chain.

Also, the SSL debug log shows that SSL handshake completed successfully for both server and
client authentication.
Conclusion

As shown above, XPI Inspector also comes in handy when troubleshooting issues related to
client certificate authentication. It contains an additional section that provides further details
regarding the verification of the client certificate chain.