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

Nesta página, fornecemos instruções para criar um certificado raiz e um certificado intermediário assinado e fazer upload desses certificados para um recurso TrustConfig do Gerenciador de certificados. Se você já tiver certificados para fazer upload, pule as etapas a seguir para criar novos certificados.

Você também cria os recursos de segurança de rede necessários para configurar o TLS mútuo (mTLS) para balanceadores de carga de aplicativos. Nas instruções, usamos o OpenSSL para criar os certificados raiz e intermediários.

Antes de começar

• Leia a Visão geral do TLS mútuo.
• Consulte 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ê não executou a gcloud CLI anteriormente, primeiro execute o comando gcloud init para autenticar.

• Ative as APIs: API Compute Engine, API Certificate Manager, API Network Security e API Network Services.

• 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

• Definir o projeto.

  gcloud

  gcloud config set project PROJECT_ID
  

Observação: não é possível usar o Console do Google Cloud para configurar os recursos de autenticação do cliente (ServerTLSPolicy) e TrustConfig. Em vez disso, use a gcloud CLI.

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 TargetHTTPSProxy: 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.

Gere uma chave e certificados assinados

Observação: se você já tem certificados para enviar, pule esta etapa e vá para Formatar os certificados.

Esta seção usa comandos openssl para criar certificados raiz e intermediários.

Use os comandos a seguir para gerar um certificado raiz e um certificado intermediário assinado com campos keyUsage e extendedKeyUsage válidos.

1. Crie um arquivo de amostra example.cnf com a configuração mínima necessária para criar certificados de assinatura válidos. É possível editar esse arquivo para definir campos adicionais nesses certificados.

   cat > example.cnf << EOF
   [req]
   distinguished_name = empty_distinguished_name
   [empty_distinguished_name]
   # Kept empty to allow setting via -subj command line arg.
   [ca_exts]
   basicConstraints=critical,CA:TRUE
   keyUsage=keyCertSign
   extendedKeyUsage=clientAuth
   EOF
   

2. Crie o certificado raiz.

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=root' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout root.key -out root.cert
   

3. Crie a solicitação de assinatura do certificado intermediário.

   openssl req \
       -new -sha256 -newkey rsa:2048 -nodes \
       -subj '/CN=int' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout int.key -out int.req
   

4. Crie o certificado intermediário.

   openssl x509 -req \
       -CAkey root.key -CA root.cert \
       -set_serial 1 \
       -days 3650 \
       -extfile example.cnf \
       -extensions ca_exts \
       -in int.req -out int.cert
   

Gerar um certificado e adicioná-lo a uma lista de permissões

Observação: se você já tem certificados para enviar, pule esta etapa e vá para Formatar os certificados.

Esta seção usa comandos openssl para criar um certificado de exemplo e adicioná-lo a uma lista de permissões.

Use os comandos abaixo para gerar um certificado e adicioná-lo a uma lista de permissões.

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=localhost' \
       -keyout allowlisted.key -out allowlisted.cert

Formatar os certificados

Para incluir certificados novos ou atuais em um TrustStore, formate os certificados em uma única linha e armazene-os em variáveis de ambiente para que possam ser lidos no arquivo YAML. Use os seguintes comandos para formatar os certificados e armazená-los em variáveis de ambiente:

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

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

Para incluir certificados novos ou atuais adicionados a uma lista de permissões em uma configuração de confiança, formate os certificados em uma única linha e armazene-os em variáveis de ambiente para que possam ser lidos no arquivo YAML. Para certificados que estão em uma lista de permissões, use o comando abaixo para formatar os certificados em uma única linha e armazená-los na variável de ambiente ALLOWLISTED_CERT.

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

Criar um recurso TrustConfig

Crie um recurso TrustConfig do Gerenciador de certificados que represente sua ICP. Este exemplo de recurso TrustConfig contém um armazenamento de confiança com duas âncoras de confiança e dois certificados de CA intermediários. Ele lê o conteúdo do certificado das variáveis de ambiente criadas na etapa anterior Formatar os certificados.

Para criar um repositório de confiança com âncoras de confiança adicionais ou certificados de CA intermediários, adicione linhas de pemCertificate na seção apropriada. Se você tiver menos âncoras de confiança ou certificados de CA intermediários, remova as linhas desnecessárias.

Este exemplo de recurso TrustConfig contém um certificado que é adicionado a uma lista de permissões. É possível especificar vários certificados em uma lista de permissões usando várias instâncias do campo pemCertificate.

Nas etapas a seguir, substitua TRUST_CONFIG_NAME pelo nome do recurso TrustConfig:

1. Para criar o arquivo trust_config.yaml com um repositório de confiança, use o seguinte comando:

   cat << EOF > trust_config.yaml
   trustStores:
   - trustAnchors:
     - pemCertificate: "${ROOT_CERT?}"
     - pemCertificate: "${ROOT_CERT_2?}"
     intermediateCas:
     - pemCertificate: "${INTERMEDIATE_CERT?}"
     - pemCertificate: "${INTERMEDIATE_CERT_2?}"
   EOF
   

