RDX Specification

MTLS (Seguridad de Capa de Transporte Mutua)

TLS mutuo/autenticación bidireccional.

Atributos del Certificado MTLS - Nombre Distinguido

AttributeDescription
commonNameNombre de dominio
countryNamePaís del emisor
localityNameLocalidad del emisor
organizationNameNombre del emisor
organizationUnitNameID del emisor (proporcionado por Cardinal)
stateOrProvinceNameEstado/provincia del emisor
emailAddressDirección de correo electrónico del grupo de gestión de claves del emisor

VCAS generará un certificado utilizando el PKI de Digicert con la siguiente encriptación:

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

Los certificados firmados son válidos por dos años.

Habilitación de MTLS

OAuth2 utiliza TLS 1.2 para la encriptación de mensajes y es una alternativa a MTLS, que autentica VCAS con un certificado. No se recomienda el uso de ambos, OAuth y MTLS, porque creará una autenticación redundante de VCAS antes de la transmisión de mensajes.

Pasos para la generación de certificados por primera vez para nuevos clientes

El emisor lo hará:

  • Generará una clave privada y no compartirá la clave con otras partes.
  • Generará una CSR (Solicitud de Firma de Certificado) a partir de su clave privada, incluyendo los atributos del certificado y el CN (Nombre Común).
  • Los socios pueden usar la herramienta de generación de claves de su elección para generar un par de claves pública/privada; la fuerza mínima del par de claves debe ser RSA 2048.
  • El Nombre Común en la CSR debe coincidir con el nombre del punto final.
  • Envíe la CSR a Cardinal con una dirección de correo electrónico (preferiblemente un correo electrónico de grupo) para que sea firmada por CardinalCommerce CA. Utilice este formato de correo electrónico para enviar su CSR:

Si el emisor envía la CSR a VCAS para que la firme, entonces VCAS lo hará:

  • Asignará el uso de la clave y configurará todos los valores requeridos.
  • Revisará y firmará la CSR para crear el certificado público.
  • Emitirá el certificado público firmado de vuelta al correo electrónico proporcionado por el emisor.

Si el emisor elige una CA de terceros para firmar su CSR:

  • El emisor necesita enviar a VCAS una copia del certificado público firmado.

Proceso de Expiración y Renovación del Certificado del Cliente.

Cardinal enviará una notificación de renovación al correo electrónico proporcionado por el socio 60 días antes de la expiración del certificado. La notificación contendrá un enlace para enviar una nueva CSR para renovar el certificado. Las notificaciones de renovación se envían a intervalos de 60, 30, 10, 7 y 1 día. La generación de claves para los certificados renovados debe ser manejada por el cliente.

  1. El socio necesitará incluir en la lista de confianza las direcciones IP de VCAS. Se realizarán pruebas desde cada centro de datos para asegurar la conectividad.
  2. El socio deberá crear primero el punto final/DNS que se utilizará para recibir las solicitudes de API de VCAS descritas anteriormente. Por favor, tenga en cuenta que VCAS no puede aceptar direcciones IP. Se requiere una URL de ruta completa con un registro DNS disponible a nivel mundial.
  3. Una vez creado, el socio creará una solicitud de firma de certificado (CSR) para la entrada de DNS creada anteriormente. Los socios pueden utilizar la herramienta de generación de claves de su elección para generar un par de claves pública/privada; la fuerza mínima del par de claves debe ser RSA 2048.
  4. Una vez creada la CSR, el socio puede enviar la CSR utilizando el enlace en la notificación de renovación o proporcionar la CSR al gestor de implementación de VCAS.
  5. Cardinal devolverá un certificado de cadena completa (que contiene certificados raíz, intermedios y de cliente) al socio.
  6. Este certificado de cadena completa deberá ser instalado en el almacén de confianza del punto final/cortafuegos que se está utilizando para recibir las solicitudes de API de VCAS.
    Nota: Debido a la complejidad y a la gran variedad de hardware/software de red, Cardinal no puede asesorar sobre la mejor manera de instalar estos certificados. Es responsabilidad del socio configurar correctamente estos certificados.
  7. Una vez intercambiados los certificados, se establecerán conexiones MTLS entre el cliente (VCAS) y el servidor (red del socio) para intercambiar datos de la aplicación. Una conversación MTLS se crea de la siguiente manera:
    a. Durante el saludo inicial, el cliente (VCAS) enviará una solicitud al servidor (socio) para iniciar la comunicación. Durante el saludo, VCAS presentará el conjunto de cifrado y las extensiones TLS que son compatibles.
    b. El servidor responderá con el conjunto de cifrado confirmado y las extensiones a utilizar.
    c. El servidor enviará su certificado de servidor, clave pública, hash y una solicitud del certificado del cliente. Esto completa la fase de negociación del lado del servidor. El servidor deberá presentar los certificados raíz e intermedios proporcionados por VCAS. El balanceador de carga de Cardinal comprobará que el certificado del servidor fue firmado por un certificado CA raíz/intermedio en su almacén de confianza. Si no es así, la conexión se terminará; si es así, enviará el certificado del cliente y la clave pública.
    d. El cliente iniciará el intercambio de claves del cliente con la clave pública del cliente y el certificado del cliente. El cliente puede cambiar el conjunto de cifrado si es necesario en esta llamada. El servidor descifrará el mensaje con la clave pública de VCAS.
    e. El cliente enviará un mensaje de "verificación de certificado" que está cifrado con la clave privada del certificado del cliente. Este mensaje puede ser decodificado por el servidor con la clave pública enviada en el paso anterior para la prueba de propiedad. Esto concluye la fase de negociación del cliente. El servidor comprobará que el certificado del cliente fue firmado por un certificado CA raíz/intermedio en su almacén de confianza. Si no es así, terminará la conexión; si es así, descifrará el mensaje de "verificación de certificado" con la clave pública del cliente. En este punto, la validación del servidor / cliente está completa.
    f. El cliente envía un mensaje "terminado" cifrado que el servidor descifrará. Si tiene éxito, pasará al siguiente paso; si no, la conexión se terminará.
    g. El servidor envía un mensaje "Terminado" cifrado que el cliente descifrará. Si tiene éxito, el apretón de manos MTLS está completo.
    h. Los datos de la aplicación se pasan entre el cliente y el servidor.