Skip to Content

With SAP NetWeaver Application Server ABAP 7.40 SP8 it is possible to activate an encrypted and authenticated communication between the SAP Netweaver AS ABAP server components. This security measure is very easy to configure and allows to replace ACLs that have been used so far to secure the communication between server components.  (For the ACL configuration see for example the SAP Help Doku . This will not be explained in this blog.)


IMPORTANT: The functionality is currently in a pilot phase. Interested customers should check SAP Note 2040644 for current limitations.


Use Cases

There exist several options to secure the communication between the ABAP server components. one possibility is to secure the network segment where the server components reside to ensure that they can not be reached from outside the segment. It is still possible to use the ACLs .

The new option allows to encrypt and authenticate the traffic between the system components with SSL.


How it works

During the first system restart after the activation of the secure server communication, the SAP Start Service sets up a certificate infrastructure (a system internal PKI). All instances of the SAP NetWeaver AS for ABAP server are integrated into the PKI and receive an instance specific certificate with private key that they can use to authenticate and to encrypt their system internal communication with other system instances.

  • The certificates are automatically renewed.
  • The root PSE file is stored in the secure store of the file system.
  • All other instance PSE files are encrypted with a PIN that is stored in the secure store of the file system as well.

After the setup of the PKI, all communication between system instances uses SSL for encryption and authentication.

Keep in Mind: This encryption is only active for the system internal communication . All external communication for example RFC communication with external RFC server is NOT encrypted unless it is done separately via SNC or SSL. The trust of the system PKI can only be used internally in the system.

Overview: Secured connections between application server components with activated secure server Communication

/wp-content/uploads/2015/04/communications_681648.jpg

  • The “red” connections that are encrypted via Secure Server Communication and the internal PKI
  • The “green” connections are external HTTP communications that can be secured using SSL
  • The “blue” connections are external RFC communications that can be secured using SNC
  • The “black” connections are connections to the Message Server. They are used top gather the list of application servers.
  • The “violet” connections are local host internal
  • The “yellow” internal ICM communication can be secured as described in the SAP Help Documentation.

  • The connections that are described with a circle (ICM and GW) are internal RFC or HTTP communications between these components.

Further use cases for the System PKI

The system PKI is not only used for the secure server communication.


  • Since 742 sapstartsrv always initializes the System PKI and offers an https based access to his web service methods with a certificate of the system PKI. Sapstartsrv also uses the system PKI to make calls to another sapstartsrv instance in the same system.    
  • Several ABAP transactions use the system PKI to communicate with a sapstartsrv of the same system (mainly the ASCS instance)     
  • sapcontrol can use the system PKI with the option   “-systempki” . Installation and  Upgrade use this option.

Limitations and Possible Incompatibilities

  • The usage of SSL results in a higher CPU consumption and a modest performance impact (~1%)
  • For ABAP servers with a high load of internal RFC communication the performance impact can be higher.
  • If customer components addressed a server component via an internal port this is no longer possible as external components cannot be  part of the internal PKI infrastructure.  External components now necessarily need to communicate over the external ports. All external SAP components use the external ports as well for example GWMON MSMON DPMON or LGTST.
  • For the SAP tool SAPEVT please check SAP Note 2000417


Configuration

  1. Stop all instances of the system (including e.g. ASCS, ERS) by using e.g. SAP MMC:  “Stop…” context menu on the system node or Command line tool: “sapcontrol … -function StopSystem”.

  2. Add the following profile parameter to the default profile DEFAULT.PFL of the system: system/secure_communication = ON

    It is also possible to use the value “BEST” instead of “ON” . If best is used and for some reason a server component is unable to communicate via SSL an unencrypted communication is possible as a fallback mechanism without an error. All other communications remain encrypted via SSL.

  3. Restart of Start Services of all instancesof the system by using e.g. SAP MMC: “All Tasks->Restart Service” context menu for each instance

    Command line tool: “sapcontrol … -function RestartService”.

  4. Start the system using e.g. SAP MMC: “Start…” context menu on the system node or Command line tool: “sapcontrol … -function StartSystem ALL”.

  5. Verify that all instances are displayed “green” in SAP MMC or “sapcontrol … -function GetSystemInstanceList”.

In transaction SM51 you will see that SSL is now used:

/wp-content/uploads/2015/04/sm51_679037.jpg

See also the  SAP Help Documentation.

Troubleshooting

IMPORTANT: The parameter system/secure_communication can be safely switched back to the OFF position without harming the system.

Using the command line tool “sapcontrol”

Checking the system status with “sapcontrol”


It is possible to check the usability of the System PKI with “sapcontrol” (without changing anything in the system). To do this use:


      sapcontrol -nr <NR> -systempki <Profile> [-host <HOST>] [-debug] -function AccessCheck Stop

Remarks:

  • Result: You should get an “AccessCheck OK” if no error is found.
  • The parameter <Profile> needs to contain the profile of a local instance.
  • With the parameters “-nr” and “-host” the connection to all system instances using the system PKI can be tested.
  • The parameter “-debug” allows to trace the SSL handshake
Reset the System PKI with “sapcontrol”

In general it should not be necessary to reset the PKI as the whole certificate lifecycle is triggered automatically. If ever you want to enforce it there exist 2 web service methods in the “sapcontrol” which are also used by the system internally to maintain the PKI:

  • UpdateSystemPKI[<force>]       “Updates the whole system PKI
  • UpdateInstancePSE[<force>]     “Updates an instance PSE

If the parameter force=0 (default value) the update is only done when considered necessary by the system with force=1 the update is enforced.

ABAP check reports

To check the internal PKI some ABAP check reports exist that can be executed in SE38 . They should not show any error messages:

  • SSFPKITEST1      Checks the system PKI (root and instance PSE)
  • SSFPKITEST2      Checks a remote application server of the system
  • SSFPKITEST3      Shows the certificate and the certificate list of the application server

Related notes:

  • Sapcontrol SSL usage: Note 1642349
  • Problems with the use of the system PKI: Note 2200230

Useful information for SAP Support

If you need help from SAP Support the following information is helpful to analyze problems with the System PKI :

  • Secure store files in $(rec/ssfs_datapath)
  • If available secure store key files in $(rec/ssfs_keypath)
  • The Instance PSEs of all instances: $(DIR_INSTANCE)/sec/sap_system_pki_instance.pse
To report this post you need to login first.

5 Comments

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

  1. Julius von dem Bussche

    Thank you!

    Do you know whether new installations will have this parameter as default to ON or BEST? It is always problematic to retro-fit such features, so best would be a default to BEST in my opinion.

    Cheers,

    Julius

    (0) 
    1. Martin Voros

      I am not sure that BEST as default option is the best. We have seen in recent months (SSL issues) that leaving these backward compatibility features can result in downgrade attack. It is probable better to leave this to admins to explicitly enable this.

      This sounds like a nice feature for cloud deployments where traditional techniques do not work. I am wondering if it is possible which cipher suite is used for this.

      (0) 
    2. Matthias Buehl Post author

      Currently the parameter default for new installations is OFF. We plan to change the default in the future when we have some more experience with systems that are used for different purposes.

      (0) 
  2. Ulrich Wolf

    When enabling this and running SSFPKITEST3 i see that the Certificate is in SHA1 and 1024 Bits, how can i influence that?  Since at least 2005 we know that SHA1 isn’t secure anymore 😉 So any possibilities there?


    Best Regards, Uli

    (0) 
    1. Matthias Buehl Post author

      We are currently working on that. It is not configurable but it will be made available in the future. Probably as new values without configuration.

      (0) 

Leave a Reply