Every guide on this site walks through a single certificate task going right. This one is for when it doesn’t. It’s organised by system, in the same order as the install/renewal guides – find your system, then scan for the error message or symptom closest to what you’re seeing.
A couple of things worth saying up front. First, these are the errors that come up often enough to be worth documenting, not an exhaustive list – if you’re stuck on something not covered here, the SAP Note/KBA numbers we cite are a good next stop, and you’re welcome to ask us directly. Second, we’ve stuck to problems we could verify against an SAP Note, SAP Community thread, or SAP Help Portal page – anywhere we’re relying on general pattern-matching rather than a confirmed source, we’ve said so.
SAP Web Dispatcher
PSE won’t open, or “no credentials available” at startup. A PIN error opening SAPSSLS.pse (SAP Note 1681008) almost always means the PIN you’re using doesn’t match what the PSE was created with – there’s no way to recover a lost PIN, only to generate a new PSE and re-issue. “No credentials available for <PSE>” (SAP Note 1525059) is a different problem: it means seclogin was never run, or was run as the wrong OS user, so Web Dispatcher can’t unlock the PSE without a human typing the PIN in. See Step 4 of our installation guide if you haven’t set that up yet.
“Installation of certificate failed” or “Installation of CA certificate failed” on import. This is almost always a chain-order problem – SAP Note 3057143 covers importing the CA response chain correctly. The signed certificate has to go in with a chain file that has the intermediate first, then the root; importing the leaf certificate on its own, or with the chain in the wrong order, is the most common cause.
Handshake or trust errors after a certificate looks correctly imported. SSSLERR_PEER_CERT_UNTRUSTED (SAP Note 2461900) means the connecting client doesn’t trust the chain you presented – check the intermediate actually made it into the PSE, not just the leaf certificate. SSSLERR_UNSUPP_PROTOCOL_VERSION (SAP Note 3306012) is unrelated to the certificate itself – it’s a client offering an older TLS version than the server now accepts, usually after a ciphersuite hardening change. SAP Note 3715227 is a good general starting point for TLS/SSL certificate errors across SAP systems if neither of those matches what you’re seeing.
Monitoring says the certificate is expired right after you renewed it. This is a known false-positive pattern, not a real problem with your certificate – see the “Monitor it” section of our renewal guide for the specific SAP Notes that cover it.
SAP ECC and S/4HANA (ABAP/STRUST)
“Certificate response does not match PSE” when importing a renewal. Covered in SAP Note 3209634. This means the certificate you’re importing wasn’t issued against the CSR that PSE currently holds – usually because a new CSR was generated since the one submitted to the CA, overwriting the request the signed certificate corresponds to. Regenerate the CSR from the current PSE state and get it re-signed rather than trying to force the mismatched certificate in.
Import silently fails, or “Cannot analyze certificate”. SAP Notes 3521745 and 3446038 both point at format/encoding problems – the file isn’t in the format STRUST expects (Base64 vs binary DER, for example), or it’s been altered in transit (line-ending changes from copying through email or a text editor are a common culprit). SAP Note 3238733 is a good general reference for importing a certificate into a STRUST PSE’s certificate list if you want to check your process end to end.
ICM won’t start HTTPS at all. “Loading of SSL library failed — NO SSL available!” (SAP Note 2534352) means the crypto library itself isn’t found or loadable – worth confirming the library path and that the sidadm user can actually read it, before assuming anything’s wrong with the certificate. A port bind failure on startup (SAP Note 2089881, or the more general “address already in use” in SAP Note 1845121) is usually a permissions or port-conflict issue rather than anything certificate-related.
You imported a new certificate in STRUST, but the system’s still serving the old one. This is expected, not a bug – ICM caches the SSL PSE at startup and doesn’t pick up STRUST changes live (SAP message TRUST085 flags exactly this: “SSL PSE saved (restart ICM)”). An ICM restart (SMICM → Administration → ICM → Exit Soft, not a full instance restart) is what actually activates it. This is one of the things SLS-based automation (see our renewal guide) is genuinely better at – it’s designed to handle activation as part of the renewal, not leave it as a separate manual step.
SAP NetWeaver AS Java (PI/PO)
“Certificate chain incomplete, no certificate found for issuer” when importing a CSR response. SAP Note 1745538. NWA’s Key Storage needs the full chain to resolve who issued what – if your CA only sent back the leaf certificate, go back and get the intermediate(s) as well before importing.
Exporting a keystore view to PSE fails with “Not a root certificate”. Same root cause as above, at a different step – an incomplete chain in the keystore view (referenced against SAP Note 1834904). Check every entry in the chain is present in Key Storage, not just the server certificate itself.
You restarted the SSL Provider service (or the whole instance), but the new certificate still isn’t live. SAP Note 2739561 covers the SSL access point disappearing after an ICM restart on AS Java – if that’s what you’re seeing, re-exporting the keystore view and restarting the SSL Provider service again (NWA → Operation Management → Systems → Start&Stop → JAVA-EE Services) is the documented fix. Worth double-checking you actually restarted the SSL Provider and not just the ICM, since they’re separate steps – see Step 5 of our installation guide.
Confusion between the TrustedCA keystore view and your own server certificate. Not an error message so much as a recurring mix-up: TrustedCA is for certificates your system needs to trust when it calls out to other systems, not for your own HTTPS certificate. If a certificate you imported doesn’t seem to be doing anything, it’s worth checking it went into the ssl-credentials view (or whichever view your server certificate actually uses) rather than TrustedCA.
SAP Integration Suite (CPI)
Custom domain certificate upload rejected. Three distinct errors cover most of what goes wrong here: “the uploaded domain certificate chain could not be parsed” (SAP Note 3313541) means the file itself is malformed; “could not be verified – make sure that KEY, CSR, and received certificate belong together” (SAP Note 3229070) means you’ve got a private key and certificate that don’t match, usually from a CSR generated separately from the key you’re now uploading; and “invalid certificate chain – upload valid certificates in the correct signing order” (SAP Note 3195663) is the same leaf-then-intermediate-then-root ordering issue that trips up every other system on this list.
An integration flow fails calling an external system, with something like “PKIX path building failed” or SunCertPathBuilderException. SAP Note 2765110 (with a BTP-OAuth-specific variant in SAP Note 3730800). This means the target system’s certificate chain isn’t in your tenant’s keystore – it’s not a problem with your own certificate at all. Add the external system’s certificate chain via Key Store Monitor (SAP Note 2715005 walks through pulling a certificate straight from a website’s HTTPS connection, which is usually the fastest way to get the right chain).
“No private key found in the keystore for the alias <name>”. SAP Note 3240189. Either the alias configured in your integration flow doesn’t match what’s actually in the keystore, or the keystore entry itself is certificate-only, with no private key attached – check which one you’re dealing with before assuming the import failed.
Automating renewal via the Security Content OData API and the query isn’t behaving as expected. Worth knowing before you build much automation on it: $filter isn’t supported against the KeystoreEntries collection from an iflow’s OData receiver channel. Pull the full entry list and do your expiry-window filtering in the integration flow itself, not in the OData query – see the “Building the automation” section of our renewal guide.
Still stuck?
If none of the above matches what you’re seeing, the fastest way forward is usually the exact error text from your system’s trace log (dev_icm, dev_webdispatcher, or the equivalent) searched directly against SAP Notes – error numbers and message classes (like SSSLERR_* or TRUST0**) are specific enough that they usually turn up the right note on the first try. If you’d rather just ask, get in touch and we’ll do what we can to point you in the right direction.