If you followed our Web Dispatcher installation guide, your certificate is live. This guide is about making sure you never have to do that manually again. Under the CA/Browser Forum’s SC-081 ruling, public certificate lifetimes are dropping to 200 days from March 2026, then 100 days from 2027, then 47 days from 2029 – a job you used to do once a year is heading towards six-plus times a year, per system. That’s not a workload a BASIS team should be doing by hand.
There are two realistic paths here: automate renewal through SAP’s own tooling (SLS), or automate it yourself with a script and a cron job. We’ll cover both – which one fits depends on what you’ve already got licensed.
Option 1: Automate with SAP Secure Login Server (SLS)
SLS is SAP’s Certificate Lifecycle Management (CLM) component, and it’s the supported way to automate renewal across ABAP, Java, HANA, and Web Dispatcher – it talks to your PKI/CA on your systems’ behalf and pushes renewed certificates into place before they expire. It’s a separate, licensed SAP product, so this path assumes you (or your SAP Basis team) already have it deployed, or are willing to set it up – it’s not something you get for free alongside NetWeaver.
On Linux/Unix hosts, the piece that actually does the renewal is a command-line client called sapslscli, which talks to SLS and rewrites the PSE in place when a certificate is due for renewal:
sapslscli renew -r /<secudir>/ra.pse -p /<secudir>/SAPSSLS.pse -g 365-p is the PSE being renewed (SAPSSLS.pse for Web Dispatcher’s server certificate), -r is the registration authority PSE SLS uses to authenticate the request, and -g sets how many days before expiry the renewal should trigger – treat the value above as an example, not a fixed setting, and tune it to a window that gives you time to notice and react if a renewal fails (30-60 days is a more typical trigger window than a full year).
Schedule this as a cron job so it runs unattended – daily is common, since the command itself is a no-op if nothing is close to expiry:
0 3 * * * <sidadm> /usr/sap/<SID>/hostctrl/exe/sapslscli renew -r /<secudir>/ra.pse -p /<secudir>/SAPSSLS.pse -g 60For ABAP systems in the same landscape, the equivalent automation runs as background jobs – SSF_CERT_ENROLL for first-time enrollment and SSF_CERT_RENEW for renewals – rather than a cron-scheduled CLI tool, so if you’re standardizing renewal across Web Dispatcher and your ABAP stack, expect two different scheduling mechanisms, not one.
Windows: sapslscli is primarily a Linux/Unix tool. On Windows Web Dispatcher hosts, check with SAP for the current supported SLS client for your release before assuming it’s unavailable – tooling here has changed release to release. If it isn’t available for your version, Windows Task Scheduler running a script against your CA’s own automation API (see Option 2) is the practical fallback.
Option 2: DIY automation without SLS
If SLS isn’t in your landscape and you don’t want to license it just for this, you can build the same outcome yourself, as long as your certificate authority supports programmatic issuance (an API, or ACME). The shape of it:
- A scheduled script (cron on Linux/Unix, Task Scheduler on Windows) checks the current certificate’s expiry date, either by reading it out of the PSE with
sapgenpse maintain_pk -l -p SAPSSLS.pseor with a plainopensslcheck against the live endpoint. - If it’s inside your renewal window, the script requests a new certificate from your CA’s automation-friendly interface.
- The script runs the same
sapgenpse import_own_certcommand from the installation guide to load the new certificate and chain into the PSE. - The script reloads Web Dispatcher –
kill -HUP <pid>on Linux/Unix, or a call to the admin interface (/sap/wdisp/admin) on Windows – so the new certificate takes effect without downtime.
This is more building work upfront than the SLS route, but it’s a one-time script rather than a recurring manual task, and it’s the more realistic option if your CA relationship or budget doesn’t currently include SLS.
Monitor it – don’t just trust it
Automated renewal still needs a human to notice if it silently stops working. A few things worth having in place regardless of which option you use:
- An expiry alert from SAP Solution Manager or Focused Run, separate from the renewal automation itself, so a failed renewal still gets caught before the certificate actually expires.
- Awareness that Web Dispatcher expiry monitoring has a history of false positives after a reload – SAP Notes 3749778 and 3348271 both cover cases where a metric shows red/expired immediately after a legitimate renewal, purely because the monitoring hasn’t re-read the new certificate yet. Don’t let a false alert train your team to ignore real ones.
- SAP Note 2325049 covers monitoring expiring certificates on Web Dispatcher and remote systems more broadly, and 2937709 is a good general troubleshooting reference if a renewal doesn’t behave as expected.
Where this leaves you
Set up correctly, either option means you stop thinking about Web Dispatcher’s certificate expiring – it renews itself, reloads itself, and only surfaces to you if something actually needs attention. Given where SC-081 is taking certificate lifetimes, that’s no longer a nice-to-have. If you haven’t sourced this round’s certificate yet, you can browse certificates here first. And if the automation itself isn’t behaving, our troubleshooting guide covers the errors we see most often.