If you followed our ECC/S4HANA (ABAP/STRUST) installation guide, your certificate is live. This guide covers the SAP-native way to stop doing that manually: automated enrollment and renewal through SAP Secure Login Server (SLS), using two standard ABAP reports, SSF_CERT_ENROLL and SSF_CERT_RENEW.
Unlike Web Dispatcher’s sapslscli command-line client, ABAP’s side of this automation runs as background jobs inside the system itself – which fits naturally with how BASIS teams already schedule recurring work, but does mean a bit of upfront configuration in SLS before the jobs will do anything.
What you need before you start
- SAP Secure Login Server (SLS) deployed and reachable from this ABAP system – it’s a separate, licensed SAP product, not something bundled with NetWeaver.
- An Application Server Profile Group configured in SLS (via SLAC) for this system, including the SIDs it should manage certificates for.
- A technical user with password authentication, authorized for enrollment against SLS.
- The corrections in SAP Note 2452425 applied, if you haven’t already – it’s referenced consistently alongside this setup.
Step 1: Enroll the system with SLS
Run report SSF_CERT_ENROLL (via SE38/SA38). You’ll be asked for the metadata URL from the Application Server Profile Group in SLS, and the technical user’s credentials. This establishes the connection between the ABAP system and SLS – run once per system, not on a schedule. On success, it shows an overview of the certificate objects (PSEs and their certificate profiles) that are now available for renewal.
Step 2: Set up the renewal job
Run report SSF_CERT_RENEW and select the certificates you want it to manage – for a typical ECC/S4HANA system that’s at least the SSL server Standard PSE from the installation guide. Assign the appropriate certificate profile to each one you select, then save the selection as a variant rather than running it ad hoc.
Schedule that variant as a background job via SM36. One detail worth knowing before you set this up: SAP’s own guidance is that you need a separate batch job per application server and per certificate type – it isn’t one job that quietly covers your whole system, so plan the job list accordingly if you have more than one application server or more than one certificate type in play.
Step 3: Let it run, then check it actually worked
Once scheduled, SSF_CERT_RENEW updates the selected certificates through SLS automatically when they’re due, and gives confirmation messages for what it processed. It’s worth checking the job log after the first few runs rather than assuming silence means success, especially while the Application Server Profile Group and certificate profiles are newly configured – a misconfigured profile tends to fail quietly rather than loudly.
Compare this to Web Dispatcher’s automation
If you’re also running our Web Dispatcher renewal automation on the same SLS instance, expect two different mechanisms rather than one shared job: Web Dispatcher’s sapslscli runs from cron on the OS, while ABAP’s runs as background jobs inside the system via SM36. Both talk to the same SLS, but they’re scheduled and monitored separately.
Where this leaves you
Configured correctly, this is genuinely the last certificate you import into STRUST by hand for this system – SLS handles enrollment and renewal from here, on whatever schedule you’ve set. Given how much more often SC-081 will make this necessary, that’s worth the upfront SLS configuration if you’re running more than a system or two. If the automation isn’t behaving as expected, our troubleshooting guide covers the errors we see most often.