Summary

Certificate Lifecycle Management is a solution to automatically renew certificates. It is part of the product SAP Single Sign-on.

This blog describes the configuration in the Secure Login Server and how to connect an AS ABAP as well as an AS Java. Configuring a Remote CA or using the commandline client are not part of this blog and may come in some future post.

This blog assumes that you are familiar with the general Certificate Lifecycle Management process.

Prerequisites

The Secure Login Server (SLS) needs to be installed. This application can be deployed into basically any recent AS Java.

Client Certificate Authentication must be possible at the SLS. This means that the SLS must request a client certificate (parameter icm/HTTPS/verify_client and/or subparameter VCLIENT in respective server port must be 1 or 2), the root CA of the client certificates issued by the SLS must be included in the trust store (often times the keystore view icm_ssl_<node>) and reverse proxies in between the client and SLS must forward client certificates and must be trusted (https://help.sap.com/docs/SAP_NETWEAVER_AS_ABAP_752/683d6a1797a34730a6e005d1e8de6f22/2a6cec67c50842aab1444f7dfd0257e1.html?locale=en-US). Without these settings, the renewal of any certificates will fail since apart from the initial enrollment all actions are based on client certificate authentication.

A user with administrative access to the SecureLoginAdministrationConsole (SLAC) is needed as well.

The AS ABAP needs to be current enough to support the CLM client. Information can be found in note 2452425. Releaseprerequisites for the AS Java (as a client) can be found here https://help.sap.com/viewer/df185fd53bb645b1bd99284ee4e4a750/3.0/en-US/48f05021dcdb4f6b992579d2ad228c4f.html.

User with authorizations for NWA (basically Administrator rights) and SLAC (SLAC_SUPERADMIN).

Configuration Secure Login Server

Before starting the configuration in the SLAC, a logon stack for the certificate based authentication of the systems needs to be created.

Configuration Logon Stack for Certificate Based Authentication

Go to the NWA of the SLS. There go to the Logon Stack configuration (NWA -> Configuration -> Authentication and Single Sign-On).

-> Add

Choose some name that reflects, that this is the logonon stack for the client authentication part of CLM.
-> Create

The logon stack has only one login module: SecureLoginModuleUserDelegationWithSSL
Three attributes needs to be set:
Rule1.subjectName: This can be used to filter for specific certificate subject using regular expressions. Using “(.*)” (without the quotes) disables the filter. However, the CN of the certificate still needs to match one of the names configured in the SLAC later on.
Rule1.issuerName: Similar to the subject name rule, this can be used to filter for specific issuers. A trust to the root CA still needs to exist. So most of the time, disabling the filter with “(.*)” (without the quotes) is enough.
UserMappingMode: this needs to be set to “VirtualUser” (without the quotes). Since the systems don’t exist in the UME as users, we map the certificate to virtual users. These are filtered within the SLAC configuration.

This logon stack is later used in all Application Profiles.

Configuration Certificate Profiles

The following certificate profiles need to be created:

• Registration Agent Profile (for Enrollment)
• One Profile per needed Certificate type
  Usually this is
  • SNC
  • TLS Server certificate
  • TLS Client certificate

Often, two TLS server certificate profiles are needed. One for certificates that do not yet have a Subject Alternative Name (SAN), where the SAN is created from the Common Name and one for certificates that already have a SAN.

The profiles are created via SLAC:

SLAC -> Profile management -> Authentication profiles -> Create

RA profile

Choose a name that reflects, that this is the RA profile. As client type choose “Application Server Profile” and for authentication a logon stack, that accepts password based authentication. This is necessary, since the client tools in AS ABAP and AS Java support only authentication via user and password.

Configure the certificate properties. Set the country code and the name of your organization. As key length, currently at least 3000 bit are recommended by some official authorities. Hence, most auditors are checking that certificates have at least 3000 bits.
Select the CA that should issue these certificates. This can be a remote CA or a local CA.

Configure an endpoint for this profile. The profile type is “Registration Agent” and as template a template for client certificates is needed.

Application Server Profiles

These profiles are for the renewal process, i.e. for signing certificates for a specific purpose. They all follow a similar pattern and are only distinguished by a few profile specific configurations.

First, we will see the configuration valid for all types. Then we will see the configurations specific to the different profiles.

-> Create a new profile

Give the profile a relevant name and description, select Application Server Profile and use the ClientCertCLM logon stack as authentication policy.
-> Next

Select the relevant issuing CA
-> Next

Select the relevant certificate template.
-> Next

=> Edit the profile

Enter a telling name (example above for the TLS Server profile with SubjectAlternativeNames present).

TLS Server Profile for requests containing SANs

This profile is for TLS Server certificates where the request already contains one or more Subject Alternative Names. This is usually the case for renewals or certificates that were created with the relative distinguished name “DNS=…” as part of the DN.

You can chose to either keep the incoming subject as is or set specific attributes in the upper part of the configuration.

TLS Server Profile for requests not containing SANs

This profile is used for TLS Server profiles where a SAN is not yet present. This is for example the case for certificates that were created in the NWA and have not yet been signed.

The important part here is to choose the Common Name as SAN (the CN usually holds the hostname).

This way, it is automatically set as SAN.

SNC

This profile is used to sign SNC certificates

Important: Keep the incoming Subject. Otherwise, the DN of the certificate might change, which in turn would lead to the disp+work processes in an AS ABAP not starting up.

TLS Client Profile

This profile is used to sign TLS Client certificates

Important: It is recommended to keep the Distinguished Name stable (as in the screenshot above). This way, certificate mappings don’t need to be adjusted after a renewal.

Creating an Application Server Profile Group

In the Secure Login Administration Console, go to “Application Server Profile Groups”.

There you can create a new group. This group should contain the RA profile as well as the other certificate profiles you created.

It is recommended to change the group ID to make the Metadata URL easier.

Under System Identifiers, you add the SIDs of the systems where you want to renew certificates. The Common Name of the RA certificate is checked against this list. The entries are allowed to contain upper case letters and numbers. However, they are not restricted to three characters, which gives you some room for the operating system renewals.

Configuration AS ABAP

The configuration in AS ABAP consists of running two reports. In newer systems, the reports are readily available. However, independent of their availability, it is always recommended to implement the newest versions via note https://launchpad.support.sap.com/#/notes/2452425.

First, run the report SSF_CERT_ENROLL. You need the SLS metadata URL and a user with password who is allowed to authenticate for enrollment.

The report will create a PSE entry in STRUST and create a signed client certificate, that is later used to authenticate the system for certificate renewal.

After the first report finished successfully, the report SSF_CERT_RENEW is run to renew entries in STRUST. To run it, you need the metadata URL and a grace period (min number of days, that a certificate should be valid before being renewed).

You will then see an overview of the certificates in your system with a selection screen for the different certificate profiles. Select the adequate profiles for the different entries and select, which entries should be renewed.

After running the report you should see a success message for each certificate

Save the settings in a variant and plan a regular background job that renews the certificates.
ATTENTION: In AS ABAP you have to plan the job yourself using the regular scheduling tools in your environment. In AS Java, the job scheduling is handled by the CLM application. In AS ABAP this has to be done by yourself.

Configuration AS Java

Within the AS Java, you need to import the package “Secure Login Library 3.0”. There the OS Independent package is an SCA that can be imported into an AS Java using telnet.

This gives you the CLM application, accessible via https://<host>:<port>/sapsso/clm

The CLM application needs access to the keystore views to renew certificates in them. This is done via the NWA:

In the NWA navigate to Configuration -> Certificates and keys. Under “Key Storage” go to “Security” and “Permissions by domain”. Filter for the CLM application and allow all actions on the Keystore Views you want to be renewed by CLM.

Then go to the CLM application.

There you first need to enroll the system (called here Registration):

You again need the metadata URL, then click on fetch to fetch the metadata from the SLS

Afterwards you are asked for a username and password of a user that is allowed to authenticate for CLM

Click on register and you will see the issued client certificate. Click on “Save” and “Home” to go to the main screen again:

Afterwards, you can start renewing certificates. The functionality can be found at the tile “Enrollment”

You don’t need to input the Metadata URL any more since this is already set. However, you need to select the keystore view you want to renew as well as the certificate.

After clicking on “Enroll Certificates” you see the renewed certificates and you can check them via the “Show Details” button.

After this you have the option to create a scheduled task that is executed regularly to keep the certificate up to date. Bear in mind that this job runs with the user that is currently logged on.

Conclusion

After this configuration, the certificates in AS ABAP and AS Java should be renewed regularly before reaching the end of their lifetime.

There are other options that are not covered by this guide. It is possible to fetch the certificates from a company PKI via an interface (a feature called Remote CA in the SLS). Also, certificates for other systems like HANA or the Web Dispatcher have to be renewed as well. This is done using the OS binary sapslscli, a command line client for the SLS. It can be downloaded as Secure Login Library 3.0 from the support portal.