Skip to main content

Raidiam Connect Public Key Infrastructure

Raidiam Connect Public Key Infrastructure (PKI) provides a turnkey certificate management service for trust framework ecosystems. It enables organizations and their technical resources–like apps or servers– to establish identity, encrypt communications, and digitally sign messages, without building or operating their own PKI.

What Raidiam Connect PKI provides​

Raidiam Connect Public Key Infrastructure (PKI) enables organisations to create, manage, distribute, and revoke digital certificates for secure network communications.

The PKI requires each participant to prove its identity with a digital certificate before exchanging data. A digital certificate is an X.509 electronic document that uses a digital signature to bind a public key with an organisation's identity. The issuing Certificate Authority signs each certificate so that any relying party can verify its authenticity.

Raidiam Connect also supports integrating external certificates into the trust framework, so organisations that already hold certificates from a recognised Certificate Authority can use them alongside Raidiam-issued certificates.

How certificate issuance works​

The following diagram shows the high-level flow when a participant requests a certificate through Raidiam Connect.


Figure 1: Certificate issuance and validation flow in Raidiam Connect.

During data exchange, both parties present their digital certificates in a mutual TLS (mTLS) handshake. Each party verifies the other's certificate by checking the Certificate Authority's signature on it and confirming the certificate's validity status through the Certificate Validation Service.

For example, imagine a Data Provider, Bank A, and a Data Receiver, Fintech B, initiating a data exchange. Bank A presents its certificate to Fintech B as part of the mTLS handshake, and Fintech B does the same. Each party verifies the CA's signature on the received certificate using the CA's public key and checks the certificate status. Once both certificates are confirmed valid, the secure exchange of information proceeds.

For detailed information about certificate contents, formats, and issuance steps, see Certificates.

Why Raidiam Connect PKI matters for ecosystem participants​

Turnkey certificate management​

Raidiam acts as both the Registration Authority and the Certificate Authority, so participants can obtain and manage certificates without building their own PKI infrastructure.

Single trust anchor​

All certificates and public keys are published through a centrally managed Public Key Store (JWKS), giving every relying party one authoritative location to verify identities.

Integrated with the participant directory​

Certificate issuance is tied to the participant directory, ensuring that only accredited organisations receive certificates.

Security​

PKI encrypts data in transit and authenticates communicating parties, ensuring that sensitive information exchanged between ecosystem participants remains confidential.

Identity verification​

Digital certificates provide cryptographic proof that the entities involved in a transaction are who they claim to be, preventing impersonation attacks.

Data integrity​

Digital signatures ensure that data has not been tampered with during transmission. Any modification invalidates the signature.

Compliance​

Many regulatory frameworks, including Open Finance and Open Banking mandates, require participants to use PKI for identity assurance and data protection. Raidiam Connect's built-in PKI helps ecosystems meet these requirements.

Common use cases​

Raidiam Connect PKI supports a range of scenarios within trust framework ecosystems.

Secure API-to-API communication with mTLS​

When a Data Receiver calls a Data Provider's API, both parties establish a mutual TLS (mTLS) connection before any data is exchanged. During the TLS handshake, each side presents its transport certificate so the other can verify its identity. The connection is encrypted end to end, which prevents eavesdropping and man-in-the-middle attacks.

Because every API call goes through this handshake, participants can be confident that they are communicating with an accredited organisation and that the data in transit cannot be read or altered by a third party.

OAuth client authentication​

Client applications can authenticate to the authorisation server using their certificate instead of — or in addition to — a client secret. During the token request, the client presents its certificate over an mTLS connection. The authorisation server verifies the certificate's validity and checks that the Distinguished Name on the certificate matches the one registered for that client.

This approach is defined in RFC 8705 and provides stronger assurance than shared secrets, because the private key never leaves the client and cannot be accidentally exposed in logs or configuration files.

Signed and encrypted messages​

Participants use their signing key pairs to create JSON Web Signatures (JWS) over request and response payloads. A valid signature proves that the message was sent by the key holder and that its content has not been modified since it was signed, providing both authenticity and non-repudiation.

When confidentiality is required — for example, when sensitive customer data travels through the browser or another untrusted channel — participants encrypt the payload using the recipient's public encryption key to produce a JSON Web Encryption (JWE) object. Only the intended recipient, who holds the corresponding private key, can decrypt and read the content.

JWKS-based token verification​

When a relying party receives a signed JWT — such as an access token or a request object — it needs the signer's public key to verify the signature. Instead of exchanging keys manually, the relying party fetches the signer's JSON Web Key Set (JWKS) from the centrally managed Public Key Store.

Because the JWKS endpoint is maintained automatically by Raidiam Connect, public keys are always up to date. When a key pair is rotated or a certificate is revoked, the JWKS reflects the change without any manual intervention from the relying party.

External certificate integration​

