Edge Security Acceleration:Configure client certificates in the console

Quando usar o mTLS:

• Ambas as partes são entidades controladas, como serviços, dispositivos ou sistemas.

• É necessária uma vinculação de identidade forte e persistente, em vez de tokens temporários.

• Você pode gerenciar centralmente uma Infraestrutura de Chave Pública (PKI), incluindo a CA, a distribuição de certificados e a revogação.

Casos de uso típicos:

1. Autenticação serviço a serviço em microsserviços, como verificação mútua de identidade entre um serviço de pedidos e um de pagamentos. Tecnologias comuns: Istio, Linkerd e Kubernetes.

2. Conexões de gateway de API para origem, como APIs corporativas internas, open banking ou integrações com SaaS de terceiros.

3. Comunicação entre dispositivos IoT e a nuvem.

4. Acesso Zero Trust em redes corporativas, substituindo o modelo tradicional de confiança por VPN.

5. Sistemas financeiros, de pagamento e de saúde que precisam atender aos padrões PCI-DSS, HIPAA ou GDPR.

Quando não usar o mTLS:

• Sites públicos (e-commerce, notícias) acessados por navegadores padrão. O gerenciamento de certificados é impraticável para usuários gerais.

• APIs REST abertas sem requisitos rígidos de identidade. Use OAuth 2.0 ou chaves de API como alternativa.

• Ambientes de teste com baixa segurança. O TLS unidirecional com autenticação básica é mais simples.

Criar um certificado

1. No console do ESA, acesse Websites. Na coluna Website, clique no site desejado.

2. No painel de navegação à esquerda, escolha Client Certificates. Clique em Create Certificate.

3. Selecione um método de CSR Generation, o Private Key Type e a Certificate Validity conforme suas necessidades e clique em OK.

   Importante

   O ESA não armazena o certificado nem a chave privada; portanto, é impossível recuperá-los após o fechamento desta caixa de diálogo. Na caixa de diálogo de visualização do certificado, clique em Copy Certificate e em Copy Private Key para copiar o conteúdo para o seu cliente.

Procedimento

1. Chame a operação UploadClientCaCertificate para enviar seu certificado de CA raiz. Anote o ID do certificado retornado.

2. Chame a operação SetClientCertificateHostnames para vincular o certificado de CA aos hostnames. A validação mTLS aplica-se apenas aos hostnames vinculados.

3. Outras operações de API para certificados mTLS personalizados:

   API	Descrição
   UploadClientCaCertificate	Envia um certificado de CA personalizado.
   ListClientCaCertificates	Lista todos os certificados de CA personalizados enviados.
   DeleteClientCaCertificate	Exclui um certificado de CA personalizado.
   GetClientCaCertificate	Consulta os detalhes de um certificado de CA personalizado específico.
   SetClientCertificateHostnames	Vincula hostnames a um certificado de CA personalizado.
   GetClientCertificateHostnames	Consulta os hostnames vinculados a um certificado de CA personalizado.

Procedimento

1. No console do ESA, acesse Websites. Na coluna Website, clique no site desejado.

2. No painel de navegação à esquerda, escolha SSL/TLS > Client Certificates > Create mTLS Rule para acessar a página de configuração de regras personalizadas.

3. Configure a regra personalizada do WAF.

   • Defina Client Certificate Verified como Desligado .

   • No campo Hostname, insira os hostnames aos quais deseja aplicar a regra.

     Importante

     Configure a condição de hostname. Caso contrário, a regra bloqueará todas as solicitações que não usarem ou falharem na autenticação por certificado de cliente.

4. Defina a Action como Block ou selecione outra ação conforme necessário.

5. Clique em OK para adicionar a regra.

   As solicitações para os hostnames especificados que falharem ou ignorarem a autenticação por certificado de cliente serão bloqueadas com um código de status 403.

Verificação

• Uma solicitação sem certificado de cliente é bloqueada com um código de status 403.

  

• Uma solicitação com um certificado de cliente válido do ESA é bem-sucedida. Substitua o hostname, o caminho do certificado e o caminho da chave pelos seus valores.

  curl -v "https://example.com" --cert ./example.crt --key ./example.key 
  * Trying 198.51.100.10...
  * TCP_NODELAY set
  * Connected to example.com (198.51.100.10) port 443 (#0)
  * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
  * successfully set certificate verify locations:
  * CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
  * TLSv1.2 (OUT), TLS Unknown, Certificate Status (22):
  * TLSv1.2 (OUT), TLS handshake, Client hello (1):
  * TLSv1.2 (IN), TLS handshake, Server hello (2):
  * NPN, negotiated HTTP1.1
  * TLSv1.2 (IN), TLS handshake, Certificate (11):
  * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  * TLSv1.2 (IN), TLS handshake, Request CERT (13):
  * TLSv1.2 (IN), TLS handshake, Server finished (14):
  * TLSv1.2 (OUT), TLS handshake, Certificate (11):
  * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  * TLSv1.2 (OUT), TLS handshake, CERT verify (15):
  * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
  * TLSv1.2 (OUT), TLS handshake, Next protocol (67):
  * TLSv1.2 (OUT), TLS handshake, Finished (20):
  * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
  * TLSv1.2 (IN), TLS handshake, Finished (20):
  * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  * Server certificate:
  * subject: CN=example.com
  * start date: Jul 31 00:00:00 2024 GMT
  * expire date: Jul 31 23:59:59 2025 GMT
  * subjectAltName: host "example.com" matched cert's "example.com"
  * issuer: C=US; O=Example CA; CN=Example DV TLS CA
  * SSL certificate verify ok.
  > GET / HTTP/1.1
  > Host: example.com
  > User-Agent: curl/7.74.0
  > Accept: */*