One API to issue and rotate self-signed certificates for ABAP, Web Dispatcher, Host Agent and Cloud Connector, and to track every public certificate you already own — pulled and applied by your own scheduler, nothing installed inside your SAP systems.
Built for Basis teams who are about to lose SAP SSO's automatic PSE distribution.
SAP SSO is what quietly automates certificate distribution across ABAP STRUST, Java keystores, Web Dispatchers, Host Agents and Cloud Connector principal propagation today. SAP has not announced a successor for that specific automation — only the deadline is fixed.
Works for one system. Doesn't scale past a handful of SIDs, and every missed renewal is an outage a customer notices before Basis does.
A full internal CA / HSM platform solves it, but it's a project of its own — procurement, integration, and ongoing operation, for a problem that's really just "keep SAP's own certificates fresh."
One tenant, one API key, a private CA that's already yours — issuance and renewal handled centrally, distribution pulled by a scheduler your Basis team already controls.
SAP SSO solved this quietly for over a decade. After 2027, something has to replace it — ssl4sap.com is built to be that something, for exactly this problem and nothing more.
A pull-based flow: ssl4sap.com decides when a certificate needs renewing, your own scheduler decides when to fetch and apply it.
Add a SID, hostname and component (ABAP SSL server, Web Dispatcher, Host Agent, Cloud Connector) through the panel or the API. A private root CA is generated for your account the first time.
A leaf certificate is signed by your CA immediately, then auto-renewed on a schedule you set per system — well before expiry, with no action required from you.
An ABAP report, cron job, or your existing scheduler polls the API, downloads the new certificate as PEM or PKCS#12, and applies it with sapgenpse or the target's own API.
The agent acknowledges the applied serial back to ssl4sap.com, so the dashboard shows "distributed", not just "issued" — and flags anything that's overdue.
Internal traffic and public-facing endpoints have different trust requirements — ssl4sap.com manages both from the same account.
Both options run the exact same API and issuance engine — the difference is where your account's data lives.
Your account runs on our shared multi-tenant platform. Every customer's certificates, keys and API traffic are logically separated by tenant boundary and encryption — nothing about your account is ever visible to another customer, and nothing about theirs is visible to you.
A dedicated tenant provisioned exclusively for your organization. No other customer's certificates, keys, or API traffic ever share infrastructure with yours — this is physical separation, not just logical.
Start on Public Cloud and move to a Private Cloud Tenant later — the API your scheduler talks to doesn't change.
Every component SAP SSO used to cover today, plus the exact mechanism ssl4sap.com uses for each.
Applied via sapgenpse import_p12 against the STRUST PSE file, triggered from a background job or SM69 external command.
Same sapgenpse mechanism, scheduled directly on the host — no ABAP stack required.
sapadm's own PSE, rotated on the same schedule as the instances it monitors.
Pushed straight through Cloud Connector's own REST Admin API — no sapgenpse involved, and it's what principal propagation trust depends on.
Issued and tracked like everything else today; NWA's Key Storage service has no scriptable API yet, so v1 leaves the final import as a manual step.
Uploaded certificates from any public CA, tracked for expiry and distributed through the same pull API as everything else.
Check what's active, download it, confirm it was applied — the same three-call shape regardless of which component is on the other end.
Full worked example, including the sapgenpse hand-off via SXPG_COMMAND_EXECUTE, ships in examples/abap-agent-example.txt.
cl_http_client=>create_by_url(
EXPORTING url = |{ base_url }/systems/{ system_id }/certificate|
IMPORTING client = lo_client ).
lo_client->request->set_header_field( name = 'X-API-Key' value = api_key ).
lo_client->send( timeout = 30 ).
lo_client->receive( ).
" compare serial to the one applied last time, then GET .../download?format=p12
" and hand the file to sapgenpse via a registered SM69 external command.For Web Dispatcher and Host Agent hosts that don't run ABAP at all — see examples/apply-cert.sh.
curl -sS -H "X-API-Key: $API_KEY" \
"https://api.ssl4sap.com/api/v1/systems/$SYSTEM_ID/certificate/download?format=p12" \
-o bundle.p12
sapgenpse import_p12 -p "$PSE_PATH" bundle.p12
sapcontrol -nr "$INSTANCE_NR" -function RestartService ICMCloud Connector has its own REST Admin API — no sapgenpse needed, see examples/cloud-connector-upload.sh.
curl -sS -H "X-API-Key: $API_KEY" \
"https://api.ssl4sap.com/api/v1/systems/$SYSTEM_ID/certificate/download?format=pem" \
-o cert.pem
curl -sS -k -u "$CC_ADMIN_USER:$CC_ADMIN_PASSWORD" \
-X PUT "$CC_ADMIN_URL/api/config/v1/instance/systemCertificate" \
--data-binary @cert.pemEvery call is authenticated with a per-customer API key; the admin API used to manage customers and quotas is a separate, separately-gated key.
Certificate custody is the whole product, so it gets the most conservative defaults: private keys are generated per system, encrypted at rest, and never appear in logs or error messages. Nothing is installed inside your ABAP stack — every apply step runs through sapgenpse or a component's own API, driven by a scheduler you already control.
"We generate the certificates. We don't get to decide what your systems trust — that bootstrap step is yours, once, and after that we just keep it current."
— ssl4sap.com design principle
Renewals and distribution checks shouldn't be something you think twice about before running them.
One landscape, one SID family
Multiple landscapes, several SIDs
Managed service providers & large landscapes
Talk to us before SAP SSO's maintenance window closes — migrating a live landscape is easier to plan for than to rush.
Tell us about your landscape and we'll set up a tenant with your first systems registered.
Request accesshello@ssl4sap.com
Aleksander Godziło-Godlewski
Storczykowa 3/2a
55-040 Bielany Wrocławskie
Wrocław, Poland