SAP NetWeaver is not cloud ready

Now that I have your attention with the blog title. The longer version is “SAP NetWeaver is not cloud ready because of default SNI configuration in NW releases that use a kernel prior to version 777.” In case you are wondering how to solve the SNI problem here is the short description of the solution:

icm/HTTPS/client_sni_enabled = true

Longer version

Why is NetWeaver not cloud ready? Because SNI is disabled by default. In case you are wondering what SNI is and why it is important for cloud scenarios let’s try to explain how the cloud works and in which scenario NetWeaver fails to work together with it. For general information on SNI, please read my blog.

The cloud is composed of services. In the end, when you access a web page/service, you are communicating with a computer program. To make this communication secure, HTTPS is used, nowadays version TLS 1.2+. A server certificate is needed to ensure the identity of a service. Typically, you use the name of your project as the server and domain name, and therefore as the name used to identify the certificate. To make running services cost efficient, they are running on a shared infrastructure or entry point. For the security validation to work, the client must receive a certificate from the server that matches exactly the servers full qualified domain name (FQDN). For the web server to be able to identify the server name the client wants to connect to, SNI is needed. SNI is an extension to TLS and both client and server must support SNI. Web servers started to support SNI over a decade ago. SNI is enabled by configuring parameter client_sni_enabled. You need an SAP Kernel that supports SNI.

SAP Kernel

A kernel supports SNI when the following parameter is available:

icm/HTTPS/client_sni_enabled = true

SNI support is available in several SAP kernel versions (all that are relevant for NetWeaver ABAP).

• Kernel 777
• Kernel 753
• Kernel 749

If you are wondering which kernel to use: SAP Note 2556153. Basically, kernel 7.53 is your target, as this one is downward compatible and can be used instead of a 74x kernel. 7.53 is the one you get with NetWeaver 7.52. More information on kernel patches and levels is available at SCN Wiki and SAP Note 2083594. A roadmap note for kernels is provided in SAP Note 1969546.

For kernel releases lower than 777, the default value for the parameter is false. Let’s just consider kernels lower than 777. To enable SNI, the parameter icm/HTTPS/client_sni_enabled must be changed in the default.pfl profile.

In case the kernel supports the parameter, it must be enabled explicitly. The justification for disabling SNI support by default: „Due to a small, but non-marginal amount of old servers in the installed base, which choke on the presence of TLS extensions in ClientHello, the sending of the optional TLS extension SNI is not enabled by default, and requires an explicit opt-in.“ [SAP Note 2582368]

It seems that SNI was added in PL 110 for Kernel 753, although the change log is not really user friendly to read. This seems to be from 2017, but I think I saw SNI introduced in SAP Web Dispatcher around 2015. Therefore, I believe SNI was added to SAP world in 2015. If you read this and know when SNI was introduced, please leave a comment.

Solution

What do you have to do when you want to be able to connect your NetWeaver system with a service that needs SNI to work?

1. Update your kernel. You need to have a kernel that supports SNI. Without this, you cannot connect directly from your NetWeaver system to the service.
2. Activate SNI support. When the installed kernel supports SNI, you may still have to activate it.

To solve the problem communicating from NW ABAP with external HTTPS services – configured in SM59 – that depend on that the client sends the server name in the request, you have to adjust the default SNI configuration. This is very easy: all you need is a recent kernel and enable SNI. What you should consider when enabling SNI is explained in SAP Note 510007.

icm/HTTPS/client_sni_enabled = true

Lessons learned

SAP systems are a vital part in many organizations. While many companies develop apps on top of NetWeaver, the number of outdated NetWeaver releases is astonishing. Even when the Basis team is applying service packages, the SAP kernel is not always updated too. Changing a profile parameter is an additional configuration step that needs to be approved. While SNI is available for quite some time, don’t expect to be able to use it. This also means that if you are not on a recent S/4HANA release with kernel 777 you need to talk to the Basis team.

I hope this blog helps you in that discussion.

SAP’s decision to offer the functionality, but to disable it by default makes sense, given that even with the release of NW 7.50 SNI support was not available and ensuring a consistent behavior across updates is one of SAP’s release goals. I hope that SAP also learns that a decision they make has an impact on customers for many years to come. While there were some web servers with a SNI problem, was it really a good choice to disable SNI by default? Why not enable it by default and let customers disable it when they have to integrate one of those web servers? Why not enable it by default with a newer release of NetWeaver ABAP, like 7.51 or 7.52? For sure, no one can predict future and this may not have been an easy decision to make. But that more and more services are going to depend on SNI support was predictable even 10 years ago.