Configurar o TLS mútuo com uma CA particular

Nesta página, fornecemos instruções para criar uma autoridade de certificação (CA, na sigla em inglês) particular usando o Certificate Authority Service e fazendo upload dos certificados para um recurso TrustConfig do Gerenciador de certificados.

Você também cria os recursos de segurança de rede necessários para configurar o TLS mútuo para balanceadores de carga de aplicativos.

Antes de começar

• Leia a Visão geral do TLS mútuo.

• Instale a Google Cloud CLI. Para uma visão geral completa da ferramenta, consulte Visão geral da CLI gcloud. Encontre os comandos relacionados ao balanceamento de carga na referência da CLI gcloud e da API.

  Se você ainda não executou a CLI gcloud, primeiro execute gcloud init para autenticar.

• Verifique se você sabe criar pools de CA.

• Se você estiver usando o balanceador de carga de aplicativo externo global ou o balanceador de carga de aplicativo clássico, verifique se configurou um balanceador de carga com um dos seguintes back-ends compatíveis:

  • Back-ends de grupo de instâncias de VM
  • Buckets do Cloud Storage (compatíveis somente se houver pelo menos um serviço de back-end também anexado ao balanceador de carga, além do bucket de back-end)
  • Funções do Cloud Run, App Engine ou Cloud Run functions
  • Conectividade híbrida

• Se você estiver usando o balanceador de carga de aplicativo externo regional, o balanceador de carga de aplicativo interno entre regiões ou o balanceador de carga de aplicativo interno regional, verifique se configurou um balanceador de carga com um dos seguintes back-ends compatíveis:

  • Back-ends de grupo de instâncias de VM
  • Cloud Run
  • Conectividade híbrida

Permissões

Para ter as permissões necessárias para concluir este guia, peça ao administrador para conceder a você os papéis do IAM a seguir no projeto:

• Para criar recursos do balanceador de carga, como TargetHTTPProxy: Administrador do balanceador de carga do Compute (roles/compute.loadBalancerAdmin)
• Para usar os recursos do Gerenciador de certificados: Proprietário do Gerenciador de certificados (roles/certificatemanager.owner)
• Para criar componentes de segurança e rede: Administrador de rede do Compute (roles/compute.networkAdmin) e Administrador de segurança do Compute (roles/compute.securityAdmin)
• Para criar um projeto (opcional): Criador de projetos (roles/resourcemanager.projectCreator)

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias por meio de papéis personalizados ou de outros papéis predefinidos.

Observação: os papéis básicos do IAM também podem conter permissões para concluir este guia. Não conceda papéis básicos em um ambiente de produção, mas é possível fazer isso em um ambiente de desenvolvimento ou teste.

Criar uma AC raiz no pool de ACs

Para criar uma CA raiz no pool de CAs particular, siga estas etapas:

1. Para criar um pool de CAs, use o comando gcloud privateca pools create:

   gcloud privateca pools create CA_POOL \
      --location=us-central1
   

   Substitua CA_POOL pelo ID ou nome do pool de CAs pai.

2. Para criar uma AC raiz no pool de ACs, use o comando gcloud privateca roots create:

   gcloud privateca roots create CA_ROOT \
      --pool=CA_POOL \
      --subject="CN=my-ca, O=Test LLC" \
      --location=us-central1
   

   Substitua:

   • CA_ROOT: o ID ou o nome da AC raiz.
   • CA_POOL: o ID ou nome do pool de ACs pai.

3. Para descrever o novo CA e criar o arquivo root.cert, use o comando gcloud privateca roots describe:

   gcloud privateca roots describe CA_ROOT \
      --pool=CA_POOL \
      --location=us-central1 \
      --format='value(pemCaCertificates)' > root.cert
   

   Substitua:

   • CA_ROOT: o ID ou nome da AC particular.
   • CA_POOL: o ID ou nome do pool de ACs pai.

4. Formate o certificado em uma única linha e armazene-o em uma variável de ambiente para que ele possa ser referenciado pelo arquivo YAML de configuração de confiança.

   export ROOT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

   Para ver mais informações, consulte os seguintes tópicos:

   • Criar um pool de CA
   • Criar um CA raiz

Criar um recurso de configuração de confiança

Uma configuração de confiança é um recurso que representa a configuração da infraestrutura de chave pública (ICP) no Gerenciador de certificados.

Para criar um recurso de configuração de confiança, siga estas etapas:

Console

1. No console do Google Cloud, acesse a página Gerenciador de certificados.

   Acessar o Gerenciador de certificados

2. Na guia Configurações de confiança, clique em Adicionar configuração de confiança.

3. Insira um nome para a configuração.

