Network Access (mTLS & IP)

Configure secure connectivity to CommBank APIs

Overview

To connect to our APIs, you must configure secure network access for your environment.

Without this setup, your requests will be rejected:

• Only approved systems can connect
• All communication between your system and ours is encrypted and trusted

Configure the following with the help of our Integration Team:

• mTLS certificate (DigiCert X9)
• Static outbound IP addresses (whitelisting)

This setup is required for both Non-Prod and Production environments.

---

Plan for access early

Network access setup is often the longest lead-time step in integration. You should begin this early to avoid delays later.

What typically takes time

• Requesting and issuing a DigiCert X9 certificate
• Setting up static outbound IP addresses
• Internal infrastructure and security approvals

---

Step 1

mTLS certificate (DigiCert X9)

• Since October 2025, public TLS certificates issued by DigiCert can no longer be used for mutual TLS (mTLS). This is because Google's Root Program update requires the removal of the Client Authentication Extended Key Usage (EKU) from public TLS certificates. From that date, public TLS certificates will only contain the Server Authentication EKU — meaning they can only prove a server's identity, not a client's identity.

  To continue supporting mTLS, DigiCert issues certificates under the X9 PKI — a separate certificate system that is not affected by this change.

  What is the X9 PKI?

  The X9 PKI is a dedicated Business-to-Business (B2B) public key infrastructure developed by the Accredited Standards Committee X9 (ASC X9), a U.S.-based standards body focused on cryptographic and security standards for the financial services industry.

  ASC X9 owns and governs the X9 PKI. DigiCert operates the infrastructure on their behalf. At present DigiCert is the only CA selling X9 certs, but in the future other CAs like Sectigo might start selling X9 certs as well.

  Unlike public TLS certificates — which are governed by browser vendors and the CA/Browser Forum — X9 PKI certificates operate under an independent certificate policy.

  What is Client Authentication?

  It is important to understand the difference between Server Authentication and Client Authentication:

  Server vs Client Authentication

  Role	Purpose	Certificate type
  Server Authentication	Proves the identity of a server to anyone connecting to it (e.g. a client calling an API).	Public TLS certificate (trusted by default on all systems, governed by CA/Browser Forum rules).
  Client Authentication	Proves the identity of a client to the server it is connecting to (e.g. a customer authenticating to an API).	X9 certificate (governed by the X9 Certificate Policy, independent of CA/Browser Forum rules).

  When CommBank hosts an API, CommBank presents a public TLS Server Authentication certificate so that connecting clients can verify they are talking to CommBank.

  To authenticate back to CommBank's API, customers use an X9 Client Authentication certificate.

mTLS Requirements

All HTTPS requests to our APIs must use Mutual TLS Authentication (mTLS) with a DigiCert X9 certificate.

See DigiCert documentation to request certificates here.

What you need:

1. RSA 4096 certificate — i.e. algorithm=RSA, key length=4096.
2. No wildcard certificates as they are not supported — i.e. Common Name (CN) = *.example.com.

DigiCert will verify domain ownership before providing you with a certificate.

Once you have a DigiCert X9 certificate, provide it to your Integration Team for validation. We will validate that the certificate you've provided is a valid DigiCert X9 certificate and use the Common Name (CN) from it. The CN for non-prod and prod must be different.

Certificate renewal

mTLS certificates expire and must be renewed regularly.

DigiCert manage mTLS certificate renewal.

DigiCert X9 Certificate Validity is not changing. But it’s worth noting that Domain Validation Reuse is reducing. Public TLS Certificate Validity is reducing, however this has no impact on Digicert X9 Certificate Validity.

Certificate renewal schedule

Date	Max DigiCert X9 Certificate Validity	Max DigiCert X9 Domain Validation Reuse	Max Public TLS Certificate Validity
From 24-Feb-2026	1 year default (max 397 days)	199 days	200 days (199 days for DigiCert)
From early 2027	1 year default (max 397 days)	99 days	100 days (99 days for DigiCert)
From early 2029	1 year default (max 397 days)	9 days	47 days (46 days for DigiCert)

Security recommendations

1. Where automatic renewal is available, teams should adopt short-lived certificates. For high-trust mTLS/server-to-server use cases, the recommended target is 46-day certificate validity, renewed on a monthly cadence. This is a security recommendation, not a DigiCert X9 requirement.
2. DigiCert X9 certificates currently permit validity up to 397 days. This should be treated as a vendor maximum, not as the preferred internal standard. Long-lived certificates increase the exposure window if a private key is compromised, if certificate details become stale, or if revocation is not consistently checked and enforced.
3. Application/platform teams remain responsible for ensuring renewed certificates are actually deployed and used.
4. Renewal automation should run during supportable business hours. A recommended pattern is:
   1. Check certificate expiry once a day during business hours.
   2. Initiate renewal when less than 3 weeks / 21 days remain.
   3. Renew certificate for 46 days.
   4. Escalate before the remaining validity drops below 14 days.
5. By early 2029, DigiCert X9 domain validation reuse is expected to reduce to 9 days. Teams should ensure domain validation is reliable enough that certificate renewal is not blocked by expired domain validation.

Step 2

IP Whitelisting

When onboarding you must provide a list of static egress IP addresses which will be used to send requests to our APIs in both non-production and production environments.

Requests from any other IP will be rejected.

Requirement:

• Use static outbound IP addresses
• If you are using cloud infrastructure, route traffic through fixed egress IPs.

You can provide your IP addresses to our Integration Team.

You can provide either:

• One or more IPv4 Addresses — e.g. 203.0.0.1
• One or more IPv4 CIDR Addresses — e.g. 203.0.0.0/24

---

Common issues

Connection fails immediately

• Certificate not configured correctly
• IP not whitelisted

Intermittent failures

• Requests sent from multiple outbound IPs
• Some IPs not whitelisted

Important Note

Step 1 and Step 2 must be completed twice — once for the non-production environment and once for production.