Setting up SSL on Application Server ABAP

Setting up SSL on Application Server ABAP

Symptom

This SAP Note contains information about setting up SSL on Application Server ABAP (AS ABAP).

Sections 1+2: installing & enabling the library (for SAP Netweaver prior to 74x)
Section      3: creating SSL Server PSEs for SAP WebAS through transaction STRUST
Section   4+5: creating SSL client PSEs for SAP WebAS through transaction STRUST
Section      6: customizing available TLS cipher suites
Section      7: customizing available TLS protocol versions
Section      8: Interoperability (issues) with third-party TLS implementations

Other Terms

SSL, TLS, Transport Layer Security, HTTPS, encryption, trust manager, STRUST, cipher suites, SAPCRYPTOLIB, SAP WebAS ABAP.

Solution

This SAP Note describes the steps required to manually install a SAPCRYPTOLIB up to SAP Release 720 and to set up SSL on Application Server ABAP.

There are two SAPCRYPTOLIB variants (old/new) that can be recognized and distinguished based on their (complete) names. Instances of the “old” library are called “SAPCRYPTOLIB 5.5.5 plXX” (for example, “5.5.5pl38”), whereas the newer variant of the SAPCRYPTOLIB has the name “CommonCryptoLib 8” (shortened to “CCL”) and has a version of the form
“8.<major>.<minor>” (for example, “8.4.31”).  For use in AS ABAP 70x or 71x, CommonCryptoLib 8 requires a downward-compatible 72x Kernel (at least 720 patchno 88). CommonCryptoLib 8 can not be used in AS ABAP 640.