4. Em Local, selecione Global ou Regional.

   O local indica onde o recurso de configuração de confiança é armazenado. Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, crie um recurso de configuração de confiança global. Para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais, crie um recurso de configuração de confiança regional.

   Se você tiver selecionado Regional, escolha a região.

5. Na seção Repositório de confiança, clique em Adicionar âncora de confiança e faça upload do arquivo de certificado codificado em PEM ou copie o conteúdo do certificado.

6. Clique em Adicionar.

7. Clique em Criar.

Verifique se o novo recurso de configuração de confiança aparece na lista de configurações.

gcloud

1. Crie um arquivo YAML de configuração de confiança (trust_config.yaml) que especifique os parâmetros de configuração de confiança. Neste exemplo, o recurso de configuração de confiança é um armazenamento de confiança com uma única âncora de confiança que representa um certificado raiz. Esse certificado raiz é gerado usando a AC particular.

   cat << EOF > trust_config.yaml
   name: TRUST_CONFIG_NAME
   trustStores:
   - trustAnchors:
       - pemCertificate: "${ROOT?}"
   EOF
   

2. Para importar o arquivo YAML de configuração de confiança, use o comando gcloud certificate-manager trust-configs import:

   global

   Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, especifique global como o local em que o recurso de configuração de confiança é armazenado.

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
       --source=trust_config.yaml \
       --location=global
   

   Substitua:

   • TRUST_CONFIG_NAME: o nome do recurso de configuração de confiança.

   regional

   Para balanceadores de carga de aplicativo externos e internos regionais, especifique a região em que o recurso de configuração de confiança está armazenado.

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
       --source=trust_config.yaml \
       --location=LOCATION
   

   Substitua:

   • TRUST_CONFIG_NAME: o nome do recurso de configuração de confiança.
   • LOCATION: a região em que o recurso de configuração de confiança é armazenado. O local padrão é global.

Criar um recurso de autenticação do cliente

Um recurso de autenticação do cliente (também chamado de ServerTLSPolicy) permite especificar o modo TLS do lado do servidor e o recurso de configuração de confiança a ser usado ao validar certificados do cliente. Quando o cliente apresenta um certificado inválido ou nenhum certificado para o balanceador de carga, o clientValidationMode especifica como a conexão do cliente é processada. Para mais informações, consulte Modos de validação do cliente mTLS.

• Quando clientValidationMode é definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT, todas as solicitações são transmitidas para o back-end, mesmo que a validação falhe ou o certificado do cliente esteja ausente.
• Quando clientValidationMode for definido como REJECT_INVALID, somente as solicitações que fornecerem um certificado de cliente que possa ser validado por um recurso TrustConfig serão transmitidas para o back-end.

Para criar um recurso de autenticação do cliente (ServerTlsPolicy), siga estas etapas:

Console

1. No console do Google Cloud, acesse a página Autenticação do cliente.

   Acesse a página "Autenticação do cliente"

2. Clique em Criar autenticação de cliente.

3. Insira um nome para o recurso de autenticação do cliente.

4. Em Local, selecione Global ou Regional.

   Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, defina o local como global. Para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo regionais internos, defina o local como a região em que o balanceador de carga está configurado.

5. Em Modo de autenticação do cliente, selecione Balanceamento de carga.

6. Selecione um modo de validação do cliente.

7. Selecione o recurso de configuração de confiança criado anteriormente.

8. Clique em Criar.

Verifique se a autenticação do cliente (ServerTlsPolicy) aparece.

gcloud

1. Com base em como você quer lidar com a conexão, selecione uma das seguintes opções para definir o recurso de autenticação do cliente (ServerTlsPolicy) no formato YAML.

   • Opção 1: clientValidationMode está definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

     global

     Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, crie um arquivo YAML que especifique de forma declarativa o modo de validação do cliente e um recurso de configuração de confiança global:

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
         clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
         clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

     regional

     Para balanceadores de carga de aplicativo externos e internos regionais, crie um arquivo YAML que especifique de forma declarativa o modo de validação do cliente e um recurso de configuração de confiança regional:

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
         clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
         clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

   • Opção 2: clientValidationMode está definido como REJECT_INVALID.

     global

     Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, crie um arquivo YAML que especifique de forma declarativa o modo de validação do cliente e um recurso de configuração de confiança global:

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
         clientValidationMode: REJECT_INVALID
         clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

     regional

     Para balanceadores de carga de aplicativo externos e internos regionais, crie um arquivo YAML que especifique de forma declarativa o modo de validação do cliente e um recurso de configuração de confiança regional:

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
           clientValidationMode: REJECT_INVALID
           clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

     Substitua:

     SERVER_TLS_POLICY_NAME: o nome do recurso de autenticação do cliente (ServerTlsPolicy).

     PROJECT_ID: o ID do seu projeto do Google Cloud.

     LOCATION: para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, use global. Para o balanceador de carga de aplicativo externo regional ou o balanceador de carga de aplicativo interno regional, use a região em que você configurou o balanceador de carga

     TRUST_CONFIG_NAME: o nome do recurso de configuração de confiança criado anteriormente.

