MTLS (Mutual Transport Layer Security)

Atributos do Certificado MTLS - Nomes importantes

O VCAS irá gerar um certificado usando o Digicert PKI com a seguinte criptografia:

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

Os certificados assinados são válidos por dois anos.

Ativação do MTLS

OAuth2 usa TLS 1.2 para criptografia de mensagens e é uma alternativa ao MTLS, que se autentica com o VCAS através de um certificado. O uso de OAuth e MTLS NÃO é recomendado porque criará autenticação redundante do VCAS antes da transmissão das mensagens.

Etapas para geração de certificado pela primeira vez para novos clientes

O emissor deve:

• Gerar uma chave privada e não a compartilhar com outras partes
• Gerar uma CSR (Solicitação de Assinatura de Certificado) a partir de sua chave privada, incluindo os atributos do certificado e o CN (Nome Comum).
  • Os emissores podem usar a ferramenta de geração de chaves de sua escolha para gerar um par de chaves pública/privada; a força mínima do par de chaves deve ser RSA 2048
  • O Nome Comum (Common Name) no CSR deve corresponder ao nome do endpoint
• Enviar o CSR à Cardinal com um endereço de e-mail (de preferência um e-mail de grupo) para que seja assinado pela CardinalCommerce CA. Use este formato de e-mail para enviar seu CSR

Assim que o emissor enviar o CSR ao VCAS para que seja assinado, então o VCAS irá:

• Atribua o uso da chave e configurar todos os valores necessários
• Revisar e assinar o CSR para criar o certificado público
• Enviar o certificado público assinado de volta ao e-mail fornecido pelo emissor

Se o emissor escolher uma CA terceirizada para assinar seu CSR:

• O emissor precisa enviar ao VCAS uma cópia do certificado público assinado

Expiração do Certificado e Processo de renovação

A Cardinal enviará uma notificação de renovação para o e-mail fornecido pelo parceiro 60 dias antes da expiração do certificado. A notificação conterá um link para enviar um novo CSR para renovar o certificado. As notificações de renovação são enviadas em intervalos de 60, 30, 10, 7 e 1 dia. A geração de chaves para certificados renovados deverá ser feita pelo cliente.

1. O emissor precisará adicionar internamente os endereços de IP do VCAS. Testes serão executados em cada data center para garantir a conectividade.
2. O emissor precisará primeiro criar o endpoint/DNS que será usado para receber as chamadas de API do VCAS descritas acima. Observe que o VCAS não pode aceitar endereços IP. É necessário um URL de caminho completo com um registro DNS disponível globalmente.
3. Depois disso o emissor criará uma solicitação de assinatura de certificado (CSR) para a entrada DNS criada acima. Os parceiros podem usar uma ferramenta de geração de chaves de sua escolha para gerar um par de chaves pública/privada; a força mínima do par de chaves deve ser RSA 2048
4. Depois que o CSR for criado, o emissor poderá enviá-lo usando o link na notificação de renovação ou fornecê-lo ao gerente de implementação do VCAS.
5. A Cardinal retornará um certificado de cadeia completa (contendo certificados raiz, intermediários e de cliente) ao emissor.
6. Este certificado de cadeia completa precisará ser instalado ao endpoint/firewall que está sendo usado para receber as chamadas de API do VCAS.
   Nota: Devido à complexidade e grande variedade de hardwares/softwares de rede, a Cardinal não pode aconselhar sobre a melhor forma de instalar esses certificados nos emissores. É responsabilidade do emissor configurar esses certificados corretamente.
7. Assim que os certificados forem trocados, as conexões MTLS serão estabelecidas entre o cliente (VCAS) e o servidor (rede parceira) para troca de dados da aplicação. Uma conversa MTLS é criada da seguinte forma:
   a. Durante o "olá" inicial, o cliente (VCAS), enviará uma solicitação ao servidor (parceiro) para inicializar a comunicação. Durante o "oi", o VCAS apresentará o conjunto de criptografia e as extensões TLS suportadas.
   b. O servidor responderá com o conjunto de cifras (cipher) confirmadas e as extensões a serem usadas.
   c. O servidor enviará seu certificado de servidor, chave pública, hash e uma solicitação de certificado do cliente. Isso conclui a fase de negociação do lado do servidor. O servidor precisará apresentar os certificados raiz e intermediários fornecidos pelo VCAS. O balanceador de carga do Cardinal verificará se o certificado do servidor foi assinado por um certificado CA intermediário/raiz em seu armazenamento confiável. Caso contrário, a conexão será encerrada; se sim, enviará o certificado do cliente e a chave pública.
   d. O cliente iniciará a troca de chave do cliente com a chave pública do cliente e o certificado do cliente. O cliente pode alterar o conjunto de criptografia se necessário nesta chamada. O servidor irá descriptografar a mensagem com a chave pública do VCAS.
   e. O cliente enviará uma mensagem de “verificação de certificado” criptografada com a chave privada do certificado do cliente. Esta mensagem pode ser decodificada pelo servidor com a chave pública enviada na etapa anterior para comprovação de propriedade. Isso conclui a fase de negociação do cliente. O servidor verificará se o certificado do cliente foi assinado por um certificado CA raiz/intermediário em seu armazenamento confiável. Caso contrário, a conexão será encerrada; se sim, decodificará a mensagem “verificação do certificado” com a chave pública do cliente. Neste ponto, a validação do servidor/cliente está concluída.
   f. O cliente envia uma mensagem criptografada “concluída” que o servidor irá descriptografar. Se tiver sucesso, passará para a próxima etapa; caso contrário, a conexão será encerrada.
   g. O servidor envia uma mensagem criptografada “Concluído” que o cliente irá descriptografar. Se for bem-sucedido, o handshake MTLS será concluído.
   h. Os dados da aplicação são transmitidos entre o cliente e o servidor.