To enable certificate automation in an AS Java system, you must first deploy the Secure Login Library 3.0. (official help.sap.com link). The operating‑system‑independent package is delivered as an SCA file, which can be installed on AS Java through the telnet deployment tool.
Once deployed, the system automatically provides access to the CLM application, available at: https:/<host>:<port>/sapsso/clm
In the NWA, go to Configuration → Certificates and Keys. Under Key Storage, open Security → Permissions by Domain, search for the CLM application, and grant it full access to the keystore views that should be renewed automatically.
Open the CLM application in the browser. Start by registering the system (initial enrollment).
Enter the metadata URL and click Fetch.
When prompted, log in with a user allowed to perform CLM enrollment.
Click Register, then Save
To renew certificates, go to the Enrollment tile.
The metadata URL is already stored, so select the keystore view and the certificate you want to renew.
After choosing Enroll Certificates, the updated certificates appear.
You can review them using Show Details.
Finally, you may create a scheduled task so renewals run automatically.
The task executes under the currently logged‑in user.
Conclusion
After this configuration, the certificates in AS Java should be renewed regularly before reaching the end of their lifetime.
To organize certificate profiles and control which SAP systems participate in the automation process, you need to create an Application Server Profile Group in the Secure Login Administration Console (SLAC).
This blog is a continuation of the generic setup explained in the blog on this page.
In SLAC, navigate to: Application Server Profile Groups → Create New Group
Give the group a name that clearly identifies its purpose.
2. Assign System Identifiers
Under System Identifiers, add the SIDs of all SAP systems that will participate in certificate renewal. Important notes: SIDs can contain uppercase letters and digits.
3. Configuration on AS ABAP
Configuring ABAP for CLM automation involves running two key reports. Most recent NetWeaver releases already include them, but to ensure you are using the latest versions, SAP recommends implementing the corrections from SAP Note 2452425 – Collective Note – SAP SSO Certificate Lifecycle Management for ABAP.
Run the SSF_CERT_ENROLL Report
This report performs the initial connection between the ABAP system and Secure Login Server (SLS).
Metadata URL of the Application Server Profile Group in SLS
Technical user with password authentication that is authorized to perform the enrollment
Running this report enrolls the system for the first time and retrieves the required certificate information.
Once the enrollment report has been executed successfully, the system displays an overview of all certificate objects that are available for renewal. This screen also shows the certificate profiles assigned to the different PSEs.
You will see a list of certificate entries along with the available certificate profiles. For each entry:
Choose the appropriate certificate profile
Select the certificates you want to renew
This allows you to control exactly which PSEs should be processed.
2. Execute the Renewal
After starting the renewal process, the system will update the selected certificates through the Secure Login Server. When the renewal completes successfully, you should receive a confirmation message for each certificate that was processed.
3. Schedule Automated Renewal
To avoid manual renewals in the future, you should save the selection in a variant and set up a scheduled job of program SSF_CERT_RENEW. You need a batch job per application server and per certificate type.
Conclusion
After this configuration, the certificates in AS ABAP should be renewed regularly before reaching the end of their lifetime.
Digital certificates play a critical role in securing SAP systems—whether for HTTPs communication, SSO, Cloud Connector integration, or internal system‑to‑system traffic. As organizations scale, manual certificate renewal becomes error‑prone and difficult to manage.
This guide explains how to automate the entire lifecycle of SAP certificate monitoring, renewal, deployment, and validation using standard tools available on any SAP system. The approach is applicable to SAP ABAP, Java, HANA, Web Dispatcher, Content Server and Host Agent environments.
This blog will explain the overview and generic setup. The follow up blogs will describe:
Certificate renewal for ABAP
Certificate renewal for JAVA
Certificate renewal for Linux
1. Overview
SAP Secure Login Server (SLS) is part of the SAP Single Sign-On product. This is a licensed product, for more information read OSS note 1876552 – License Requirement and Download of Single Sign-On 3.0 from the SAP Software Center. Within SSO, SLS serves as the central component for Certificate Lifecycle Management (CLM), enabling automated renewal of certificates used by:
AS ABAP systems
AS Java systems
SAP Web Dispatcher
SAP Host Agent
Other SAP components requiring HTTPS or SSL
For automation, SAP SLS communicates with a PKI infrastructure. A widely used option is Microsoft NDES, which supports enrollment using the SCEP (Simple Certificate Enrollment Protocol).
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.
This blog assumes that you are familiar with the general Certificate Lifecycle Management process. Before setting up Certificate Lifecycle Management (CLM) with Secure Login Server (SLS), make sure the following requirements are met:
1.1 Secure Login Server Installed You need a working installation of SAP Secure Login Server. SLS can run on any supported, modern SAP NetWeaver AS Java system. Read OSS note 3529951 – SAP Single Sign On 3.0 product compatibility for exact specifications.
1.2 Administrative Access You need a user who can access the Secure Login Administration Console (SLAC) to configure CLM settings.
1.3. Supported SAP Releases Your SAP systems must support the CLM client components:
A user with SLAC_CERT_ADMIN/SLCLM_ADMIN/SLAC_SUPERADMIN or equivalent permissions in the Secure Login Administration Console.
2. Configuration of Destination (Connecting SLS to the PKI / NDES Server
(This step must be completed before creating certificate profiles) Before defining any certificate profiles in Secure Login Server (SLS), you must configure a destination that allows SLS to communicate with your PKI infrastructure (typically Microsoft NDES). SLS uses this destination to forward CSR requests and to retrieve issued certificates, acting as a broker between SAP systems and the PKI server. This is a mandatory step because without a properly configured destination, SLS cannot reach the PKI, and no certificate enrollment or renewal will work.
Open the Destinations Area in NWA In the SLS (AS Java) system:
Go to NetWeaver Administrator (NWA) Navigate to: Configuration → Infrastructure → Destinations
This area allows you to create HTTP/S destinations that SAP components use to reach external systems.
Create a New Destination Create a new destination dedicated to your PKI/NDES server. Recommended Naming Convention Use a name that reflects your PKI or environment (e.g.,): NDES_PROD NDES_QA PKI_SCEP
This improves clarity when assigning the destination later in SLS certificate profiles.
Configure Destination Type Set the destination type to: HTTP Destination, Since NDES SCEP endpoints are exposed over HTTPs, this ensures compatibility.
Enter the SCEP URL of the NDES Server In the Connection Information section, enter the full SCEP endpoint URL of your PKI/NDES server. For example (generic format): https://<ndes-hostname>/certsrv/mscep/
This URL points to the NDES SCEP service used for certificate enrollment.
(Optional) Configure Logon Data Depending on your PKI security configuration, you may need to configure:
Basic Authentication with a technical service account Certificates for mutual TLS. No authentication if internal trust is used. This must align with your PKI design.
Test the Destination After configuring:
Click “Ping Destination” Ensure the HTTP/HTTPs connection is successful If the response is reachable, SLS can now communicate with NDES
Remark: even though HTTPs is configured, the success message still shows HTTP.
SLS relies on this destination for all CLM certificate operations.
Why this destination is critical This destination is used internally by SLS for:
Forwarding Certificate Signing Requests (CSR) to NDES Receiving signed certificates Validating enrollment responses Triggering certificate renewals Communicating over the SCEP protocol
Without this destination, all profiles (TLS, SNC, Client) and enrollment workflows will fail because SLS would have no path to the PKI infrastructure.
How It Fits Into the Overall CLM Workflow Once the destination is created: SAP System → SLS → (Destination) → NDES/PKI → CA → SLS → SAP System
3.1 Configuring Secure Login Server for CLM
Before you configure anything in the Secure Login Administration Console (SLAC), you must prepare SLS to accept certificate‑based authentication from SAP systems. This requires creating a dedicated logon stack.
The formal SAP help document link can be found here. The steps below describe the summary main steps with clarifying screen shots.
1. Create a Logon Stack in SLS
1.1 Create a Logon Stack in NWA
Begin by opening the NetWeaver Administrator (NWA) of the Secure Login Server and navigating to:
Configuration → Authentication and Single Sign‑On → Logon Stacks
Here you create a new logon stack. Choose a name that clearly indicates it is intended for CLM system authentication, such as Client_Cert_CLM
1.2 Steps to Create the Logon Stack
Open the NetWeaver Administrator (NWA) for SLS.
Navigate to: Configuration → Authentication and Single Sign‑On → Logon Stacks
Create a new logon stack with a name that clearly indicates it is intended for CLM client authentication (for example, CLM_ClientAuth).
Add a single login module to this stack: SecureLoginModuleUserDelegationWithSSL
**Configure the Three Key Attributes** This module requires three important attributes that control how certificates are validated: 🔹 Rule1.subjectName
Used to filter acceptable certificate subjects using a regular expression. If you set it to the wildcard pattern: (.*)
it effectively accepts any subject. Even with the wildcard, the Common Name (CN) of the system certificate must still match one of the system entries you later configure in the Secure Login Administration Console (SLAC).
🔹 Rule1.issuerName
Controls which certificate issuers are allowed. Typically also set to: (.*)
This disables strict issuer filtering and allows any issuer that SLS already trusts through its root CA store.
🔹 UserMappingMode
Must be set to: VirtualUser
SAP systems do not exist as users in the UME. Therefore, SLS maps each system certificate to a virtual identity, and these identities are filtered and managed later in SLAC.
1.3. Purpose of the Logon Stack
This logon stack is used by every application profile in CLM. It ensures that SAP systems can authenticate securely when requesting new or renewed certificates. This logon stack forms the authentication foundation for all certificate lifecycle operations in SLS. Every CLM application profile will reference it. By configuring:
The SecureLoginModuleUserDelegationWithSSL module, The subjectName and issuerName rules, and Virtual user mapping
You ensure that: ✔ SAP systems authenticate themselves correctly via SSL client certificates ✔ Certificate enrollment and renewal requests are validated through the defined rules ✔ System‑to‑certificate mapping is handled through virtual identities (since systems do not exist in UME) ✔ CLM workflows function seamlessly from initial enrollment through automatic renewal ✔ Every SAP component—ABAP, Java, Web Dispatcher, Host Agent, HANA—can make use of this same logon stack This logon stack is therefore reused across all application profiles in CLM, ensuring consistency and secure handling of certificate requests throughout the entire SAP landscape.
1.4 Configuration of Certificate Profiles
After preparing the logon stack, the next step in setting up Certificate Lifecycle Management (CLM) is to define the certificate profiles inside the Secure Login Server (SLS). These profiles describe what type of certificates SAP systems should request and how SLS should communicate with the backend CA/NDES to obtain them. Each certificate profile represents a specific certificate purpose (such as SNC or TLS) and includes the rules that control certificate enrollment, renewal, and template mapping.
Registration Agent Profile (Used for Enrollment Requests) The first profile that must be created is the Registration Agent (RA) profile. This profile is responsible for handling initial certificate enrollment requests coming from SAP systems. It acts as the “front door” for: Receiving enrollment metadata from SAP components, forwarding Certificate Signing Requests (CSR) to NDES and Returning the signed certificate back to the SAP system. Every system type—ABAP, Java, HANA, Web Dispatcher, Host Agent—uses this RA profile during enrollment.
fill the required entry as per organization details. and CA for issuing certificates create PKI structure under certificate management
Create Certificate Profiles for Each Required Certificate Type
✔ Initial_TLS_Cert_SAN
Used for First‑Time SAN‑Based Enrollment & Renewal and This profile is required for the very first certificate issuance when: You are enrolling a system for the first time and want the initial certificate to follow SAN requirements (as enforced by modern PKI policies)
✔ SNC Certificate Profile
Used for systems that use Secure Network Communication (SNC) with X.509 certificates.
✔ TLS Server Certificate Profile
Disclaimer: This page covers only the architecture and configuration required for SAP certificate automation. For the full enrollment and renewal procedure, please refer to 👉 “SAP Certificate Enrollment & Renewal Automation Process” page dedicated to the operational workflow.
Health Monitoring provides a functionality called Availability Monitoring wherein we can monitor:
HTTP Availability: Monitoring availability of URLs.
TCP Availability: Monitoring the availability of a TCP port or the availability of a host.
RFC Availability: Monitoring availability of RFCs specifically for measuring availability of an application server instance of an SAP system or the availability of a message server port of an SAP system.
In this blog we will explain how you can configure a HTTP Availability monitor to monitor availability of a URL.
Setup of URL availability monitoring
Step1: Assign Agent for data collection
The HTTP availability is measured by making a URL http or https call by a designated Simple Diagnostic Agent from your specific customer network in the Focused Run system.
The first step is to assign a Simple Diagnostic agent as the collector for this metric.
For this open the Health Monitoring App from the Focused Run launchpad.
Navigate to Configuration area by clicking on the Configuration button.
Expand the Customer Networks node and click on the change button.
In the next popup select the agent from the list of all connected agents to this customer network.
Step2: Configure HTTP Availability Metric
In the Configuration area expand the metric node and click on the change button for Availability under Metrics node.
In the next pop-up screen click on the Plus button to add a metric.
In the next pop-up screen select HTTP Availability
Enter the following details for a basic URL Availability check.
Field
Description
Metric Name
A descriptive name for the metric
Customer Network
Select the customer network for which you want to create the metric
Collection Frequency
Specify the collection frequency, how frequently the check should be performed.
URL
Enter the URL to be monitored
Proxy
Enter the proxy detail if the URL is reached via a proxy from the customer network. Else select None.
Authentication
Enter the authentication type None or Basic or oAuth and enter the details based on authentication type.
Timeout
Period in milliseconds (ms) before a call fails.
Number of Retries
Number of times the data collector calls a URL until it receives a response.
You can also further customize based on type of call you want to do to the URL for instance sending a POST request. For details you can refer to the SAP documentation here.
Optionally you can also enable alerting and notification in the Alert section of the configuration.
After entering all the details save your configuration to activate the metric.
URL availability monitoring usage
To navigate to the URL availability monitors you can click on the Availability button in the navigation panel.
Or you can also navigate from home screen.
Upon navigating to the Availability monitor metric list you will see the status of all URL availability metrics configured. The metric list view shows us the number of days and hours since the URL is available or unavailable. It also shows us the response time when accessing the URL.
This way you can not only monitor the URL availability but also the performance of an URL with regards to the response time while accessing the URL.
OS process monitoring
With OS Process Monitoring functionality we can monitor the availability of critical OS level processes on any host.
With System Monitoring templates you can also activate custom metric for monitoring OS processes however this will be applicable for all system/hosts for which you activate the template.
For monitoring critical OS processes for specific hosts you need to setup using Health Monitoring functionality.
To access Health Monitoring functionality you can navigate to Health Monitoring app in the Focused Run launch pad.
Prerequisite for OS process monitoring
The only prerequisite for configuring OS process monitor in Health Monitoring is that you should have registered the host and deployed Simple Diagnostic Agent (SDA) on the host where you want to monitor the critical process.
Setup of OS process monitoring
For setting up the OS process monitor you need to navigate to the settings page of the Health Monitoring App.
In the settings area expand the metrics node and click on the pencil button (Edit Metric) for OS Processes.
In the OS Process edit metric screen click on Add Metric button to start creating the OS Process Metric.
In the OS Process edit metric screen click on Add Metric button to start creating the OS Process Metric.
Field
Description
Process Name
Name of the OS process. This parameter needs to be maintained as a regular expression. SDA will use this expression for searching for the respective OS process at OS level.
User (Optional)
You can further restrict the search for processes running through a specific user. You need to enter the name as a regular expression
Command Line (Optional)
You can further restrict by the specific command line with which the process is running . This is specifically useful if there are multiple processes running with the same name but you want to monitor the process which is running with a specific argument or parameter. This also needs to be maintained as regular expression.
Hostname
Name of the host where the process to be monitored. You can select from a list of all hosts connected (also SDA deployed) to the Focused Run system.
In the General Settings tab you can also specify the data collection frequency and the threshold. By default 5 minutes frequency and Already Rated threshold is set.
Optionally you can update the alert settings for this metric in the Alert Settings tab. By default alerting is active with medium severity.
After entering all details, to activate the metric click on Save button.
You can monitor all you OS process metrics in the OS Processes tab of the Health Monitoring App.
SSL certificate monitoring
You can configure monitors to monitor the SSL certificate of a URL using Health Monitoring functionality in SAP Focused Run system. This monitor measures the remaining validity (in days) of a SSL certificate for a https call to a URL. The URL is called by Simple Diagnostics Agent of a designated host in your customer network.
The Health Monitoring app also provides a separate section called as URL Certificate Monitor where in you can centrally monitor expiry of SSL certificates of any https URL.
To navigate to URL Certificates monitor you can click on the URL Certificate button as shown below in the navigation panel of the app.
Setup of SSL certificate monitoring
To configure URL Certificate monitors , navigate to the Configuration area, expand the Metrics node and click on the change button.
In the popup window click on the Add Metric.
In the Metric Configuration window enter the following details in the General tab.
Field
Description
Metric Name
A meaningful name to the monitor
URL
URL whose certificate to be monitored.
Proxy URL (Optional)
The Proxy URL if the URL is accessible via a proxy URL
Customer Network
The Customer Network to which this URL belongs. The designated SDA from this customer network will be performing the check.
Technical System (Optional)
You can optionally link this monitor to a specific cloud service you have registered in your LMDB. This is the Cloud Service you would have created if you are using AIM scenario for Cloud Service Monitoring. Select from the drop down.
Collection Interval
Frequency of data collection. Select from available options.
Threshold
Threshold for remaining days for expiry. By default 200 Days for Yellow and 100 days for Red.
Additionally and optionally in the Alert Settings tab you can activate alerting and notification settings as shown below.
That’s it, now your monitor is active.
Using SSL certificate monitoring
To monitor navigate to the URL Certificate tab in the Health Monitoring App.
You can also refer to this SAP documentation to know more about various features available with Focused Run Health Monitoring.
<< This blog was originally posted on SAP Focused Run Guru by Manas Tripathy and Frank Umans. Repost done with permission. >>
