Vista geral dos certificados SSL

O SSL/TLS é o protocolo criptográfico mais usado na Internet. Tecnicamente, o TLS é o sucessor do SSL, embora os termos sejam, por vezes, usados alternadamente, como neste documento.

O Transport Layer Security (TLS) é usado para encriptar informações enquanto são enviadas através de uma rede, o que garante a privacidade entre um cliente e um servidor ou um equilibrador de carga. Um balanceador de carga de aplicações ou um balanceador de carga de rede proxy que usa SSL requer, pelo menos, uma chave privada e um certificado SSL.

Método de configuração do certificado

Para balanceadores de carga de aplicações que usam proxies HTTPS de destino, o proxy de destino do balanceador de carga tem de referenciar entre um e 15 certificados SSL do Compute Engine. Cada recurso de certificado SSL do Compute Engine contém a chave privada, o certificado correspondente e, opcionalmente, os certificados da AC.

Apoio técnico do balanceador de carga

A tabela seguinte mostra os métodos de configuração de certificados suportados por cada equilibrador de carga.

Balanceador de carga Método de configuração do certificado: referências... do proxy de destino
Certificados SSL do Compute Engine Um mapa de certificados do Gestor de certificados Certificados do Gestor de certificados diretamente
Balanceadores de carga de aplicações (proxies HTTPS de destino)
Balanceador de carga de aplicações externo regional Suporta certificados regionais
Geridos por si
Geridos pela Google
Gerido por si
Gerido pela Google
Balanceador de carga de aplicações interno regional Suporta certificados regionais
Geridos por si
Geridos pela Google
Gerido por si
Gerido pela Google

Tipos de certificados

Pode criar certificados SSL autogeridos para os seus equilibradores de carga.

Certificados SSL autogeridos

Os certificados SSL autogeridos são certificados que obtém, aprovisiona e renova por si. Os certificados autogeridos podem ser qualquer um destes tipos de certificados de chave pública:

  • Validação de domínio (DV)
  • Validação da organização (OV)
  • Certificados de validação alargada (EV)

Pode criar certificados SSL autogeridos através de recursos de certificados SSL do Compute Engine. Para mais informações, consulte o artigo Use certificados SSL autogeridos.

Tipos de chaves suportados

Os seguintes tipos de chaves são suportados para certificados SSL do Compute Engine autogeridos regionais:

  • RSA-2048
  • RSA-3072
  • RSA-4096
  • ECDSA P-256
  • ECDSA P-384

Use certificados com chaves ECDSA

Esta secção examina o motivo pelo qual recomendamos o ECDSA em vez do RSA como prática recomendada para chaves de assinatura de certificados.

Que tipo de chave usar

O ECDSA P-256 é a escolha recomendada do tipo de chave para a maioria dos certificados TLS, oferecendo uma forte segurança criptográfica juntamente com um excelente desempenho para operações de assinatura e uma utilização eficiente da largura de banda da rede.

Seguem-se alguns dos possíveis motivos para usar outros tipos de chaves de certificados:

  • Se precisar de suportar clientes antigos que não suportam certificados ECDSA, pode fornecer certificados RSA-2048, além de certificados ECDSA P-256.
  • Se tiver requisitos de conformidade específicos que exijam a utilização de tamanhos de chaves maiores ou tipos de chaves específicos, pode usar chaves ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.

Por que motivo deve escolher ECDSA em vez de RSA

A principal vantagem do ECDSA reside na sua capacidade de fornecer um nível de segurança criptográfica equivalente com chaves significativamente mais pequenas em comparação com o RSA. Esta eficiência traduz-se em benefícios tangíveis de desempenho e recursos. Uma chave mais pequena não implica uma segurança mais fraca. A ECDSA baseia-se no problema do logaritmo discreto da curva elíptica, que oferece uma segurança mais forte por unidade de chave e, em alguns casos, uma melhor eficiência computacional em comparação com a RSA.

Por exemplo:

  • Uma chave ECDSA de 256 bits oferece um nível de segurança semelhante ao de uma chave RSA-3072.
  • Uma chave ECDSA de 384 bits oferece um nível de segurança superior ao de qualquer tamanho de chave RSA amplamente suportado.

