If you followed our Integration Suite (CPI) installation guide, you’ve got certificates in place. This one covers automating renewal of the tenant keystore certificates using SAP’s own Security Content OData API – the closest thing CPI has to sapslscli or the SLS-driven jobs we’ve covered for the on-premise systems.
What this API actually does
The Security Content OData API exposes your tenant’s keystore over HTTP, with two operations that matter for renewal:
- Reading expiry dates – a GET against the
KeystoreEntriescollection returns every certificate in the store along with itsValidNotAfterdate, which is what you’d use to build an expiry check. - Replacing a certificate – a
PUTto/CertificateResources('{HexAlias}')/$value(with the certificate’s alias converted to hexadecimal in the URL, and?fingerprintVerified=true&returnKeystoreEntries=false&update=trueas query parameters) uploads a new certificate in place of an existing alias.
Both are Basic-auth-protected using service credentials deployed alongside your integration flows, the same way any other CPI adapter authenticates.
Two different renewal situations
Worth being precise about what you’re renewing, since the source pattern for the new certificate differs:
- A CA-issued certificate that’s genuinely yours (your own client cert, or a server cert for a system you control) – you still need a signing authority to issue the renewal, same as any other guide on this site. The automation here is in the upload step: once you have the renewed certificate, the
PUTcall above replaces it in the keystore without a manual Add-in-the-cockpit step. - A trust-store entry for an external system’s certificate (you’re trusting someone else’s server, not renewing your own) – since you don’t control that certificate’s lifecycle, the practical pattern is to fetch its current certificate directly from the live TLS handshake (a small script or Groovy step connecting to the target host) and push whatever’s currently being served into your keystore via the same
PUT. This keeps your trust store in sync with a certificate someone else renews, rather than renewing anything yourself.
Building the automation
The common pattern is a small integration flow, triggered on a schedule (a Timer start event, run daily or weekly), that:
- Calls the OData API to list keystore entries and their expiry dates.
- Filters for anything inside your renewal window.
- For each one, obtains the new certificate (from your CA for your own certs, or from the live endpoint for trust-store entries) and calls the
PUTto replace it.
Turning on HTTP session reuse on the OData receiver is worth doing if you’re checking more than a handful of entries – it avoids re-authenticating on every single call.
Custom domain certificates aren’t covered by this API
The Security Content OData API works against your tenant’s keystore, not Custom Domain Manager. A custom domain’s certificate still goes through the same upload/bind flow as the installation guide when it needs renewing – there’s no equivalent auto-renew hook for that piece as of writing, so put a calendar reminder on it rather than assuming it’s covered by the automation above.
Where this leaves you
Keystore certificates that CPI trusts or authenticates with can be kept current automatically once this is built; your custom domain’s own certificate still needs a manual (if quick) renewal each cycle. Given where SC-081 is taking certificate lifetimes, automating the keystore side is worth doing even if the custom domain piece stays manual for now. If the automation isn’t behaving as expected, our troubleshooting guide covers the errors we see most often.