2. Opcional: para criar o arquivo trust_config.yaml com um certificado adicionado a uma lista de permissões, use o seguinte comando:

   cat << EOF >> trust_config.yaml
   allowlistedCertificates:
   - pemCertificate: "${ALLOWLISTED_CERT?}"
   EOF
   

3. Para criar os recursos TrustConfig do Gerenciador de certificados, use o comando gcloud certificate-manager trust-configs import:

   global

   Para balanceadores de carga de aplicativo externos e balanceadores de carga de aplicativo internos entre regiões, use este comando:

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

   regional

   Use este comando para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais:

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

Criar os recursos 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 TrustConfig 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 o recurso ServerTLSPolicy, conclua as etapas a seguir:

1. Com base em como você quer lidar com a conexão, selecione uma das opções a seguir.

   Nas etapas a seguir, substitua SERVER_TLS_POLICY_NAME pelo nome da política de TLS do servidor e PROJECT_ID pelo ID do projeto do Google Cloud.

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

     Para criar o arquivo server_tls_policy.yaml, use o seguinte comando:

     global

     Para balanceadores de carga de aplicativo externos e internos entre regiões, use o comando:

     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

     Use o comando para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais:

     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.

     Para criar o arquivo server_tls_policy.yaml, use o seguinte comando:

     global

     Para balanceadores de carga de aplicativo externos e internos entre regiões, use o comando:

     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

     Use o comando para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais:

     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
     

2. Para criar o recurso ServerTlsPolicy, use o comando gcloud network-security server-tls-policies import:

   global

   Para balanceadores de carga de aplicativo externos e internos entre regiões, use o comando:

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

   regional

   Use o comando para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais:

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

3. Opcional: liste todos os recursos de autenticação do cliente (ServerTlsPolicies) no local especificado do projeto atual.

   Console

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

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

   2. Todos os recursos ServerTlsPolicies serão exibidos.

   gcloud

   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=REGION
   

   Substitua:

   REGION: use global 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. 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 ServerTlsPolicy, primeiro é necessário excluir o recurso ServerTlsPolicy existente e depois criar um novo recurso ServerTlsPolicy. Em seguida, aplique a nova política ao proxy HTTPS de destino do balanceador de carga. Para mais informações, consulte Configurar o mTLS para o balanceador de carga.

Configurar o mTLS para o balanceador de carga

Para que a autenticação TLS mútua funcione, depois de configurar um balanceador de carga, você precisa atualizar o proxy HTTPS de destino usando o recurso ServerTLSPolicy.

1. Verifique se você já criou o recurso de autenticação do cliente (ServerTLSPolicy). Para instruções, consulte Criar os recursos de autenticação do cliente.

2. Para listar todos os proxies 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.

3. 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 de um arquivo 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 de um arquivo yaml. Por exemplo, mtls_target_proxy.yaml
   • REGION: a região em que você configurou o balanceador de carga.

4. Liste todos os recursos ServerTlsPolicies no local especificado do projeto atual.

   Console

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

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

   2. Todos os recursos ServerTlsPolicies serão exibidos.

   gcloud

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

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

   Substitua:

   REGION: use global 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. 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 ServerTlsPolicies para configurar o mTLS. Esse nome será chamado de SERVER_TLS_POLICY_NAME na próxima etapa.

5. Para adicionar ao final o arquivo de recurso ServerTlsPolicy TARGET_PROXY_FILENAME, use o comando a seguir. Substitua PROJECT_ID pelo ID do projeto do Google Cloud.

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

6. 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 de um arquivo 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 de um arquivo 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}"
   

Assinar uma chave de cliente com o certificado intermediário

Nesta seção, fornecemos uma opção de configuração adicional para gerar um certificado de folha. Se você já criou um recurso TrustConfig usando certificados intermediários (int.cert e int.key), use as instruções a seguir:

1. Crie um arquivo de configuração de chave de cliente.

   Observação: se a chave for usada em um servidor, será possível adicionar o campo serverAuth ao campo extendedKeyUsage.

   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              = [e-mail]
   
   EOF
   

   Se você quiser ter uma identidade SPIFFE anexada:

   • Adicione um subjectAltName à seção [extension_requirements] conforme a seguir:

     subjectAltName            = @sans_list
     

   • Adicione uma nova seção na parte de baixo do arquivo client.config com isto:

     [sans_list]
     URI.1                     = spiffe://example.com/test-identity
     

2. Assine a chave.

   openssl req -new -keyout client.key -out client.csr -config client.config
   
   openssl x509 -req -in client.csr -out client.cert -extfile client.config -extensions extension_requirements -days 365 -CA int.cert -CAkey int.key
   

3. Para testar, envie uma solicitação curl para o endereço IP do balanceador de carga.

   curl -v -k --key client.key --cert client.cert https://IP_ADDRESS
   

   Substitua IP_ADDRESS pelo endereço IP do balanceador de carga.

A seguir

• Configurar o TLS mútuo com uma CA particular