Esta página foi traduzida pela API Cloud Translation.

Configurar o mTLS do frontend com uma CA particular

Um certificado de cliente válido precisa mostrar uma cadeia de confiança de volta à âncora de confiança no repositório de confiança. Nesta página, fornecemos instruções para criar sua própria cadeia de confiança usando o certificado raiz de uma CA (autoridade certificadora) particular, que está sob seu controle. Nesta configuração, a CA particular é criada usando o Certificate Authority Service.

Depois de receber o certificado raiz da CA particular, este documento descreve o processo para fazer upload do certificado para o repositório de confiança do recurso TrustConfig do Gerenciador de certificados. Em seguida, vincule a configuração de confiança ao recurso de autenticação do cliente (ServerTLSPolicy) e anexe esse recurso ao proxy HTTPS de destino do balanceador de carga.

Antes de começar

Leia a Visão geral do TLS mútuo.
Consulte o guia para Gerenciar configurações de confiança.
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.
Consulte o guia para criar um pool de CAs.
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.

Acessar o certificado da CA raiz

A CA raiz tem um certificado autoassinado que precisa ser adicionado ao repositório de confiança. O certificado da CA raiz está na parte superior da cadeia de certificados.

Para receber o certificado da CA raiz, primeiro crie um pool de CA, que fica vazio na criação. Em seguida, crie uma CA raiz e adicione-a ao pool de CAs. A CA raiz e o pool de CAs são criados usando o Certificate Authority Service, conforme descrito nas etapas a seguir.

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.
Para criar uma CA raiz e adicioná-la ao pool de CAs, 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 nome da CA raiz.
- CA_POOL: o ID ou nome do pool de ACs principal.
Extraia o certificado codificado por PEM que identifica a CA raiz.
```
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 CA particular.
- CA_POOL: o ID ou nome do pool de ACs principal.
O certificado raiz (root.cert) precisa ser enviado para o repositório de confiança. Essa etapa será realizada na seção a seguir.

Para mais informações sobre como usar o Certificate Authority Service para criar um pool de ACs e uma AC raiz, consulte o seguinte:

Formatar o certificado de CA raiz

Para incluir o certificado raiz em um repositório de confiança, formate o certificado em uma única linha e armazene-o em uma variável de ambiente para que 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')

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

No console Google Cloud , acesse a página Certificate Manager.

Acessar o Gerenciador de certificados
Na guia Configurações de confiança, clique em Adicionar configuração de confiança.
Insira um nome para a configuração.
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.
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.
Clique em Adicionar.
Clique em Criar.

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

gcloud

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 CA particular.
```
cat << EOF > trust_config.yaml
name: TRUST_CONFIG_NAME
trustStores:
- trustAnchors:
    - pemCertificate: "${ROOT?}"
EOF
```
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 está 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 regionais e balanceadores de carga de aplicativo 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 está 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 do 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

No console Google Cloud , acesse a página Configuração de autenticação.

Acessar "Configuração de autenticação"
Na guia Autenticação do cliente, clique em Criar.
Insira um nome para o recurso de autenticação do cliente.
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 internos regionais, defina o local como a região em que o balanceador de carga está configurado.
Em Modo de autenticação do cliente, selecione Balanceamento de carga.
Selecione um modo de validação do cliente.
Selecione o recurso de configuração de confiança que você criou antes.
Clique em Criar.

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

gcloud

Com base em como você quer lidar com a conexão, selecione uma das opções a seguir 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 regionais e balanceadores de carga de aplicativo 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 regionais e balanceadores de carga de aplicativo 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 Google Cloud projeto.
  
  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 que você criou anteriormente.
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 internos regionais, defina a flag --location como 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).
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, 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 interno regional, use a região em que você configurou o 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

No console Google Cloud , acesse a página Balanceamento de carga.

Acessar o "Balanceamento de carga"
Na lista de balanceadores de carga, selecione aquele a que você precisa anexar o recurso de autenticação do cliente (ServerTLSPolicy).
Clique em Editar.
Na seção Configuração de front-end de um front-end HTTPS, expanda a seção Mostrar recursos avançados.
Na lista Autenticação do cliente, selecione o recurso de autenticação do cliente.
Clique em Concluído.
Clique em Atualizar.

gcloud

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.
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 no 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 no formato YAML. Por exemplo, mtls_target_proxy.yaml
- REGION: a região em que você configurou o balanceador de carga.
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.
Adicione 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 Google Cloud projeto.
- 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 no formato YAML.
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 no 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 no 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.

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.

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}'

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

   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}"

Receber um certificado do cliente usando uma CSR

Nesta seção, fornecemos uma opção de configuração adicional para gerar um certificado de cliente (folha) assinado pelo certificado da CA raiz.

Para receber um certificado de cliente, gere uma solicitação de assinatura de certificado (CSR) e envie para o pool de CAs.

Crie um arquivo de configuração do OpenSSL para gerar a CSR do certificado do cliente.

O arquivo de configuração a seguir (client.config) contém a seção [extension_requirements], que especifica as extensões X.509 a serem incluídas na CSR. Para saber mais sobre os requisitos para certificados do cliente, consulte Requisitos de certificado.

cat > client.config << EOF
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = critical, CA:FALSE
keyUsage                  = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage          = clientAuth

[dn_requirements]
countryName               = US
stateOrProvinceName       = California
localityName              = San Francisco
0.organizationName        = example
organizationalUnitName    = test
commonName                = test.example.com
emailAddress              = test@example.com

EOF

Execute o comando openssl a seguir para gerar uma CSR (csr.pem) e uma chave privada correspondente (key.pem).
```
openssl req -newkey rsa:2048 -nodes \
    -config client.config \
    -keyout key.pem \
    -out csr.pem
```
Execute o seguinte comando gcloud privateca certificates create para enviar a CSR e solicitar o certificado do cliente X.509 da CA no pool de CA.
```
gcloud privateca certificates create \
     --issuer-pool CA_POOL \
     --issuer-location=us-central1 \
     --csr csr.pem \
     --cert-output-file CERT_FILENAME
```
Substitua:
- CA_POOL: o ID ou nome do pool de ACs.
- CERT_FILENAME: o arquivo de cadeia de certificados codificado em PEM ordenado da folha à raiz.
Envie uma solicitação HTTPS segura para o endereço IP do balanceador de carga usando o certificado SSL do lado do cliente. O cliente apresenta o certificado para se autenticar no balanceador de carga.
```
curl -v --key key.pem --cert CERT_FILENAME https://IP_ADDRESS
```
Substitua:
- CERT_FILENAME: o arquivo de cadeia de certificados codificado em PEM, ordenado da folha à raiz.
- IP_ADDRESS: o endereço IP do balanceador de carga.

A seguir

Configurar o TLS mútuo com certificados fornecidos pelo usuário

Configurar o mTLS do frontend com uma CA particular Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Permissões

Acessar o certificado da CA raiz

Formatar o certificado de CA raiz

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

Console

gcloud

global

regional

Criar um recurso de autenticação do cliente

Console

gcloud

global

regional

global

regional

global

regional

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

Console

gcloud

global

regional

global

regional

Adicionar cabeçalhos personalizados mTLS

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

Adicionar cabeçalhos personalizados do mTLS ao mapa de URL

global

regional

Receber um certificado do cliente usando uma CSR

A seguir

Configurar o mTLS do frontend com uma CA particular