Principais vantagens do ECDSA:

  • Desempenho: as operações de assinatura ECDSA são significativamente menos intensivas em termos de computação do que as operações RSA, oferecendo um nível de segurança equivalente. Isto reduz a carga da CPU e a latência, o que é fundamental para sistemas de elevado débito ou sensíveis à latência.

  • Eficiência: as chaves e as assinaturas mais pequenas requerem menos largura de banda e armazenamento, o que é especialmente benéfico para ambientes com restrições de recursos, como dispositivos móveis e de IdC.

Vários certificados SSL

O proxy de destino de um Application Load Balancer pode referenciar até 15 certificados SSL do Compute Engine. O primeiro recurso de certificado SSL do Compute Engine referenciado é o certificado predefinido (principal) para o proxy de destino.

Para mais informações, consulte os artigos Proxies de destino e Certificados SSL na documentação de equilíbrio de carga.

Processo de seleção de certificados

O seguinte processo de seleção de certificados aplica-se a equilibradores de carga cujos proxies de destino referenciam vários certificados SSL do Compute Engine.

Depois de um cliente se ligar ao balanceador de carga, o cliente e o balanceador de carga negociam uma sessão TLS. Durante a negociação da sessão TLS, o cliente envia ao balanceador de carga uma lista de cifras TLS suportadas (no ClientHello). O balanceador de carga seleciona um certificado cujo algoritmo de chave pública é compatível com o cliente. O cliente também pode enviar um nome de anfitrião de indicação do nome do servidor (SNI) para o balanceador de carga como parte desta negociação. Por vezes, os dados do nome de anfitrião SNI são usados para ajudar o equilibrador de carga a escolher o certificado que deve enviar para o cliente.

  • Se o proxy de destino do equilibrador de carga referenciar apenas um certificado, esse certificado é usado e o valor do nome de anfitrião SNI enviado pelo cliente não é relevante.

  • Se o proxy de destino do balanceador de carga fizer referência a dois ou mais certificados, o balanceador de carga usa o seguinte processo para selecionar um único certificado:

    • Se o cliente não tiver enviado nenhum nome de anfitrião SNI no respetivo ClientHello, o balanceador de carga usa o primeiro certificado na respetiva lista de certificados.

    • Se o cliente enviar um nome de anfitrião SNI que não corresponda a nenhum nome comum (CN) do certificado e que não corresponda a nenhum nome alternativo de entidade (SAN) do certificado, o balanceador de carga usa o primeiro certificado na respetiva lista de certificados.

    • Em todas as outras situações: o balanceador de carga seleciona um certificado através do seguinte processo de correspondência:

      • A correspondência é feita pelo sufixo mais longo em relação aos atributos do certificado de nome comum (CN) e nome alternativo de entidade (SAN), com uma preferência por certificados ECDSA em vez de certificados RSA.

      • Para ilustrar o método de correspondência, considere um proxy de destino que faz referência aos dois certificados seguintes:

        • Certificado A

          • CN: cats.pets.example.com
          • SANs: cats.pets.example.com, *.pets.example.com, *.example.com
        • Certificado B

          • CN: dogs.pets.example.com
          • SANs: dogs.pets.example.com, *.pets.example.com, *.example.com
      • Considere agora os seguintes cenários:

        • Se o nome de anfitrião SNI enviado pelo cliente for cats.pets.example.com, o equilibrador de carga usa o certificado A.
        • Se o nome de anfitrião SNI enviado pelo cliente for ferrets.pets.example.com, não existe uma correspondência exata, pelo que o equilibrador de carga seleciona o certificado A ou o certificado B porque ambos incluem *.pets.example.com na respetiva lista de SANs. Nesta situação, não pode controlar que certificado é selecionado.
  • Depois de selecionar um certificado, o balanceador de carga envia o certificado ao cliente apenas se o certificado selecionado usar um algoritmo de chave pública compatível com uma cifra enviada pelo cliente no ClientHello. A negociação de TLS falha se o cliente não suportar um conjunto de cifras que inclua o algoritmo de chave pública (ECDSA ou RSA) do certificado que o equilibrador de carga selecionou.

O que se segue?