Configuring Certificate Lifecycle Management
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.
The Secure Login Server (SLS) needs to be installed. This application can be deployed into basically any recent AS Java.
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).
Choose some name that reflects, that this is the logonon stack for the client authentication part of CLM.
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
- 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
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.
Select the relevant issuing CA
Select the relevant certificate template.
=> 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.
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.
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
Then go to the CLM application.
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.