MTLS (Mutual Transport Layer Security)

MTLS Certificate Attributes - Distinguished Name

VCAS will generate a certificate using the Digicert PKI with the following encryption:

• RSA Encryption - RSA 2048, 4096
• EC Encryption - P256, P384, P521

Signed certificates are valid for two years.

MTLS Enablement

OAuth2 uses TLS 1.2 for message encryption and is an alternative to MTLS, which authenticates VCAS with a certificate. The use of both OAuth and MTLS is NOT recommended because it will create redundant authentication of VCAS prior to messages transmission.

First Time Certificate Generation Steps for New Clients

The issuer will:

• Generate a private key and will not share the key with other parties
• Generate a CSR (Certificate Signing Request) from their private key including the certificate attributes and the CN (Common Name).
  • Partners can use the key generation tool of their choice to generate a public/private keypair; the minimum keypair strength must be RSA 2048
  • The Common Name in the CSR must match the endpoint name
• Submit the CSR to Cardinal with an email address (preferably a group email) to have it signed by CardinalCommerce CA. Use this email format to submit your CSR:

If the issuer sends the CSR to VCAS to have it signed, then VCAS will:

• Assign the key usage and configure all required values
• Review and sign the CSR to create the public certificate
• Issue the signed public certificate back to the email supplied by the issuer

If the issuer choses a third-party CA to sign their CSR:

• Issuer needs to send VCAS a copy of the signed public certificate

Client Certificate Expiration and Renewal Process

Cardinal will send a renewal notification to the email supplied by the partner 60 days prior to certificate expiration. The notification will contain a link to submit a new CSR to renew the certificate. Renewal notifications are sent at 60, 30, 10, 7 and 1-day intervals. The key generation for renewed certificates should be handled by the client.

1. The partner will need to trust list the IP addresses from VCAS. Tests will be run from each data center to ensure connectivity.
2. The partner will need to first create the endpoint/DNS that will be used to receive API requests from VCAS outlined above. Please note, VCAS cannot accept IP addresses. A full path URL with a globally available DNS record is required.
3. Once created, the partner will create a certificate signing request (CSR) for the DNS entry created above. Partners can use a key generation tool of their choice to generate a public/private keypair; minimum keypair strength must be RSA 2048.
4. Once the CSR is created, the partner can submit the CSR using the link in the renewal notification or provide the CSR to the VCAS implementation manager.
5. Cardinal will return a full chain certificate (containing root, intermediate and client certificates) to the partner.
6. This full chain certificate will need to be installed on the endpoint/firewall trust store that is being used to receive API requests from VCAS.
   Note: Due to the complexity and wide variety of network hardware/software, Cardinal cannot advise on how to best install these certificates. It is the responsibility of the partner to configure these certificates correctly.
7. Once the certificates are exchanged, MTLS connections will be made between the client (VCAS) and server (partner network) to exchange application data. An MTLS conversation is created as follows:
   a. During the initial hello, client (VCAS), will send a request to the server (partner) to initialize communication. During the hello, VCAS will present the cipher suite and TLS extensions that are supported.
   b. The server will respond with the confirmed cipher suite and extensions to use.
   c. The server will send its server certificate, public key, hash, and a request for the client’s certificate. This completes the server-side negotiation phase. The server will need to present the VCAS provided root and intermediate certificates. Cardinal’s load-balancer will check that the server certificate was signed by an intermediate/root CA certificate in its trust store. If not, the connection will terminate; if yes, it will send the client certificate and public key.
   d. The client will initiate the client key exchange with the public client key and client certificate. The client can change the cipher suite if needed in this call. The server will decrypt the message with the VCAS public key.
   e. The client will send a “certificate verify” message that is encrypted with the client’s certificate private key. This message can be decoded by the server with the public key sent in the previous step for proof of ownership. This concludes the client negotiation phase. The server will check that the client certificate was signed by a root/intermediate CA certificate in its trust store. If not, it will terminate the connection; if yes, it will decode the “certificate verify” message with the client’s public key. At this point, the server / client validation is complete.
   f. 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.
   g. The server sends an encrypted “Finished” message that the client will decrypt. If it is successful, the MTLS handshake is complete.
   h. Application data is passed between the client and server.