For SAP NetWeaver 74X, a SAPCRYPTOLIB in the new variant CommonCryptoLib 8 is a regular component of the delivery (kernel CD), and, as of November 2013, “CommonCryptoLib 8” is also part of new 72x kernel patches (in the download from SAP Service Marketplace, in the packages SAPEXE and dw_utils).  This means that manual installation of  the library (described in section 1) for Netweaver 74x systems is only necessary to get the most recent library version (newer than what a particular Kernel includes, such as a stack kernel), and Netweaver 74x includes suitable predefined profile parameter values (described in section 2), so custom profile parameters for the library location are no longer necessary (and can be removed after upgrade of AS ABAP to 74x).

  1. Manual Installation SAPCRYPTOLIB (obsolete for Netweaver 72x/74x kernel patches released after November 2013)

    Install SAPCRYPTOLIB and the corresponding sapgenpse command line tool in the directory $DIR_EXECUTABLE on all application servers.  Earlier versions of SAPCRYPTO 5.5.5 (pl32 and below) require a separate license ticket file (“ticket“), which must be installed in the directory $DIR_INSTANCE/sec.

    As of Kernel Release 6.20, the license ticket was generated automatically by the AS ABAP kernel (disp+work) in $DIR_INSTANCE/sec when the system was started.  As of SAPCRYPTOLIB 5.5.5 pl32, the system no longer requires a license ticket file, and the SAPCRYPTO 5.5.5 pl34+ download packages still contain a file ticket (because there are several installation instructions that describe the installation of the file ticket). However, the content of the file ticket is completely irrelevant for new libraries.

    Independent of SAPCRYPTOLIB, the NetWeaver Administrator in SAP AS Java checks for the existence of a file ticket. If necessary, you must produce a file ticket there with the required contents in $DIR_INSTANCE/sec to satisfy the check function in the NetWeaver Administrator.

    Distribution packages of CommonCryptoLib 8 contain no file named ticket. To ensure continuously consistent system behavior, set the environment variable SECUDIR in the environment of the user <sid>adm (or SAPService<SID> or both) in the directory $DIR_INSTANCE/sec on all application servers. If you want to protect the PSEs (key files) with a password, on UNIX systems, you must also set the environment variable USER to the name of the UNIX user under whom the SAP system is running.

  2. Manual First-Time Installation or Configuration of SAPCRYPTOLIB on an SAP NetWeaver 6xx, 70X, 71X, 72x, or 73x System

    Set the following profile parameters in the instance profile of all application servers and then restart the system.  The first three parameters replace the SAPSECULIB contained in the delivery of earlier SAP NetWeaver releases with SAPCRYPTOLIB:

    ssf/name = SAPSECULIB
    ssf/ssfapi_lib = <path and file name of SAPCRYPTOLIB>
    sec/libsapsecu = <path and file name of SAPCRYPTOLIB>
    ssl/ssl_lib = <path and file name of SAPCRYPTOLIB>

    In SAP Netweaver Release 740+ and in Netweaver 72x Kernel-Patches created in 2014 or later, SAPCRYPTOLIB is automatically installed in $(DIR_EXECUTABLE) along with all other Kernel libraries and executables, so that you should use the following parameter values on all application server platforms (each SAP AppServer will substitute the necessary platform-specific parts, like the path seperator character, shared library prefix and shared library filename extension) :

    ssf/name = SAPSECULIB
    ssf/ssfapi_lib = $(DIR_EXECUTABLE)$(DIR_SEP)$(FT_DLL_PREFIX)sapcrypto$(FT_DLL)
    sec/libsapsecu = $(DIR_EXECUTABLE)$(DIR_SEP)$(FT_DLL_PREFIX)sapcrypto$(FT_DLL)
    ssl/ssl_lib = $(DIR_EXECUTABLE)$(DIR_SEP)$(FT_DLL_PREFIX)sapcrypto$(FT_DLL)

    740+ Kernels plus 72x Kernel patches created after Q2/2014 know a predefined variable “$(SAPCRYPTOLIB)”, where the platform-specific shared library prefix and filename extension is supplied by the Kernel.  You can use ABAP report “RSPARAM” to lookup current & predefined profile parameter settings known to AS ABAP, and to check whether it provides a definition for $(SAPCRYPTOLIB).  Using the Kernel-supplied definition of $(SAPCRYPTOLIB), the above can alternatively be defined as:

    ssf/name = SAPSECULIB
    ssf/ssfapi_lib = $(SAPCRYPTOLIB)
    sec/libsapsecu = $(SAPCRYPTOLIB)
    ssl/ssl_lib = $(SAPCRYPTOLIB)

    Actually, SAP Netweaver 74x Kernels include CommonCryptoLib and suitable predefined values for the profile parameters above, so removing custom settings for the above parameters from default and instance profile(s) of a Netweaver 74x ABAP System will work as well.

    To configure an actual service that uses HTTPS for an incoming connection, use icm service definitions with any of the applicable plugins (such as e.g. the HTTPS plugin):

    icm/server_port_X  = PROT=HTTPSPORT=<TCP port number for HTTPS>

    If you want to suppress/permit/enforce user logon by client certificate in the SSL protocol:

    icm/HTTPS/verify_client = 0 / 1 (default) / 2

    In SAP Netweaver 6.xx the STRUST user interface does not offer selection of a key size when creating new (SSL) PSEs.  As a workaround, you can set the following profile parameter for specifying the keysize that will be used when creating new RSA PSEs (this requires at least an ABAP kernel Release 6.20 or higher, see SAP Note 509495).

    sec/rsakeylengthdefault = 2048
  3. Creating the SSL Server PSEs in SAP AS ABAP

    When using SSL/TLS to protect network communication, the server of the communication scenario is typically authenticated by an X.509 certificate, and there is a convention to identify the server by matching the server hostname from the connection parameters (such as the URL) to name attributes in the certificate.  This matching is called “server endpoint identification”, and was first described in Section 3.1 of rfc2818 “HTTP over TLS” based on the behaviour implemented in common web browsers at the time.  Similar checking of server endpoint identification has been adopted by other protocols that use TLS, and has been described in rfc6125.

    https://tools.ietf.org/html/rfc2818#section-3.1
    https://tools.ietf.org/html/rfc6125#section-6.4

    When creating SSL server PSEs, you will have to place the hostname(s) from the URLs to your server(s) in the Name part of your server certificate(s), otherwise clients connecting to your server with SSL/TLS will not report errors about incorrect/mismatching server certificate(s).

    In case you want to create Certificate Signing Requests (CSRs) with one or multiple SubjectAltName(s) within ABAP transaction STRUST please refer to SAP note 2478769.

    To create or maintain SSL server PSEs, start ABAP transaction STRUST (“Trust Manager”).

    1. Create the default SSL server Standard PSE (for all instances that do not have an instance-specific SSL server PSE).
      When using a wildcard server certificate or a multi-hostname certificate matching the hostnames of all your AppServers, then you do not need any instance-specific SSL server Standard PSEs.

      Choose “Create” in the context menu of the “SSL server” node. As far as possible, the trust manager proposes the correct entries so that you can later have the certificates signed by the SAP Trust Center Service. In particular, set the following values:

      Name = *.<Domain of AS ABAP>

      Do not replace the asterisk (*) with a host name. The default PSE must also exist even if separate PSEs are created for all of the instances.  Here, “Name” represents the X.500 attribute “Common Name” (CN).

    2. Optionally create individual PSEs for individual instances. A list of all active instances is displayed in a second dialog box if you open the right-mouse-button context menu item “Change” over SSL Server Standard. The proposed Distinguished Name (DN) contains the following entry:
      Name = <Host name>.<Domain of AS ABAP>

      Ensure that each instance is assigned the fully qualified host name that is used in the HTTPS protocol. A DN can be assigned to multiple instances at the same time, for example, if a Network Address Translators (NAT) is used – in this case, as CN, the fully qualified host name of the NAT must be specified. All instances with an empty DN receive the default PSE. In Release 6.10, the “Create” checkbox dictates whether the instance gets its own PSE. Note that each DN can have a maximum of 255 characters.

    3. Create certificate requests for all instance PSEs. Expand the “SSL server” node in the tree control, double-click to load the instance PSE into the relevant node and select the “Generate certificate request” function.

      For the default PSE, you must only create a certificate request if there are instances without their own PSEs (in this case, double-click to load the default PSE into the “SSL server” node). Send the certificate requests to a CA such as the SAP Trust Center Service (http://service.sap.com/tcs). The certificate response must be either a PKCS#7 package with a complete upwards path or a text file that contains a list of all of the required certificates in PEM format (with the header “—–BEGIN CERTIFICATE—–” and the footer “—–END CERTIFICATE—–“).

      As of Release 6.20, you can also import the certificate response as an individual PEM certificate if the CA certificate is saved in the database (to search for certificates, select “Import certificate”, category = “Server CA”). Using the SAP Trust Center Service ensures that the certificate response has a valid format. Always import the certificate response into the PSE from which the original certificate request was generated (double-click on the corresponding nodes and call the “Import certificate response” function) and save the changes.

    4. If you want to allow logon via the client certificate, import the root certificate of the CA user into one of the SSL server PSEs. When you save, the system updates the certificate list of all SSL server PSEs. The certificate list contains the root certificates of those CAs whose user certificates are to be accepted.
  4. Creating the SSL client (Standard) PSE / SAPSSLC.pse
    and the SSL client (Anonymous) PSE / SAPSSLA.pse

    The intended purpose of SSL client PSE (Standard) is for communication with other (organization-internal) SAP Systems and other servers of the same SAP system (including itself), using an SSL client certificate for authentication.  An SSL client certificate can only be used on a connection, when a server explicitly requests it during the SSL/TLS handshake (which for icm is configured through icm/HTTPS/verify_client=1/2 or the service-specific VCLIENT=1/2 setting).
    When creating SSL client (Standard) PSE, STRUST proposes the subject name:

    Name = <System SID> SSL client default

    When SSL client PSE (Standard) does not exist, the server SSL PSE (SAPSSLS.pse) will be used as fallback.  When using this PSE to communication with other SAP systems, it is strongly recommended to request and install a CA-signed certificate, because this will significantly simplify the configuration of the necessary trust relationships, for verifying this system’s SSL client certificate on remote servers.  It is OK to use your own organizational CA for issuing SSL client certificates that are used for organization-internal authentication.

    The intended purpose of SSL client PSE (Anonymous) is for communication with third-party Systems that use server-only authentication, and in a fashion somewhat similar to a regular web browser.  When using SSL client PSE (Anonymous), no SSL client certificate will be sent to servers.  This includes defective/misconfigured servers, that send an incomplete request for a client certificate, and fail to provide a list of acceptable certificate_authorities.  Some of those latter servers get highly confused and erroneously abort the TLS handshake when receiving an arbitrary self-signed SSL client certificate, or an SSL client certificate from a CA unknown to the server, in response to an incomplete request for an SSL client certificate.  Since the certificate of the Anonymous PSE is not used, the Name in its certificate does not matter, and self-signed is fine.

    When SSL client PSE (Anonymous) does not exist, the client SSL PSE (SAPSSLC.pse) will be used as fallback (and another fallback to SAPSSLS.pse is used, when SSL client PSE (Standard) does not exist either).

    IMPORTANT: Different to Web Browsers, SAP WebAS does not come with a huge amount (350+) of pre-installed and pre-trusted (Root)CA certificates of omnipotent public CAs.  Another difference is, that each (client) SSL PSE contains a seperate and independent list of trust anchor certificates for verifying server certificates / server certificate chains.  (Only the Certificate Lists of the instance-specific SSL server (Standard) PSEs are synchronized by STRUST, so that all AppServers will use the same list of acceptable certificate_authorities for SSL client certificates).

    For each communication scenario that uses a particular SSL client PSE, the SSL/TLS certificate (chain) of a server can only be verified, if suitable trust anchor certificate is added, or has previously been added, to the “Certificate List” of the chosen SSL client PSE.  Creating&verifying the necessary trust relationship is required configuration step for every communication scenario that uses SSL/TLS, and each application scenario or web service that publishes/uses a HTTPS URL for access, must describe where to obtain the trust anchor certificate that will be necessary to verify the SSL/TLS certificate of the server.

    If you forgot to configure trust, or when the server certificate was unexpectedly replaced with one from a different issuer, or when a man-in-the-middle attack is performed on the connection, the TLS handshake will (and must) fail with the error ICM_HTTP_SSL_PEER_CERT_UNTRUSTED / SSSLERR_PEER_CERT_UNTRUSTED.  To overcome this handshake failure, you will have to check whether you forgot to configure trust (missing trust anchor), or whether a change in the issuer of the server certificate is appropriate (unexpected certificate issuer), or whether someone is performing a man-in-the-middle attack on the communication and trying to impersonate the real server, and correct/adjust your configuration accordingly.  In some environments, man-in-the-middle impersonation attacks may be performed by “SSL intercepting proxies” operated by your own IT department.  In such a situation, you will have to talk to your own IT department on guidance how to configure your communication scenario.  Should the communication require the use of an explicit SSL client certificate, then this communication scenario will have to be permitted untampered by that proxy.

    Service providers that intend to replace their current SSL/TLS server certificate with one from a different CA, or a server certificate issued under a different RootCA certificate of the same CA, will have to provide ample advance notice to all of the users / consumers of that service, so that the trust configuration of all clients can be updated before the new server certificate is installed.

  5. Creating Additional SSL Client PSEs (Optional)

    You can define additional SSL client identities (Environment -> SSL client-> Identities) for individual, application-specific communication scenarios.  After creation of new SSL Client identities, new nodes are displayed in Trust manager (STRUST).  You can now create the relevant PSEs, and when the communication scenario use authentication by SSL client certificate, get your public key certificates signed by a CA that is accepted for this communication scenario.  Similar to the two default SSL client PSEs, you will have to add the relevant trust anchor certificate for verification of the server certificate (chain) to the “Certificate List” of your custom SSL client PSE or you will encounter the lack-of-trust error (ICM_SSL_PEER_CERT_UNTRUSTED / SSSLERR_PEER_CERT_UNTRUSTED).  Where/how to obtain that trust anchor certificate must be specified in the description of your application scenario or by the service provider operating that service.

    Note that the changes made to SSL PSEs in Trust Manager (STRUST), such as importing the certification response of a CA, and changes to the Certificate List of trust anchors, will be updated at runtime (with no interruption of service) only in Netweaver AS ABAP 710 and later plus AS ABAP 702.  On releases of Netweaver 700/701 and 64x, the changes will take effect only after you manually restart the ICMAN process (transaction SMICM, “Administration -> ICMAN -> Exit Soft -> Global”).  Changes to SSL PSEs of standalone programs that are not maintained through Trust Manager (STRUST) also require restart of the affected program (sapwebdisp, msgsrv, sapstartsrv, saphostagent).

  6. Configuration of Available SSL Cipher Suites (Optional)

    You can configure the available SSL/TLS cipher suites and their order for AS ABAP (icmansapwebdispmsg_server, and sap_http), plus incoming SSL-proteccted communication of SAP AS Java 710+ with the following two profile parameters.  Outgoing SSL-protected communication from SAP AS Java (all versions) are NOT affected by these settingss, because these use the native-Java OEM SSL-Implementation “IAIK” included with SAP AS Java rather than SAPCRYPTOLIB to provide SSL/TLS protection.

    (all Netweaver Releases) ssl/ciphersuites =
    (740+ and 70x/71x/72x
    with Kernel patch 1433874)
    ssl/client_ciphersuites =

    For SAP servers using SAPCRYPTOLIB, the server-side cipher suite preference order takes precedence over the client-proposed list when searching for a common cipher suite with a client.

    NOTE: When adding above profile parameters to AppServer profiles with profile maintenance transaction RZ10 on SAP Netweaver 73x or earlier, please ignore RZ10 warning(s) “Unknown Parameter … a check cannot be performed”.  The default cipher suite settings up to SAP Netweaver 73x are built-in defaults rather than predefined profile parameters.  Below is a list of default values for the above profile parameters by Netweaver Release, and the resulting list of cipher suites.  Please see section 7 for currently recommended custom settings for the above two profile parameters.

    Outgoing SSL connection (SSL client) will all offer the cipher suites configured by (ssl/client_ciphersuites).  Netweaver Kernels predating the Kernel patch from SAP Note 1433874 use the “ssl/ciphersuites” setting also for outgoing SSL connections.  For backwards compatibility, Kernel patch 1433874 does not have a built-in default setting for “ssl/client_ciphersuites“, and will use the “ssl/ciphersuites” setting as fallback unless a custom setting is configured.

    Incoming SSL connections (SSL server/services) can optionally be configured to use service-specific cipher suite settings in the SSL configuration part icm/ssl_config_<xx> for an icm server port definition icm/server_port_<xx> via the string parameter CIPHERS:

    icm/server_port_<xx> = …, SSLCONFIG=ssl_config_<yy>
    icm/ssl_config_<yy> = …, CIPHERS=

    The contents of parameter CIPHERS is subject to the same rules and syntax that applies to profile parameter ssl/ciphersuites.

    CAVEAT: for CommonCryptoLib 8.4.38 and newer, please refer to the output of “sapgenpse tlsinfo DEFAULT” (for server) and “sapgenpse tlsinfo -c DEFAULT” (for client) in order to determine the exact TLS cipher suites supported by your version of CommonCryptoLib with either “DEFAULT” settings, or with custom cipher suite configurations, such as “HIGH” or “PFS:HIGH“,
    e.g. “sapgenpse tlsinfo PFS:HIGH“.

    The following table covers only TLS cipher suites available in SAPCRYPTOLIB 5.5.5pl28+ and CommonCryptoLib 8.4.10->8.4.37, and in the default preference order of Netweaver 740+, as well as Netweaver 70x, 71x and 72x with Kernel Patch 1433874:

    Category Pos. numeric ID Name(s) of SSL/TLS Cipher Suite TLS protocol version support
    HIGH    1.  0x00, 0x2F TLS_RSA_WITH_AES128_CBC_SHA TLSv1.2,TLSv1.1,TLSv1.0,SSLv3
    HIGH    2.  0x00, 0x35 TLS_RSA_WITH_AES256_CBC_SHA TLSv1.2,TLSv1.1,TLSv1.0,SSLv3
    MEDIUM    3.  0x00, 0x05 TLS_/SSL_RSA_WITH_RC4_128_SHA TLSv1.2,TLSv1.1,TLSv1.0,SSLv3
    MEDIUM    4.  0x00, 0x04 TLS_/SSL_RSA_WITH_RC4_128_MD5 TLSv1.2,TLSv1.1,TLSv1.0,SSLv3
    HIGH    5.  0x00, 0x0A  TLS_/SSL_RSA_WITH_3DES_EDE_CBC_SHA TLSv1.2,TLSv1.1,TLSv1.0,SSLv3
    *LOW    6.  0x00, 0x09 TLS_/SSL_RSA_WITH_DES_CBC_SHA              TLSv1.1,TLSv1.0,SSLv3
    *EXPORT    7.  0x00, 0x08 TLS_/SSL_RSA_WITH_DES40_CBC_SHA                           TLSv1.0,SSLv3
    *EXPORT    8.  0x00, 0x06 TLS_/SSL_RSA_WITH_RC2_CBC_40_MD5                           TLSv1.0,SSLv3
    *EXPORT    9.  0x00, 0x03 TLS_/SSL_RSA_WITH_RC4_40_MD5                           TLSv1.0,SSLv3
       ( **EXPORT  10.  0x00, 0x02 TLS_/SSL_RSA_WITH_NULL_SHA TLSv1.2,TLSv1.1,TLSv1.0,SSLv3 )
       ( **EXPORT  11.  0x00, 0x01 TLS_/SSL_RSA_WITH_NULL_MD5 TLSv1.2,TLSv1.1,TLSv1.0,SSLv3 )

    *these cipher suites are disabled by default in SAP Netweaver 740+
    **these cipher suites are disabled by default in SAP Netweaver 700+

    NOTE: CommonCryptoLib 8.4.38 added support for cipher suites providing Perfect Forward Secrecy (PFS) based on the ECDHE key exchange, and TLSv1.2 AEAD cipher suites (AES-GCM).  CCL 8.4.38+ inserts two TLSv1.2 AEAD cipher suites from rfc5288 (TLS_RSA_WITH_AES128_GCM_SHA256 and TLS_RSA_WITH_AES256_GCM_SHA384) into class HIGH and at the beginning of the above list.  PFS cipher suites were added as a seperate class “PFS” and have to be explicitly enabled.  See SAP Note 2181733 for details.  For use of PFS cipher suites on x86_64 platforms, please use CommonCrypotLib 8.4.48 or newerWhen enabling the FIPS crypto kernel (profile parameter ccl/fips/enable=1) you MUST use CommonCryptoLib 8.4.48 or newer to get PFS cipher suites.  The command line tool “sapgenpse” of CommonCryptoLib 8.4.38+ provides a new command “tlsinfo” to visualize the resulting cipher suites, their ordering and the enabled TLS protocol versions.  You can use “sapgenpse tlsinfo” to query the resulting behaviour for parameter values that you can configure through profile parameters ssl/ciphersuites and ssl/client_ciphersuites.

    The following table shows the default / built-in cipher suite configuration settings for different Releases of SAP Netweaver, and which cipher suites from the previous table will be available as result (and their order):

    Netweaver Releases  profile parameter(s)  default value(s) / built-in defaults cipher suites & order
     742+ ssl/ciphersuites=
    ssl/client_ciphersuites=
    HIGH:MEDIUM:+e3DES:!aNULL
    HIGH:MEDIUM:+e3DES:!aNULL
    1,2,3,4,5
    1,2,3,4,5
     740, 741 ssl/ciphersuites=
    ssl/client_ciphersuites=
    193:HIGH:MEDIUM:+e3DES:!aNULL
    192:HIGH:MEDIUM:+e3DES:!aNULL
    1,2,3,4,5
    1,2,3,4,5
     70x, 71x, 72x with
    Kernel patch 1433874
    ssl/ciphersuites=
    ssl/client_ciphersuites=
    HIGH:MEDIUM:+e3DES:LOW:EXPORT:!aNULL:!eNULL
    <undefined>*
    1,2,3,4,5,6,7,8,9
     640 patch level 414 ssl/ciphersuites=
    ssl/client_ciphersuites=
    HIGH:MEDIUM:+e3DES:LOW:EXPORT:!aNULL:!eNULL
    <undefined>*
    1,2,3,4,5,6,7,8,9
     70x, 71x, 72x ssl/ciphersuites= MEDIUM:HIGH:LOW:EXPORT:!aNULL:!eNULL 3,4,1,2,5,6,7,8,9
     6xx ssl/ciphersuites= MEDIUM:HIGH:LOW:EXPORT:!aNULL 3,4,1,2,5,6,7,8,9,10,11

    * <undefined> means that for strict backwards compatibility with earlier Kernels, there is no built-in value.  Unless an explicit value is configured for the parameter ssl/client_ciphersuites, the setting of ssl/ciphersuites will also apply to outgoing/client communication.

    If you want the cipher suite with AES256 encryption to have the highest preference, do not want to use any cipher suites from the MEDIUMEXPORT or LOW category, you would have to use the following value for the configuration:

    ssl/ciphersuites = eAES256:HIGH
    ssl/client_ciphersuites = eAES256:HIGH

    This setting will result in the ordered list of four cipher suites (2,1,5) from the cipher suite list above.
    (FYI: The only ciphers in the MEDIUM class are those with RC4_128 encryption — an algorithm with a long-known weakness, but no imminent security problem — and RC4_128 may still occasionally be necessary for interop with a few communication peers).

    The parameter parts for the configuration of the ciphersuites are based on a combination of simple set theory and the preferred ciphersuites sequence. The syntax of this cipher suites parameter is only vaguely similar to OpenSSL and differs substantially in names of individual ciphers from current OpenSSL versions.

    With the category, you select which cipher suites come into consideration. With the sequence of the categories, you determine the preferred cipher suites. And with specifications such as !eNULL!eRC4!eDES!eRC2, you can delete certain cipher suites from the selected categories from the list of selected cipher suites.  The use of eAES256 will place matching cipher suite(s) to the position where this specifier is placed within the string.

  7. (Optional) Configuration of Available TLS Protocol Versions

    SAPCRYPTOLIB 5.5.5 and its successor CommonCryptoLib 8 support the following SSL & TLS protocol versions:

    SAPCRYPTOLIB 5.5.5 <= pl26 server: SSLv3, “BC”
    client:   SSLv3
    SAPCRYPTOLIB 5.5.5 >= pl28

    CommonCryptoLib 8 <= 8.4.30

    server: SSLv3, TLSv1.0, “BC”
    client:  SSLv3, TLSv1.0
    CommonCryptoLib 8 >= 8.4.31 server: SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, “BC”
    client:  SSLv3, TLSv1.0, (TLSv1.1, TLSv1.2)

    For use in AS ABAP 70x or 71x, CommonCryptoLib 8 requires a downward-compatible 72x Kernel (at least 720 patchno 88). CommonCryptoLib 8 can not be used in AS ABAP 640 and neither with Netweaver Kernels 70x and 71x (which have been out of maintenance for quite some time now).

    Over the course of year 2016, a growing number of TLS servers (e.g. Ariba, German BAFA, HR-GKV & HR-DRV, Salesforce, etc.) was reconfigured to abort/reject TLSv1.0 handshakes for various fairly lame reasons (long known security design limits that are irrelevant in the real world, and which could be seen as weaknesses but are no vulnerabilities).  With respect to these server configuration changes, the currently recommended setting is (this requires at least CommonCryptoLib 8.4.38, recommending at least 8.4.49):

    ssl/ciphersuites  =  135:PFS:HIGH::EC_P256:EC_HIGH
    ssl/client_ciphersuites  =  150:PFS:HIGH::EC_P256:EC_HIGH

    which enables TLSv1.2+TLSv1.1+TLSv1.0, support for Perfect Forward Secrecy (PFS) cipher suites, and blind sending of client certificates for outgoing SSL/TLS-protected communication.  This setting disables RC4-based TLS cipher suites.

    BEWARE:  When copy&pasting profile parameter names from this SAP Note HTML display into the RZ10 profile editor, you may accidentally copy bogus Unicode Byte-Order-Mark (BOM) characters into the profile, which may cause the parameters to remain invisible to the SAP Netweaver kernel code.  This is a silly bug in the SAP Notes HTML display, and more silly bugs in all involved software components that copy the BOMs through into the profile (instead of dropping the bogus BOMs).

    Enabling TLSv1.1 or TLSv1.2 for outgoing/client communication (ssl/client_ciphersuites) may result in TLS handshake failures with a small, decreasing, but still non-marginal number of defective and/or old TLS server implementations, which will otherwise handshake TLSv1.0 just fine.  The erratic server behaviour comes in several different flavours, such as the presence of protocol version TLSv1.2 in ClientHello.client_version, or the inclusion of TLS extensions in the ClientHello handshake message (elemica) or proposing TLSv1.2 without TLS extensions (causes Microsoft Windows 2008R2 and 2012R2 to choke) or the use of SSL/TLS client certificates in TLSv1.2 with (sha256,rsa) signatures (fails with certain SSL Load Balancers).  Unfortunately, the IETF TLS working group has not yet standardized a suitable alternative TLS protocol version negotiation scheme that would allow TLS clients to safely negotiate protocol versions > TLSv1.0 and TLS extensions in a fashion that will not break interoperability with the installed base (i.e. not break interop with TLS version intolerant and/or TLS extension intolerant servers and/or defective TLSv1.2 implementations).  Web Browsers invented a heuristics-based, complex and insecure approach (“Downgrade Dance”) to this non-marginal TLS interop problem … and browsers therefore got bitten by POODLE.

    The protocol version TLSv1.0, that was added with SAPCRYPTOLIB 5.5.5pl28+ is proposed or used by default if the communication partner also supports it.  TLSv1.1 and TLSv1.2 support are enabled for the server-side by default if the library implements them.  For the client-side, the default protocol is limited to TLSv1.0 because of a non-marginal number of version-intolerant TLS Servers that will choke and fail the TLS handshake when faced with TLSv1.1 or TLSv1.2 in the TLS ClientHello handshake message.

    NOTE: In order to ensure interoperability with other communication peers and with itself (client to server), CommonCryptoLib will automatically enable TLSv1.0 and TLSv1.1 whenever TLSv1.1 or TLSv1.2 is requested/enabled through configuration.  If you really want to disable TLSv1.0 and/or TLSv1.1, you need at least CommonCryptoLib 8.4.48 and must select “Strict protocol version configuration” (bitflag with value 32) in the protocol version flags.  This is discouraged. You may encounter interoperability problems with some commmunication peers that can only be resolved by _not_ using the “strict protocol version configuration”.

    The protocol option “BC” for “Backwards Compatibility” allows an SSL Version 2.0 CLIENT-HELLO (“SSLv2Hello” in Java) as the first message of an SSLv3 or a TLS handshake.  For a description of this backwards compatibility, see the following sections of the relevant standards:

    http://tools.ietf.org/html/rfc6176#section-3
    http://tools.ietf.org/html/rfc5246#page-89

    A possibility for configuring TLS protocol versions was added with the kernel correction described in SAP Note 1433874.  A number value (protocol version flags) can be inserted at the beginning of the SSL/TLS cipher suites strings in profile parameters ssl/ciphersuites and ssl/client_ciphersuites.  This number has to be computed (added up) from the following (bit-flag) values:

    Value Description
    1 “BC”– Option (allow SSL Version 2.0 CLIENT-HELLO / SSLv2Hello)
    2 “Best”– Option (activate highest available TLS protocol version)
    4 “NO_GAP”– Option (no gaps between TLS protocol versions; is forced to date)
    16         Allow blind sending of a client certificate (5.5.5pl36+ and all CCL 8.4.xx)
    32 “Strict protocol version configuration” option–do not automatically enable TLSv1.0
    (recognized/supported only by CommonCryptoLib (CCL) 8.4.48 or higher)
    64 SSLv3
    128 TLSv1.0
    256 TLSv1.1  (only with CommonCryptoLib (CCL) 8.4.31 or higher)
    512 TLSv1.2  (only with CommonCryptoLib (CCL) 8.4.31 or higher)

    With the built-in defaults, the server-side has all SSL&TLS protocol versions plus BC enabled.  This corresponds to server-side protocol version flags (128+64+1) = 193 for SAPCRYPTO 5.5.5pl28+ and CommonCryptoLib 8 up to Version 8.4.30, and (512+256+128+64+1) = 961 for CommonCryptoLib 8.4.31+.  The built-in defaults for the client-side enables only SSLv3 + TLSv1.0 for SAPCRYPTO 5.5.5pl28+ and CommonCryptoLib 8, corresponding to client-side protocol version flags (128+64) = 192.  It is recommended to request TLS protocol version TLSv1.1 and TLSv1.2 with the flags “Best” and “NO_GAP”, because only the latter is future-friendly and is fully compatible with older libraries.

    The previous recommendation (conservative, interoperable and still secure, disabling only SSLv3 and RC4-based TLS cipher suites, and proposing only TLSv1.0 for outgoing communication) was:

    ssl/ciphersuites = 135:HIGH
    ssl/client_ciphersuites = 144:HIGH

    For (the small, but non-marginal) amount of communication peers that still need RC4-based cipher suites, you will have to include class “MEDIUM” as fallback for interoperability, resulting in:

    ssl/ciphersuites = 135:HIGH:MEDIUM
    ssl/client_ciphersuites = 144:HIGH:MEDIUM

    Both settings can be used with all SAP Netweaver releases and all Library versions (though the kernel correction from SAP Note 1433874 is necessery to affect the TLS protocol version(s) used by the library).  On the server side, 135 = (128+4+2+1) enables all TLS protocol versions supported by your current library with the exception of SSLv3 plus the SSLv2 ClientHello compatibility option.  On the client side, 144 = (128+16) enables TLSv1.0 plus blind sending SSL client certificates even for servers that send a malformed CertificateRequest TLS handshake message. This should provide a high level of interoperability and ensure the negotiation of TLSv1.0 with every Server that supports TLSv1.0.  Should you encounter interoperability problems with a few leftover and buggy SSLv3-only servers, you could try enabling the deprecated protocol version SSLv3 on the client-side:

    ssl/ciphersuites = 135:HIGH:MEDIUM
    ssl/client_ciphersuites = 208:HIGH:MEDIUM

    Attacks like “BEAST“, “CRIME” and “Poodle” do not affect programmatic TLS clients.  These attacks require several vulnerabilities to be present in a TLS client, and can only be mounted against feature-bloated clients such as Web browsers.  One of the prerequisites is willingness to execute active content provided by the attacker (such as JavascriptJavaFlash, and so on). These attacks also require that the TLS client gives the attacker free access to a Cross-Site-Request-Forgery (CSRF) facility, a browser misfeature. which will happily insert session cookies and supply user credentials to arbitrary GET and POST requests authored by attackers.

  8. Information about Interoperability with other SSL and TLS implementations
    1. Some Servers (including Servers hosted by Content Distribution Systems such as cloudfront) are being co-hosted with lots of other servers on a single IPv4 address, and are accessible only when Clients include TLS extension server_name_indication (SNI) from rfc6066 in their ClientHello handshake messages.  Sending of TLS extensions is unfortunately not backwards compatible with a small, but non-marginal set of old Servers, so TLS extensions are not sent by default.  For SAP Netweaver 741+ Kernels, sending of TLS extension SNI can be enabled through profile parameter icm/HTTPS/client_sni_enabled starting with Kernel Patch 2124480.  Sending of TLS extension SNI as client can alternatively be enabled in 722 Kernel patchno 223 and higher through profile parameter ssl/client_sni_enabled, see SAP Note 2384290.
    2. Microsoft SChannel in Windows 2008R2 and Windows 2012R2 will erroneously choke and abort the TLS handshake when a client offers TLSv1.2 in an extensionless ClientHello handshake message with ClientHello.client_version = TLSv1.2 and the server certificate is signed with sha256WithRsaEncryption.  The recommended workaround to this Microsoft SChannel shortcoming is to use CommonCryptoLib 8.4.48+ and enable PFS cipher suites (ssl/client_ciphersuites=150:PFS:HIGH).  Lesser desirable workarounds are to limit the protocol version to TLSv1.1 on the Microsoft server side (this server-side limit was the default in original Windows 2008R2) or to limit the protocol version to TLSv1.1 on the SAP client side (ssl/client_ciphersuites=400:HIGH).
    3. Microsoft Windows 2012 ADFS chokes and aborts on TLS handshakes from TLS client that do not include TLS extension server_name_indication because it fails to define a suitable default server certificate.  Possible workarounds to this Windows 2012 shortcoming are manually adding the missing mapping of a default server certificate on the Microsoft Server, or enabling sending of TLS extension SNI in SAP Netweaver 742+ clients as described in SAP Note 2124480, or in Netweaver 722+ clients as described in SAP Note 2384290, or manually fixing the missing backwards compatibility in Windows 2012R2, e.g.
      https://blogs.technet.microsoft.com/applicationproxyblog/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2/
    4. The protocol option “BC” (Backwards Compatibility) is required for interoperability with JavaSE 6 (still in use in Android 4.4 and several J2EE servers), Microsoft Internet Explorer (MSIE) Version 6 on Windows XP and Windows 2003Firefox up to Version 3.0 and possibly other, mostly older, browsers and SSL clients.

      Background: XP and 2003 were delivered with MSIE Version 6, and SSLv2 is activated and TLSv1.0 is deactivated there by default.  When you upgrade MSIE to Version 7 or 8, SSLv2is deactivated and TLSv1.0 is activated.  However, the basic attributes of the SChannel component of the underlying Windows version are not changed by an MSIE upgrade.

    5. The attributes that can be used by Microsoft Internet Explorer for SSL or TLS are determined by the capabilities and attributes of the underlying operating system version, especially the security provider SChannel and the Microsoft CryptoAPI — regardless of which browser version you have installed.

      Some attributes are available on older versions of Microsoft Windows only after a Microsoft HotFix has been installed manually.

      Microsoft SChannel support for AES cipher suites:

      XP 32-bit:
      2003, XP 64-bit: http://support.microsoft.com/kb/948963

      Microsoft CryptoAPI Support for SHA256-based digital signatures, which includes SSL server certificates:

      Microsoft SChannel It supports the use of the AES-based cipher suite (rfc3268) of SAPCRYTPOLIB pl28+ only in combination with protocol version TLSv1.0 and higher since Windows Vista(plus Windows 2003 after the manual installation of Microsoft Hotfix 948963).

      Firefox 3+Google Chrome, and OpenSSL 0.9.8+ support AES-based suites both on Windows XP and in combination with SSLv3.

Software Components
Software Component From To And Subsequent
KRNL64NUC 7.40 7.40
KRNL64UC 7.40 7.40
SAP_BASIS 610 640
SAP_BASIS 700 702
SAP_BASIS 710 730
SAP_BASIS 731 731
KERNEL 7.40 7.40
References
Attributes
Name Value
Other Components BC-MID-ICF Internet Communication Framework
Other Components BC-SEC-SSF Secure Store and Forward
Transaction codes SMICM
Transaction codes STRUST

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *