AS2 Client Credential

The AS2 client credential bundles the certificates and delivery policy used by the AS2 node to sign, encrypt, and exchange messages with a trading partner. One AS2 credential represents one sender ↔ partner relationship — if you exchange messages with multiple partners, create one credential per partner.

Overview

An AS2 exchange involves three certificates and a small set of policy decisions about Message Disposition Notifications (MDNs). The AS2 client credential captures all of them in one place so individual workflow steps only need to reference the credential by name.

The credential references three underlying certificate credentials rather than embedding raw key material directly. This separation lets you:

• Manage certificate rotations without touching the AS2 credential
• Reuse a sender certificate across multiple partner relationships
• Share a partner's encryption certificate across multiple AS2 credentials when the partner runs distinct flows over the same trust material

Required Setup

Before creating the AS2 credential you need three certificate credentials in place:

Certificate Credential	Contains	Purpose
Sender Certificate	Your X.509 certificate and matching private key	Signs the outbound AS2 payload
Partner Encryption Certificate	The partner's public X.509 certificate	Encrypts the outbound AS2 payload
Partner Signer Certificate (optional)	The partner's signing certificate (often the same cert as their encryption certificate)	Verifies the signature on signed MDNs returned by the partner

Certificate Exchange

During AS2 onboarding you will exchange certificates with your partner: you send them the public half of your sender certificate so they can verify your signatures and decrypt outbound MDNs; they send you the certificates they use for encryption and signing. Never share your sender private key.

Credential Fields

Sender Certificate

The certificate credential containing your certificate and matching private key. The private key is required — without it the node cannot sign outbound payloads. This is typically a credential of type "Certificate" or "X.509 Key Pair" in the credential service.

Partner Encryption Certificate

The certificate credential containing the partner's public certificate used to encrypt payloads to them. The private key is not required (and would not be available — it is held by the partner).

Partner Signer Certificate

(Optional) The certificate credential containing the partner's signing certificate. Configure this whenever you expect signed MDNs from the partner; without it, signed MDNs cannot be verified and the node will fail with signature-error when MDN signature validation is enabled.

In practice partners often use the same certificate for encryption and signing, in which case this field references the same certificate credential as Partner Encryption Certificate.

Preferred MIC Algorithm

The hash algorithm used to compute the Message Integrity Check (MIC):

Value	Notes
sha256 (default)	Recommended for new integrations
sha384	Use when the partner specifies SHA-384
sha512	Use when the partner specifies SHA-512
sha1	Legacy support only — avoid unless the partner cannot accept stronger algorithms

The partner must support the chosen algorithm. If unsure, check the partner's onboarding documentation or stay with the default.

Request MDN

Whether to ask the partner for a Message Disposition Notification confirming receipt and processing of the message.

• Enabled (default) - The partner returns an MDN; the node parses it and reports the disposition in the workflow result.
• Disabled - No MDN is requested; the node accepts a 2xx HTTP status as success with no application-layer confirmation.

Disabling MDNs is rare in production — most partners expect them and many will reject messages that do not request one.

Request Signed MDN

Controls whether signed MDNs are requested and how unsigned MDNs are treated:

Value	Behavior
required	The partner is asked for a signed MDN. Unsigned responses fail with signature-error.
optional (default)	The partner is asked for a signed MDN, but unsigned responses are accepted.
none	No MDN signature is requested or validated.

For most partners optional is the right choice — it negotiates signing when the partner supports it without breaking interoperability when they do not.

Validate MIC

When enabled (default), the node compares the locally computed MIC against the Received-Content-MIC reported in the partner's MDN. A mismatch returns mic-mismatch and indicates either tampering or a canonicalization difference between implementations.

Disable only when working around a known partner-side canonicalization quirk that cannot be resolved otherwise.

Validate MDN Signature

When enabled (default), the node verifies the detached PKCS#7 signature on signed MDNs against the configured Partner Signer Certificate. If no partner signer certificate is configured and a signed MDN is returned, validation fails with signature-error.

Example Configuration

Standard Trading Partner

A typical configuration for a partner that signs MDNs:

Sender Certificate: Acme Production Sender Cert
Partner Encryption Certificate: BigRetailer Encryption Cert
Partner Signer Certificate: BigRetailer Encryption Cert  (same cert)
Preferred MIC Algorithm: sha256
Request MDN: true
Request Signed MDN: optional
Validate MIC: true
Validate MDN Signature: true

Partner That Does Not Sign MDNs

For older or simpler partner integrations that return unsigned MDNs:

Sender Certificate: Acme Production Sender Cert
Partner Encryption Certificate: SmallVendor Encryption Cert
Partner Signer Certificate: (not set)
Preferred MIC Algorithm: sha256
Request MDN: true
Request Signed MDN: none
Validate MIC: true
Validate MDN Signature: false

High-Trust Integration

When the partner reliably returns signed MDNs and the contract requires non-repudiation:

Sender Certificate: Acme Production Sender Cert
Partner Encryption Certificate: Carrier Encryption Cert
Partner Signer Certificate: Carrier Signing Cert
Preferred MIC Algorithm: sha384
Request MDN: true
Request Signed MDN: required
Validate MIC: true
Validate MDN Signature: true

Onboarding Checklist

When setting up a new partner:

1. Obtain the partner's certificates - Receive their encryption certificate (and signing certificate, if separate) in PEM format
2. Send them your sender certificate - Export the public half of your sender certificate and provide it to the partner
3. Confirm the AS2 identifiers - Agree on the AS2-From and AS2-To strings each side will use
4. Confirm the receiver URL - Get the partner's AS2 endpoint URL
5. Confirm the MIC algorithm - Most partners support SHA-256; some require SHA-1 for compatibility
6. Confirm MDN expectations - Ask whether they sign MDNs, and whether they expect signed MDNs from you
7. Create the certificate credentials - Add the sender certificate (with private key) and partner certificates as separate credential entries
8. Create the AS2 client credential - Reference the certificate credentials and set the policy fields
9. Run a test exchange - Use a small known-good payload to verify end-to-end delivery and MDN handling before connecting live data

Security

• Sender private keys are sensitive material - They prove your identity to partners. Splice stores them encrypted; never embed them in workflow code, parameters, or logs.
• Plan certificate rotation in advance - Partner certificates expire. The AS2 node emits a near-expiry warning starting 30 days before the partner encryption certificate's notAfter date, and blocks sends once it is expired.
• One credential per partner - Sharing a single AS2 credential across partner relationships forces all partners to use the same MDN policy and obscures the trust boundaries between them.
• Audit credential changes - Any change to certificates or MDN policy directly affects production message exchange. Coordinate updates with the partner when possible.

Troubleshooting

Common Issues

• AS2 client credential is missing sender or partner encryption certificate reference - The credential is incomplete. Confirm that both Sender Certificate and Partner Encryption Certificate are set.
• Sender certificate credential [...] is missing key material - The certificate credential referenced as the sender does not include a private key. Re-import the credential with the matching private key.
• Partner encryption certificate credential [...] has no certificate - The referenced credential is empty or contains only a private key. Verify it contains the partner's public certificate.
• Signed MDN failures after a partner certificate update - The partner rotated their signing certificate. Update the certificate credential referenced as Partner Signer Certificate.
• certificate-expired transport errors - The partner encryption certificate has passed its notAfter date. Obtain the new certificate from the partner and update the certificate credential.

Related

• AS2 Node - Uses this credential to send signed and encrypted AS2 messages