RDX Specification

Standard TLS/HTTPS Authentication

Standard Transport Layer Security Protocol

Standard TLS 1.2

Existing clients using TLS are responsible for notifying the VCAS team at least 60 days before the certification expiration date. The key generation for renewed certificates should be handled by the client.

  1. Partner will need to trust list the IP addresses from VCAS. Tests will be run from each data center to ensure connectivity.

  2. Partner will need to first create the endpoint/DNS that will be used to receive API requests from VCAS as outlined above. Please note that VCAS cannot accept IP addresses. A full path URL with a globally available DNS record is required.

  3. Once created, the partner will need to attach a public facing certificate to this endpoint and provide this certificate to the VCAS implementation manager. Note: The public certificate needs to be signed by a trusted Certificate Authority. These include certificates signed by trusted global third-party CAs (DigiCert, Entrust, Thawte, etc.) or Cardinal’s own Certificate Authority. Cardinal does not accept self-signed certificates, or certificates signed by a private (internal) CA.

  4. Once the preceding steps have been completed, TLS connections will be made between the client (VCAS) and the server (partner network) to exchange application data. A standard TLS conversation is made as follows:

    • During the initial hello, client (VCAS) and server (partner network) will exchange data to confirm they have matching cipher suites and required TLS extensions.
    • The server will send its server certificate and public key. This completes the server-side negotiation phase.
    • The client (Cardinal’s load-balancer) will check that the server certificate was signed by an intermediate/root CA certificate in its trust store. If no, the connection will terminate. If yes, it will send its public key to the server. This completes the client-side negotiation phase.
    • The client sends an encrypted “Finished” message that the server will decrypt. If it succeeds, it will move to the next step. If not, the connection will terminate.
    • The server sends an encrypted “Finished” message that the client will decrypt. If it is successful, the MTLS handshake is completed, and they begin passing application data back and forth.