SAP CPI Security Artifacts Basics: Certificates, Credentials, and Keystore Operations

SAP CPI security artifacts are reusable security objects that let an integration flow authenticate to external systems without embedding secrets in message processing logic. The main artifacts include user credentials, client certificates, PGP keys, secure parameters, and SSH keys. Each artifact has a defined purpose, lifecycle, and deployment scope.

This guide focuses on the operational decisions behind security artifacts: selecting the right artifact type, associating it with an adapter, rotating it safely, and diagnosing failures after deployment.

01Understand the main security artifact types

User credentials

User credentials store a username and password for basic authentication or for adapter-specific authentication methods. They are appropriate when the target system expects a technical user, service account, or API username and password.

Use a dedicated integration account rather than a personal user. Record the owning team, target endpoint, rotation interval, and affected integration flows in the operational documentation. Store only the values needed by the adapter and keep access to credential maintenance limited to the integration administration team.

Client certificates

Client certificates support mutual TLS when the remote server validates the calling client. The artifact usually contains a private key and its certificate chain. The remote party must trust the issuing certificate authority and must have the correct public certificate registered when its configuration requires explicit client identification.

Certificate authentication depends on both sides of the TLS exchange. A valid certificate can still fail when the certificate chain is incomplete, the private key is unavailable, the certificate has expired, or the remote endpoint does not trust the issuing authority.

Secure parameters

Secure parameters hold protected values that an integration flow needs at runtime. They are useful for values such as tokens, shared secrets, or environment-specific configuration that should not be exposed in the integration flow design.

Use secure parameters for values that are consumed by the flow but are not naturally represented as a username-password pair or a key pair. Keep the parameter name stable across environments and provide the value through the appropriate tenant administration process.

SSH keys

SSH keys support secure file transfer scenarios when an SFTP server uses public-key authentication. The private key belongs in the tenant keystore or the relevant security material, while the corresponding public key is registered with the SFTP server.

Confirm the supported key format, passphrase requirements, and host-key configuration before deployment. A successful network connection does not prove that public-key authentication is configured correctly.

PGP keys

PGP key artifacts support message encryption and signing for file-based or partner integrations. Public keys encrypt content for a recipient, while private keys decrypt content or create signatures, depending on the processing requirement.

Protect private PGP keys carefully and document the key owner, purpose, fingerprint, expiration date, and replacement procedure. Coordinate key replacement with the partner because encryption and decryption require the correct key on each side.

02Choose the artifact for the authentication pattern

Start with the authentication requirement published by the receiving system. Basic authentication normally requires a user credential, mutual TLS requires a client certificate, SFTP public-key authentication requires an SSH key, and signed or encrypted payloads require PGP keys.

For an overview of where security fits into an integration design, see SAP Integration PI PO CPI Overview. When the endpoint is part of an iFlow, review SAP CPI iFlow Basics alongside the security configuration so that the artifact reference and adapter settings are designed together.

Avoid selecting an artifact because it is convenient to maintain. The target protocol determines the authentication mechanism, and the adapter must support the selected mechanism. A credential cannot replace a client certificate when the server requires mutual TLS, and a certificate cannot provide a password expected by a basic-authentication endpoint.

03Create and assign security artifacts

1. Identify the target endpoint, authentication method, owner, expiration date, and rotation contact.
2. Open the security material area in the SAP Integration Suite tenant administration tools.
3. Select the artifact type that matches the endpoint requirement.
4. Enter a unique, descriptive artifact name such as SFTP_VENDOR_PROD_KEY or API_PARTNER_MTLS.
5. Upload the required key, certificate, or encrypted value, or enter the credential through the protected maintenance form.
6. Save the artifact and verify its status and metadata.
7. Open the integration flow and select the artifact name in the adapter or security-related configuration field.
8. Save and deploy the integration flow.
9. Execute a controlled test and inspect the message-processing log without exposing secret values.

Use names that identify the partner, environment, protocol, and purpose. Do not include passwords, private-key material, or access tokens in an artifact name, message body, exception text, or script log.

Security artifacts are referenced by name, so renaming an artifact can break deployed flows or require configuration changes. Treat names as integration interface dependencies and use a planned replacement process for rotation.

04Manage certificates and keystore entries

Certificate management requires attention to the complete chain rather than only the leaf certificate. Before importing a certificate, inspect its subject, issuer, validity period, key usage, extended key usage, and fingerprint. Confirm that the private key matches the certificate when the artifact represents a client identity.

For outbound TLS, separate the client identity from the trust configuration. The client identity proves who the integration tenant is. The trust configuration determines which server certificates and certificate authorities the tenant accepts. Both sides must be configured consistently.

