Certificate Credential

The Certificate credential stores X.509 certificate material — a certificate, and optionally its matching private key. It is the building block for certificate-based flows such as AS2: the AS2 Client and AS2 Receiver credentials reference Certificate credentials rather than embedding raw key material directly.

Overview

A Certificate credential can hold either:

• A full keypair — a certificate and its matching private key. Required wherever Splice must prove an identity: signing an outbound AS2 payload or MDN, or decrypting an inbound message addressed to you.
• A certificate only — just the public X.509 certificate, with no private key. Used to verify or encrypt to another party — for example a trading partner's encryption or signing certificate.

A keypair can be obtained three ways: self-signed (Generated mode), imported (Keypair mode), or CA-signed via a Certificate Signing Request (CSR). Whenever Splice creates the key for you, it stays safely on our servers and is never sent anywhere else.

Storing certificates as their own credential lets you rotate certificate material in one place and reuse a single certificate across multiple higher-level credentials (for instance, sharing one sender certificate across several partner relationships).

Credential Fields

Mode

How the certificate material is supplied:

Mode	What it does	Private key
Generated (default)	Splice mints a fresh keypair server-side. The private key never leaves the server and is never returned on read. Only the public certificate is exposed for sharing.	Held server-side
Keypair	You supply a PEM-encoded private key and its matching certificate. Use this to import an existing identity (e.g. one issued by your CA).	Supplied by you
Certificate Only	You supply just a public X.509 certificate — typically a partner's. No private key is stored.	None

Certificate

The PEM-encoded X.509 certificate.

• In Generated mode this is produced for you and shown so you can share the public certificate with partners.
• In Keypair and Certificate Only modes you paste the PEM certificate here.

Private Key

(Keypair mode only) The PEM-encoded private key matching the certificate.

This field is write-only — it is accepted when you create or update the credential, but is never returned when the credential is read back through the API or UI. Server-side consumers (such as AS2 signing and decryption) load it directly when needed.

Private keys are sensitive

A private key proves your identity to partners. Splice stores it encrypted and never returns it on read. Never share a private key, embed it in workflow parameters, or paste it into logs. When exchanging certificates with a partner, only ever send the public certificate.

Choosing a Mode

• Generating a new identity for AS2 or signing? Use Generated — the private key stays protected server-side and you simply hand the public certificate to your partner.
• Bringing an existing certificate issued by your CA or another system? Use Keypair and paste both halves.
• Storing a partner's certificate so you can encrypt to them or verify their signatures? Use Certificate Only — you never have (and never need) their private key.
• Need a CA-signed certificate rather than a self-signed one? Start a new credential and choose Request via CSR instead of generating a pair — see Requesting a CA-signed certificate (CSR).

Requesting a CA-signed certificate (CSR)

By default, Generated mode produces a self-signed certificate — which is fine when you and your partner simply exchange public certificates directly. When a partner's requirements or your own policy demand a certificate signed by a Certificate Authority (CA) — a public CA such as DigiCert, or your organization's internal CA — use a Certificate Signing Request (CSR) instead.

A CSR is the standard way to have a certificate issued: you generate a keypair, send the CA a request containing your public key and subject details (signed by your private key to prove you hold it), and the CA returns a signed certificate. Just like Generated mode, the private key never leaves Splice — only the CSR, which is safe to share, goes to the CA.

The CSR lifecycle

1. Generate the CSR. On a new Certificate credential, choose Request via CSR. Optionally customize the certificate subject (see below), then generate. Splice mints a keypair, builds and signs the CSR, and the .csr file downloads automatically. The credential is saved in an Awaiting CA-signed certificate state.
2. Send the CSR to your CA. Submit the downloaded .csr through your Certificate Authority's process. You can re-download it at any time with Download CSR.
3. Import the signed certificate. When the CA returns your certificate, open the credential and choose Import signed certificate. Paste the PEM the CA returned — include any intermediate / root certificates from the chain if they were provided. Splice verifies the certificate matches the private key it is holding, then activates it.

Once imported, the credential behaves exactly like a Generated one: it pairs a usable certificate with a protected private key, and you can Download Public Certificate to share it with partners.

Customizing the certificate subject

When generating a CSR you can optionally set the Distinguished Name (DN) the CA will sign. These fields are collapsed by default — generate without touching them to accept the defaults, or expand Customize certificate subject to override any subset:

Field	Default
Common Name (CN)	splice:<credential name>
Organization (O)	Splice
Organizational Unit (OU)	(none)
Country (C)	US
State / Province (ST)	(none)
Locality (L)	(none)

Any field left blank uses its default. Public CAs often validate these values against your organization, so set them to match what the CA expects; private and partner CAs may ignore them.

Validation on import

Splice checks that the certificate you import was issued for the keypair it generated — the certificate's public key must match the stored private key. A certificate that doesn't match (for example, one returned for a different request) is rejected.

Common Setups

What you're setting up	Mode	What you do
A new identity for yourself (self-signed)	Generated	Create the credential — Splice mints the keypair. Share the public certificate with your partner.
A CA-signed identity for yourself	Request via CSR	Generate the CSR, send it to your CA, then import the signed certificate they return. See Requesting a CA-signed certificate.
An existing certificate you already hold	Keypair	Paste in both the private key and its matching certificate.
A partner's certificate (so you can encrypt to them or verify their signatures)	Certificate Only	Paste in just their public certificate — no private key needed.

Security

• Private keys are write-only and encrypted at rest — they are never returned through the API or UI.
• Prefer Generated mode when minting a new identity, so the private key is created and retained server-side and never transits an external system.
• CSR keeps the private key server-side too — when requesting a CA-signed certificate, only the CSR and the resulting public certificate leave Splice; the private key is generated and held server-side throughout.
• Plan rotation ahead of expiry — certificates have a notAfter date. Flows that depend on a certificate (such as AS2) warn as expiry approaches and fail once it passes. Replace the certificate before then.
• Only ever share the public certificate with partners — never the private key.

Related

• AS2 Client Credential — references Certificate credentials for the sender and partner certificates
• AS2 Receiver Credential — references a Certificate credential to decrypt inbound AS2 messages and sign MDNs