Configuring Certificate Lifecycle Management

[Tobias_Lejczyk]

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/2a6cec67c50842a...). 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/48f05021dcdb4f6b992579d2ad228....

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.

[sachin_sachdeva2]

Hi Tobias,

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?

 

Regards

Sachin

[Colt]

Hello Sachin!

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.

Cheers Carsten

[msilva14]

Hello.

 

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.

best regard

[Tobias_Lejczyk]

Hi Marcio,

 

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:

1. This only happens when a certificate is renewed (so if you want to roll out a new CA, all certificates would have to be renewed)


2. [Somewhat of a corollary of 1.] This only works for Stores where a certificate is renewed. So, for example the Anonymous Client PSE, which is not signed, will never get the certificates.


3. The certificate list is replaced (at least that is what happens in the AS ABAP; in AS Java, the behaviour differs).

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.

 

Best regards,
Tobias

[sherryharminder]

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.

 

Thanks!!

[Tobias_Lejczyk]

Hi Singh,

 

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.

 

Best regards,
Tobias

[asif_rahmetulla]

Hello Tobias,

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?

Regards,

Asif

[Tobias_Lejczyk]

Hi Asif,

 

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.

 

Best regards,
Tobias

[asif_rahmetulla]

Hello Tobias,

Yes, I agree!

Thank you for detailed explanation

Regards,

Asif

[anu_s4]

Hello Tobias,

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
{"sessionSalt":{"field":"j_salt","value":"gqZ+ExE72gUwkyJ519bhhw=="},"clientConfig":{"newPinType":"pin","browserMonitor":false,"grac
ePeriod":0,"showSuccessMsg":false,"inactivityTimeout":0,"autoReenrollTries":0,"keySize":2048,"AutoLogout":false,"reAuthentication":0
},"clientMessage":{"messageStatus":"none","messageText":"","messageType":3},"userInput":[]}#

AND

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

1. Is there any configuration reqd on client ? (I have set ssl/client_pse to use signed SSL client pse)


2. Is there a document link to understand Rule1.subjectName.

Thanks;

-Anu

[Tobias_Lejczyk]

Hi Anu,

 

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.

 

Best regards,

Tobias

[anu_s4]

Thanks Tobias,

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'.

 

-Anu

[Tobias_Lejczyk]

Hi Anu,

 

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.

 

Best regards,

Tobias

[asif_rahmetulla]

Hello Tobias,

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?

Regards,

Asif

[Tobias_Lejczyk]

Hi Asif,

 

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).

 

Best regards,

Tobias

[anu_s4]

Thanks for help Tobias.

I can understand.

 

-Anu

[asif_rahmetulla]

Hello Tobias,

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?

Regards,

Asif

[Tobias_Lejczyk]

Hi Asif,

 

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.

 

Best regards,
Tobias

[asif_rahmetulla]

Hello Tobias,

Thank you! I am able to see the client identity in the ABAP trust manager.

Regards,

Asif

 

[ambrish_srivastava]

Hello,

 

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?

 

Regards,

Ambrish

[Tobias_Lejczyk]

Hi Ambrish,

 

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 ;).

 

Best regards,
Tobias

[mwahrhusen88]

Hey Guys,

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.

[Tobias_Lejczyk]

Hi Matthias,

 

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.

[mwahrhusen88]

Hi Tobias,

 

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:

[mwahrhusen88]

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:

IF ms_auth-status <> 'ACM_OK'.

      mf_errortext = cl_secxml_helper=>utf8_2_string( mf_response ).

      CONCATENATE 'Invalid user name/password:'(012) mf_errortext INTO mf_errortext SEPARATED BY ' '.

[Tobias_Lejczyk]

Hi Matthias,

 

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.

[mwahrhusen88]

Hi Tobias,

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.

[Tobias_Lejczyk]

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.

[mwahrhusen88]

thanks for your expertise Tobias.

[dashsailendraprasad]

Hello Everyone,

 

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.

 

Thanks,

Sailendra

 

[Tobias_Lejczyk]

Hi Sailendra,

 

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.

 

Best regards,
Tobias