2. Para importar o recurso ServerTlsPolicy de autenticação do cliente, use o comando gcloud network-security server-tls-policies import:

   global

   Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, defina a flag --location como global.

   gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
     --source=server_tls_policy.yaml \
     --location=global
   

   Substitua:

   SERVER_TLS_POLICY_NAME: o nome do recurso de autenticação do cliente (ServerTlsPolicy).

   regional

   Para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais, defina a flag --location para a região em que o balanceador de carga está configurado.

   gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
     --source=server_tls_policy.yaml \
     --location=LOCATION
   

   Substitua:

   SERVER_TLS_POLICY_NAME: o nome do recurso de autenticação do cliente (ServerTlsPolicy).

3. Opcional: para listar todos os recursos de autenticação do cliente (ServerTlsPolicies), use o comando gcloud network-security server-tls-policies list:

   gcloud network-security server-tls-policies list \
     --location=LOCATION
   

   Substitua:

   LOCATION: para balanceadores de carga de aplicativo externos globais, clássicos e internos entre regiões, use global. Para o balanceador de carga de aplicativo externo regional ou o balanceador de carga de aplicativo interno regional, use a região em que você configurou o balanceador de carga.

Observação: para modificar o recurso de autenticação do cliente (ServerTlsPolicy), primeiro é necessário excluir o recurso de autenticação do cliente e criar um novo. Em seguida, anexe o recurso de autenticação do cliente ao proxy HTTPS de destino do balanceador de carga.

Anexar o recurso de autenticação do cliente ao balanceador de carga

Para que a autenticação TLS mútua funcione, depois de configurar o balanceador de carga, você precisa anexar o recurso de autenticação do cliente (ServerTLSPolicy) ao recurso de proxy HTTPS de destino do balanceador de carga.

Console

1. No Console do Google Cloud, acesse a página Balanceamento de carga.

   Acessar o "Balanceamento de carga"

2. Na lista de balanceadores de carga, selecione o balanceador de carga ao qual você precisa anexar o recurso de autenticação do cliente (ServerTLSPolicy).

3. Clique em Editar.

4. Na seção Configuração de front-end de um front-end HTTPS, expanda a seção Mostrar recursos avançados.

5. Na lista Autenticação do cliente, selecione o recurso de autenticação do cliente.

6. Clique em Concluído.

7. Clique em Atualizar.

gcloud

1. Para listar todos os recursos de proxy HTTPS de destino no projeto, use o comando gcloud compute target-https-proxies list:

   gcloud compute target-https-proxies list
   

   Anote o nome do proxy HTTPS de destino para anexar o recurso ServerTLSPolicy. Esse nome é chamado de TARGET_HTTPS_PROXY_NAME nas etapas a seguir.

2. Para exportar a configuração de um proxy HTTPS de destino para um arquivo, use o comando gcloud compute target-https-proxies export.

   global

     gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
         --destination=TARGET_PROXY_FILENAME \
         --global
     

   Substitua:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML. Por exemplo, mtls_target_proxy.yaml.

   regional

   gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
       --destination=TARGET_PROXY_FILENAME \
       --region=REGION
   

   Substitua:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML. Por exemplo, mtls_target_proxy.yaml
   • REGION: a região em que você configurou o balanceador de carga.

3. Para listar todos os recursos de autenticação do cliente (ServerTlsPolicy), use o comando gcloud network-security server-tls-policies list:

   gcloud network-security server-tls-policies list \
       --location=LOCATION
   

   Substitua:

   LOCATION: para o balanceador de carga de aplicativo interno entre regiões, o balanceador de carga de aplicativo externo global ou o balanceador de carga de aplicativo clássico, use global. Para o balanceador de carga de aplicativo externo regional ou o balanceador de carga de aplicativo interno regional, use a região em que você configurou o balanceador de carga.

   Anote o nome do recurso de autenticação do cliente (ServerTLSPolicy) para configurar o mTLS. Esse nome será chamado de SERVER_TLS_POLICY_NAME na próxima etapa.

4. Anexe a autenticação do cliente (ServerTlsPolicy) ao proxy HTTPS de destino.

   echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> TARGET_PROXY_FILENAME

   Substitua:

   • PROJECT_ID: o ID do seu projeto do Google Cloud.
   • LOCATION: para balanceadores de carga de aplicativo externos globais ou clássicos e balanceadores de carga de aplicativo internos entre regiões, use global. Para o balanceador de carga de aplicativo externo regional ou o balanceador de carga de aplicativo interno regional, use a região em que você configurou o balanceador de carga.
   • SERVER_TLS_POLICY_NAME: o nome do recurso de autenticação do cliente (ServerTLSPolicy).
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML.

