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.
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).
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.
I'm following your blog and would like to take your expert advice. We have a requirement to integrate CLM with Venafi to fetch the certificates. It is possible?
I may be wrong, as far as I know, Venafi is kind of an improved RA and based on ADCS as the PKI. It uses certain standards such as MSCEP/NDES for communication with the ADCS. Enables simple processes to request and renew certificates and allows it to send reminders about soon expiring certificates (lifecycle). As there is no Auto-Enrollment support for SAP you would need to use the SAP SSO 3.0 solution and by this the SLS to establish another RA (Proxy System) to handle the CSR and forward them to the real CA behind, which could work in parallel with Venafi all together. SAP Secure Login Server (CLM) supports CA web enrollment and NDES. Sounds like a nice integration project and this would require some technical evaluation and PoC approach to ensure feasibility.
Concerning this subject, could you, please, let me know about the certificate list, for instance on the SSL Client Standard... this might be used even for renewing those certificates, I mean all the certificate list..
Thanks in advance for your help concerning this subject.
no, a full management of the certificate list is not supported. You can select a certificate store that is propagated into the certificate list when a certificate is renewed. However, there are quite a few restrictions:
So all in all, this solution is usuable in some very specific cases (you want the same trust list for all use cases, you don't need any individual trusts in any PSE).
But a full blown trust list management is not possible.
Nice blog!! Can we use this tool to integrate this with digicert for the certificate renewal.
Do we have any documentation or steps for that.
I don't know of any integration with Digicert. The SLS supports a feature called Remote CA (https://launchpad.support.sap.com/#/notes/2375797). There you can fetch certificates from a PKI via NDES (SCEP implementation in Microsoft AD CS) or CMC (Certificate Management via CMS). So if Digicert provides such an interface (with the restrictions mentioned in the note, for example having a synchronous interface), you can try such an integration.
However, I have not yet seen such an integration and I don't know if Digicert provides the respective interfaces.
Thank you! for the detailed blog on Certificate Lifecycle Management
We have configured failover server for the Secure Login server to address high availability and would like to get your input on whether we should setup certificate lifecycle management on both of the Secure Login Server nodes Or do you recommend keeping the enrollment process and certificate renewal to the primary node?
in this case, I would usually recommend setting up a reverse proxy (for example Web Dispatcher) in front of the Secure Login Server. This way you can always send the traffic to an active node and have High Availability in this scenario as well. The CLM tools do not work with multiple URLs, but rather always address one single host. Using a reverse proxy here can send the traffic to an active node independent of your setup (multiple Application server or even multiple systems).
On the other hand, CLM is usually not time critical (as opposed to user authentication). So if you run the CLM reports once a day anyways and your grace period is for example 20 days, for CLM you actually don't care about a downtime of a week. As long as the system is available once in those 20 days you are fine.
In the end, I would probably set up a reverse proxy (I like availability and I like the Web Dispatcher a lot and hence I like to set up Web Dispatchers basically for all HTTP communication). But I can also get on board with a setup where you say that downtimes don't occur for longer periods anyways and you keep CLM just on one server.
Yes, I agree!
Thank you for detailed explanation
Thanks for detailed steps on configuration.
In my case registration is successful, but renewal fails with below error;
SSL client SSL Client (Standard) SSLC DFAULT
No TLS client certificate provided
Trace on NWA shows;
Unsuccessful login: no login module succeeded. The size of the used authentication stack ClientCertCLM is 1
this looks as if your client certificate is not transfered to the Secure Login Server. Make sure that the server ports in the SLS actually request a client certificate (parameter VCLIENT in icm/server_port or globally via icm/HTTPS/verify_client). If you are using a reverse proxy like Web Dispatcher make sure that the client certificate is forwarded to the SLS (Forward SSL Certificates for X.509 Authentication | SAP Help Portal).
Regarding the Rule: Using Rules Based on Client Certificate Subject Names | SAP Help Portal
This is follows the general setup for client certificate based authentication and is not SLS specific. It is basically the same as for all Netweaver products.
HTTPS port is configured to 'request' , even I see client is presenting SLS PSE. But doesn' show up on SLS ICM log. Which always report 'No TLS client certificate provided'.
this can be due to quite a few things: Is there any infrastructure between client and server (i.e. Reverse Proxies)? Does the Root CA really match the Client Certificate? Does the client address the right port? Was the ICM restarted after the Parameters were set?
You can see what the server is requesting by issuing an "echo | openssl s_client -connect <host>:<port>" to the server. There you see which CAs are sent as trusted. In addition you can check the verify client parameters... And the Root CA needs to be in the ICM_SSL_<node> keystore view in NWA which needs to be synched down into an OS PSE.
All in all, troubleshooting this from afar is rather difficult. This would be something where a direct look at the system would be necessary. So I would recommend to look at the system together with someone who is familiar with client certificate based authentication at SAP Netweaver systems.
Thanks for help Tobias.
I can understand.
The certificate renewal is failing with message text "Provided TLS client certificate does not meet configured policy". On the NW Java AS security log we do see initial login commit abort message (below).
We did check the certificate list on the ABAP system under Trust manager and both the Root CA and SLS Sub CA certs are loaded under the key stores "SSL Client SSL (anonymous) and (Standard). These are the same certs requested by the SLS server. Also, the VCLIENT on SLS server is set to value 2.
Any Idea what is wrong here?
That means, that one of the rules configured in the CLM Certificate Logon Stack does not match the issued certificate.
Rule1.subjectName and Rule1.issuerName are both regular expressions that need to match the subject and issuer of the client certificate.
If implemented as described above, Rule1.issuerName is not the cause since the RegEx (.*) matches all strings.
However, the subjectName Rule mentioned matches "CN=[A-Z][A-Z0-9][A-Z0-9], ...", basically any CN that has three characters, all uppercase, starts with a letter and continues with two letters or numbers (so basically, an SID). Depending on the other configured attributes, the things behind (OU, O or C) might not match or in case of a sapslscli renewal, the CN of the client certificate might be longer than three characters.
To solve this you can either adjust the RegEx to match your actual subject or use (.*) in the issuerName rule as well to match all strings (basically deactivating the match).
That worked! I changed the regular expression to match the issuer and subject.
I do have another question on the report SSF_CERT_ENROLL. As per documentation, we only need to run the report once (Preparing a Certificate Renewal at Regular Intervals | SAP Help Portal). The PSE file generated by the enrollment report is later used by the certificate renewal process, however, the PSE validity is limited to 181 days as configured in the RA profile. This would mean that we need to re-run the enroll report periodically, right?
As the report SSF_CERT_ENROLL requires user-id and password in the variant we will then have to change the variant to update the password to comply with company's 90-day password change policy. Is there an alternative to periodically run the report without providing password? Also, can the report send a notification upon completion?
glad to hear that :).
Regarding the report: The report generates a new client identity in STRUST (I think it shows up as SSL Client Certificate SAPSLS). This is a standard client identity that you can renew using the SSF_CERT_RENEW report. So selfrenewal is possible. You just need a respective client ceritificate profile in the SLS.
Thank you! I am able to see the client identity in the ABAP trust manager.
I am unable to integrate remote PKI with SLS due to security setup in my organization, they do not allow user and password login. Is their a way i can copy the renewed certificate response from PKI to SLS manually and push it to a system?
you could try to create the Registration Agent PSE yourself and import the signed client certificate directly. Technically, this should work. However, I didn't ever test this.
For the OS Commands, this should be no problem. The AS ABAP report should be fine as well. But I don't know if the Java Application has any checks if the enrollment process was actually run successful. So, there might be some problem.
I never tested this, so this is more along the lines of guesswork ;).
I have evrything set up but when I run report ssf_cert_enroll I'm always getting the following error:
I'm using basic login module.
this looks like some problem with the authentication. First, I would check the User and Password (obviously, you probably already did that 😉 ).
After that, I would check the troubleshooting logs in the AS Java. For that, go to https://<host>:<port>/tshw. There you can use the authentication trace and check, if anything fails during the authentication process. If that does not help, follow https://launchpad.support.sap.com/#/notes/2341102 to create the Secure Login Server logs and check if there are any errors there.
These would be the points that I would check.
thanks for your reply. You are right, I checked the credentilas, created a new user, etc.
I also did the tshw analysis before but I can't see the reason for this error. Here's hat I get from tshw:
I tried to debug the report and it looks like the variable ms_auth-status doesnt't get a value and therefore the report runs into the error:
are all the components on the newest versions? (Currently, Secure Login Server SP 02 PL 11, newest note referenced in https://launchpad.support.sap.com/#/notes/2452425 installed in AS ABAP)
This somehow sounds like a problem in the communication that would have popped up at more customers. But I have this solution running at several customers, so the product in itself should be fine. Could you look at the components here?
Also, the authentication seems fine. You get a "LOGIN.OK" which is exactly what we want.
SLS is on a fresh and up to date installed AS JAVA and ABAP got patched last week 7.52 (latest SPS). I entered the status ACM_OK with the debugger and the report did it's job. It's really strange.
In that case, I would really recommend opening a customer message. I have not seen this behaviour yet and from the description it doesn't look like one of the usual configuration errors.
thanks for your expertise Tobias.
I am trying to use Remote CA feature. Although my connection test and everything is working fine for the destination, when I do the enrollment I am getting 500 Internal Server Error. and when I do a TSHW trace, I am getting below error:
I Even tried implementing note 2810511 for no help.
I am not sure if it is issue with SLS side or our PKI side.
from the trace it looks to me as if the SLS actually tries to call the NDES server. It seems to be a response from the NDES server. So I would recommend to try to find the error message there. You might be able to find something in the IIS traces or the Windows Event Viewer.
But that is just the best guess. I would also recommend double checking that your SLS version is rather current. Just to make sure that it is not some incompatibility (even though I am not aware of any problems in the past...).
The NDES interface itself is working at many different customers and since the configuration options are rather limited, I don't think that there is a protocol specific error in the SLS itself.