Mutual TLS Setup
mTLS (Mutual TLS) secures communication between Apata and your systems by requiring both sides to present and verify digital certificates. Unlike standard TLS - where only the server is verified - mTLS authenticates both parties, ensuring that only trusted systems can exchange data.
Apata supports mTLS in two directions:
Apata initiates a connection to your system (e.g. for Card Link or Webhook calls). Apata presents a certificate your CA has signed.
Your system initiates a connection to the Apata API. You present a certificate that Apata has signed.
mTLS adds an additional layer of security by validating the identity of both parties, making it the recommended approach for securing sensitive API and webhook connections.
Outbound mTLS (Apata → Issuer)
Use this when Apata calls your endpoint - for example, Card Link requests, OOB webhooks, or the Finalised Event.
Step 1 - Apata generates a CSR
Apata creates a CSR containing its organisation details and a public key, and provides it to your team for signing.
Step 2 - Sign the CSR with your CA
Sign the CSR using your own CA or an internal CA. The signed certificate authorises Apata to connect to your system.
openssl x509 -req -in apata.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out apata-outbound.crt -days 365 -sha256Step 3 - Provide the signed certificate to Apata
Return the following to Apata:
| File | Description |
|---|---|
apata-outbound.crt | The signed certificate generated from Apata's CSR. |
ca.crt | Your CA certificate. Required if you are using a private or internal CA. |
Step 4 - Configure your webhook
Add apata-outbound.crt and your CA certificate(s) to your webhook configuration. Apata will present this certificate on every outbound connection to your endpoint.
Ensure the certificate validity period aligns with your security policies. Plan renewals at least 30 days before expiry to avoid service disruptions.
Inbound mTLS (Issuer → Apata)
Use this when your system calls the Apata API. You generate a CSR, Apata signs it, and you configure your API client to present the resulting certificate on every request.
Step 1 - Generate a private key and CSR
# Generate a 2048-bit RSA private key
openssl genrsa -out client.key 2048
# Create a CSR
openssl req -new -key client.key -out client.csrYou will be prompted for the following details during CSR creation:
| Field | Example |
|---|---|
| Country Name (C) | IE |
| State or Province (ST) | Dublin |
| Locality (L) | Dublin |
| Organisation (O) | My Company Inc. |
| Organisational Unit (OU) | IT |
| Common Name (CN) | example.com |
The Common Name (CN) must exactly match the domain or hostname used to connect to Apata.
Step 2 - Share the CSR with Apata
Send client.csr to the Apata support team via a secure channel such as encrypted email or the account portal.
Step 3 - Receive your signed certificate from Apata
Apata will return the following files:
| File | Description |
|---|---|
client.crt | Your signed client certificate. Present this on all API requests to Apata. |
apata_ca.crt | Apata's CA certificate. Optional - use this to validate the Apata server certificate on the client side. |
Step 4 - Configure your API client
Update your client to present client.crt and client.key on every request. See the Code Examples below.
Code Examples
const fs = require('fs');
const https = require('https');
const httpsAgent = new https.Agent({
cert: fs.readFileSync('client.crt'),
key: fs.readFileSync('client.key'),
ca: fs.readFileSync('apata_ca.crt') // optional - validates Apata's server certificate
});
const response = await fetch('https://api.apata.io', {
method: 'POST',
body: JSON.stringify({ message: 'Test' }),
headers: { 'Content-Type': 'application/json' },
agent: httpsAgent
});CSR Requirements
Requirements
| Requirement | Detail |
|---|---|
| Common Name (CN) | Must exactly match the domain or hostname used to connect. |
| Key algorithm | RSA. Minimum 2048-bit key size. RSA 4096-bit is supported but not required. |
| All required fields | Country, Organisation, and Common Name must be populated. |
Best Practices
Store private keys (client.key) in a hardware security module (HSM) or encrypted storage. Never share or transmit private keys.
Plan certificate renewals at least 30 days before expiry. Expired certificates will cause connection failures.
Test your mTLS configuration in the Merchant Simulator before deploying to production.
Enable TLS handshake logging on your client to make connectivity issues easier to diagnose.
Troubleshooting
Connection errors
- Verify that certificates have not expired.
- Confirm the Common Name (CN) matches the domain being connected to.
- Check logs for TLS handshake failures - these will indicate whether the issue is on the client or server side.
CSR rejected
- Ensure the RSA key size is at least 2048 bits.
- Confirm all required CSR fields are populated (Country, Organisation, Common Name).
Contact support
If you cannot resolve the issue, contact the Apata support team with your error logs and certificate details.
Updated 24 days ago