Some ecosystems require participants to use certificates issued by a specific external Certificate Authority — for example, to comply with jurisdiction-level regulations or to interoperate with legacy systems. Raidiam Connect allows these organisations to import their existing certificates into the trust framework and use them alongside Raidiam-issued certificates.

Imported certificates go through the same validation and status-checking processes as Raidiam-issued ones, so all participants in the ecosystem can verify them through a single, consistent trust chain.

Certificate types: transport, signing, and encryption​

Raidiam Connect manages three categories of certificates, each serving a distinct purpose. To learn more about certificate contents, formats, CSRs, and the issuance process, see Certificates.

Transport certificates​

Transport certificates are used for mTLS connections between participants. They authenticate the communicating parties and encrypt data in transit. See Key pair usage — mTLS certificates for details.

Signing certificates​

Signing certificates are used to digitally sign messages (JWS), enabling identity validation and non-repudiation. See Key pair usage — signing keys for details.

Encryption certificates​

Encryption certificates are used to encrypt payloads (JWE) so that only the intended recipient can decrypt and read the content. This protects data confidentiality when it travels through unsecured channels such as the browser. See Key pair usage — encryption keys for details.

Certificates can be issued at the organisation level or the application level depending on the use case.

Certificate lifecycle​

Each certificate follows a defined lifecycle:

  1. Request — The organisation generates a key pair and submits a Certificate Signing Request (CSR) to the Registration Authority.

  2. Issuance — The Registration Authority validates the request and forwards it to the Certificate Authority, which signs and returns the certificate.

  3. Active use — The certificate is installed on servers or applications for mTLS handshakes, message signing, or encryption.

  4. Renewal — Before a certificate expires, the organisation submits a new CSR. The CA issues a replacement certificate while the existing one remains active during the transition. For guidance on rotating the underlying key pairs, see the key rotation blog post.

  5. Revocation — If a certificate is compromised or no longer needed, it can be revoked. Revocation status is published through the Certificate Validation Service via OCSP and CRL.

  6. Expiry — Certificates that are not renewed become inactive after their validity period ends.

For step-by-step instructions, see Manage organisation certificates and Manage application certificates.

Supported standards and algorithms​

Raidiam Connect PKI is built on widely adopted standards:

StandardDescription
X.509 v3Certificate format used for all issued certificates
RSA (2048-bit and above)Supported key algorithm for certificate key pairs
ECDSA (P-256, P-384)Supported elliptic-curve key algorithm
OCSP (RFC 6960)Online Certificate Status Protocol for real-time certificate validation
CRL (RFC 5280 §5)Certificate Revocation Lists for batch revocation checking
PEM / DERSupported certificate encoding formats

PKI components in Raidiam Connect​

Raidiam Connect's PKI consists of the following components. In most ecosystems, Raidiam acts as both the Registration Authority and the Certificate Authority, providing a turnkey certificate service.

Figure 2: How PKI components interact in Raidiam Connect.

Registration Authority​

A Registration Authority (RA) verifies the eligibility of PKI participants and ensures the accuracy of information provided during the certificate request process.

The RA screens and validates each certificate request from the applicant and decides whether it should be accepted. If a certificate request is accepted, the Registration Authority submits it to the Certificate Authority for signing.

In Raidiam Connect, the RA automatically validates your CSR when you submit it through the platform UI or API.

Certificate Authority​

A Certificate Authority (CA) authenticates the identity of subscriber entities and binds them with a cryptographic key. The CA digitally signs the submitted public key with its own private key and issues the digital certificate. The CA returns the certificate to the RA for onward transmission to the subscriber.

Raidiam Connect operates a dedicated issuing CA for each ecosystem, chained to a secure root CA.

Certificate Validation Service​

Certificate Validation Services verify the authenticity and validity of a digital certificate. This includes checking the certificate's status (whether it is active, revoked, or expired), verifying the CA's signature, and confirming the certificate was issued by a trusted Certificate Authority.

Raidiam provides validation services using open standards: Online Certificate Status Protocol (OCSP) per RFC 6960 and Certificate Revocation Lists (CRL) per RFC 5280.

Participants and their servers can query these endpoints to check certificate status in real time before establishing a connection.

Key Management Services​

Key Management Services (KMS) handle the secure lifecycle management of cryptographic keys used to encrypt or digitally sign data. This includes the secure generation, exchange, use, storage, and replacement of keys.

Raidiam Connect's KMS manages keys on behalf of participants and supports automated key rotation. For more on rotation practices, see Key rotation for PCI DSS compliance.

Public Key Store​

Public Key Stores host JSON Web Key Sets (JWKS) for each organisation and software instance in an ecosystem. The system maintains active and inactive keys at the individual software and organisation level, correlating each key to the status of its corresponding digital certificate.

A centrally managed Public Key Store in JWKS format is critical to ensuring that ecosystem API consumers and relying parties have a single trust anchor and location to obtain the necessary public keys.

When a certificate is issued, renewed, or revoked, the corresponding public key in the JWKS endpoint is automatically updated.

Open Book IconTABLE OF CONTENT