A practical certificate rotation process is:

1. Obtain the replacement certificate and verify its fingerprint through a trusted channel.
2. Confirm that the replacement private key and certificate chain are complete.
3. Import the replacement material under a new, clearly named artifact when parallel validation is possible.
4. Register the new public certificate with the partner or endpoint owner.
5. Update the integration flow or endpoint configuration to reference the replacement artifact.
6. Deploy and run a controlled connectivity test.
7. Monitor successful processing and partner acknowledgements.
8. Retain the old artifact only for the agreed rollback period, then remove it according to the security policy.

Do not wait until the certificate expiration date to begin rotation. Start early enough to allow partner registration, testing, approval, and rollback.

05Handle user credentials and secret rotation

A password rotation changes the value stored in the artifact and may also require a change in the remote system. Coordinate both actions so that the integration does not enter a period where the tenant and endpoint hold different values.

For a controlled rotation, create or update the credential according to the tenant’s change process, test the endpoint with a non-production message where possible, and then observe normal processing after deployment. Record the completion time, responsible team, affected artifact, and validation result without recording the secret itself.

If multiple flows use one credential, inventory those references before rotation. A shared technical user can create a broad failure domain, so separate credentials by partner, environment, or business purpose when the target system and operating model support that design.

The adapter configuration also matters. Review SAP CPI Adapter Types Comparison when authentication behavior depends on the selected adapter, transport protocol, or endpoint pattern.

06Troubleshoot authentication failures

Begin with the exact error time, message-processing log, integration flow version, endpoint, and artifact name. Compare the failure with a known successful execution and determine whether the failure occurs during DNS resolution, TCP connection, TLS negotiation, authentication, authorization, or application processing.

Credential failures

Check the username, password status, account lock state, password expiration, endpoint URL, and authentication method expected by the receiver. Confirm that the deployed flow references the intended artifact and that the change was deployed to the correct tenant or environment.

TLS and certificate failures

Check certificate validity, the complete certificate chain, server-name matching, trust configuration, client-certificate registration, and the endpoint’s supported TLS settings. Use the certificate fingerprint to ensure that the tenant and partner are discussing the same certificate.

A trust failure usually indicates that the receiving certificate chain is not accepted. A client-authentication failure usually indicates that the receiver did not accept the presented client identity or that the tenant could not provide the required private key.

SFTP and SSH failures

Check the SFTP host, port, username, directory permissions, host-key verification, private-key format, passphrase handling, and public-key registration. Confirm that the technical user can access the required directory and that the server allows the configured authentication method.

PGP failures

Check the recipient key used for encryption, the private key used for decryption, key fingerprints, expiration dates, signature requirements, and file-processing order. A partner key replacement must be reflected in the correct direction: encryption uses the recipient’s public key, while decryption uses the corresponding private key.

For message-level diagnosis, pair artifact checks with SAP CPI Monitoring and Error Handling Basics. Monitoring evidence should identify the failing stage without logging passwords, private keys, access tokens, or decrypted business payloads.

07Operate artifacts across environments

Use a consistent artifact naming convention across development, test, and production while keeping environment-specific values separate. A name such as PARTNER_API_MTLS can remain stable when the certificate value and endpoint differ by environment.

Maintain an inventory containing the artifact name, type, owner, consuming flows, partner, environment, creation date, expiration date, rotation date, and emergency contact. Limit the inventory’s secret content to metadata; never copy private keys or passwords into the inventory.

Include security artifact checks in deployment readiness. Confirm that every referenced artifact exists in the target tenant, has the correct type, contains the required key material, and is available to the runtime identity. A flow deployment can succeed while a later message fails because the remote endpoint or credential was not prepared.

Use the integration flow version and deployment timestamp when investigating a change. This separates an artifact rotation issue from an unrelated mapping, routing, or endpoint change. For payload transformation dependencies, see SAP CPI Message Mapping Basics.

08Build a safe artifact lifecycle

A reliable lifecycle has five operational stages: request, create, validate, rotate, and retire. Assign an owner at creation time and define the retirement condition before the artifact enters production.

During validation, test authentication against the actual protocol path used by the flow. A browser test or a standalone command may validate connectivity but not the adapter’s authentication behavior, payload handling, or runtime identity.

During retirement, remove references from inactive flows, confirm that no active process depends on the artifact, and retain only the audit information required by policy. Emergency revocation should be documented separately from routine rotation so that operators can act quickly when a key or password is suspected to be compromised.

Security artifacts are part of integration operations, not a one-time configuration task. Ownership, expiration monitoring, protected logging, and tested replacement procedures keep authentication failures from becoming avoidable production outages.