5. Para importar a configuração de um proxy HTTPS de destino de um arquivo, use o comando gcloud compute target-https-proxies import.

   global

     gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
         --source=TARGET_PROXY_FILENAME \
         --global
     

   Substitua:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML. Por exemplo, mtls_target_proxy.yaml.

   regional

     gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
         --source=TARGET_PROXY_FILENAME \
         --region=REGION
     

   Substitua:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML. Por exemplo, mtls_target_proxy.yaml
   • REGION: a região em que você configurou o balanceador de carga.

Adicionar cabeçalhos personalizados mTLS

Ao ativar o mTLS, é possível transmitir informações sobre a conexão mTLS usando cabeçalhos personalizados. Você também pode ativar o registro para que as falhas de conexão do mTLS sejam capturadas nos registros.

Adicionar cabeçalhos personalizados do mTLS aos serviços de back-end

Para balanceadores de carga de aplicativo externos globais ou clássicos, use cabeçalhos personalizados para transmitir informações sobre a conexão do mTLS para os serviços de back-end.

1. Para listar todos os serviços de back-end no projeto, use o comando gcloud compute backend-services list:

   gcloud compute backend-services list
   

   Anote o nome do serviço de back-end para ativar os cabeçalhos e a geração de registros personalizados. Esse nome é chamado de BACKEND_SERVICE na etapa a seguir.

2. Para atualizar o serviço de back-end, use o comando gcloud compute backend-services update:

   gcloud compute backend-services update BACKEND_SERVICE \
     --global \
     --enable-logging \
     --logging-sample-rate=1 \
     --custom-request-header='X-Client-Cert-Present:{client_cert_present}' \
     --custom-request-header='X-Client-Cert-Chain-Verified:{client_cert_chain_verified}' \
     --custom-request-header='X-Client-Cert-Error:{client_cert_error}' \
     --custom-request-header='X-Client-Cert-Hash:{client_cert_sha256_fingerprint}' \
     --custom-request-header='X-Client-Cert-Serial-Number:{client_cert_serial_number}' \
     --custom-request-header='X-Client-Cert-SPIFFE:{client_cert_spiffe_id}' \
     --custom-request-header='X-Client-Cert-URI-SANs:{client_cert_uri_sans}' \
     --custom-request-header='X-Client-Cert-DNSName-SANs:{client_cert_dnsname_sans}' \
     --custom-request-header='X-Client-Cert-Valid-Not-Before:{client_cert_valid_not_before}' \
     --custom-request-header='X-Client-Cert-Valid-Not-After:{client_cert_valid_not_after}'
   

Observação:

É possível colocar seus próprios nomes de cabeçalho personalizados. Os nomes usados nas opções --custom-request-header são apenas exemplos.

É possível ativar alguns ou todos os cabeçalhos personalizados mTLS.

Adicionar cabeçalhos personalizados do mTLS ao mapa de URL

Para balanceadores de carga de aplicativo internos entre regiões, balanceadores de carga de aplicativo externos regionais ou balanceadores de carga de aplicativo internos regionais, é possível usar cabeçalhos personalizados para transmitir informações sobre a conexão do mTLS para o mapa de URL.

Para listar todos os mapas de URL no projeto, use o comando gcloud compute url-maps list:

   gcloud compute url-maps list
   

Anote o nome do mapa de URL para ativar cabeçalhos personalizados e geração de registros. Esse nome é chamado de URL_MAP_NAME na etapa a seguir.

global

Para editar o mapa de URL de um balanceador de carga de aplicativo interno entre regiões, use o comando gcloud compute url-maps edit:

   gcloud compute url-maps edit URL_MAP_NAME --global
   

Veja a seguir um exemplo de arquivo YAML que mostra como usar variáveis em cabeçalhos de solicitações personalizadas (requestHeadersToAdd). É possível usar as mesmas variáveis para enviar cabeçalhos de resposta personalizados (responseHeadersToAdd).

   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"
   

regional

Para editar o mapa de URL de um balanceador de carga de aplicativo externo regional ou um balanceador de carga de aplicativo interno regional, use o comando gcloud compute url-maps edit:

   gcloud compute url-maps edit URL_MAP_NAME --region=REGION
   

Veja a seguir um exemplo de arquivo YAML que mostra como usar variáveis em cabeçalhos de solicitações personalizadas (requestHeadersToAdd). É possível usar as mesmas variáveis para enviar cabeçalhos de resposta personalizados (responseHeadersToAdd).

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: regional-lb-map
      region: region/REGION
   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"
   

A seguir

• Configurar o TLS mútuo com certificados assinados