Visão 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 usados como sinônimos, como neste documento.

O Transport Layer Security (TLS) é usado para criptografar informações enquanto elas são enviadas por uma rede, oferecendo privacidade entre um cliente e um servidor ou balanceador de carga. Um balanceador de carga de aplicativo ou de rede de proxy que usa SSL exige pelo menos uma chave privada e um certificado SSL.

Método de configuração de certificado

Para balanceadores de carga de aplicativo que usam proxies HTTPS de destino, o proxy de destino do balanceador de carga precisa 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 de CA.

Suporte ao balanceador de carga

A tabela a seguir mostra quais métodos de configuração de certificado cada balanceador de carga oferece suporte.

Balanceador de carga Método de configuração de certificado: o proxy de destino faz referência a...
Certificados SSL do Compute Engine Um mapa de certificado do Gerenciador de certificados Diretamente no Gerenciador de certificados
Balanceadores de carga de aplicativo (proxies HTTPS de destino)
Balanceador de carga de aplicativo externo regional Suporta certificados regionais
autogerenciados
gerenciados pelo Google 		Autogerenciamento
Gerenciamento pelo Google
Balanceador de carga de aplicativo interno regional Suporta certificados regionais
autogerenciados
gerenciados pelo Google 		Autogerenciamento
Gerenciamento pelo Google

Tipos de certificado

É possível criar certificados SSL autogerenciados para seus balanceadores de carga.

Certificados SSL autogerenciados

Os certificados SSL autogerenciados são obtidos, provisionados e renovados por você. Os certificados autogerenciados podem ser qualquer um destes tipos de certificado de chave pública:

  • Validação de domínio (DV, na sigla em inglês)
  • Validação da organização (OV, na sigla em inglês)
  • Validação estendida (EV, na sigla em inglês)

É possível criar certificados SSL autogerenciados usando recursos de certificado SSL do Compute Engine. Para mais informações, consulte Usar certificados SSL autogerenciados.

Tipos de chave compatíveis

Os seguintes tipos de chaves são compatíveis com certificados SSL regionais autogerenciados do Compute Engine:

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

Usar certificados com chaves ECDSA

Nesta seção, vamos analisar por que recomendamos o ECDSA em vez do RSA como prática recomendada para chaves de assinatura de certificado.

Qual tipo de chave usar

ECDSA P-256 é a opção recomendada de tipo de chave para a maioria dos certificados TLS, oferecendo segurança criptográfica forte e excelente desempenho para operações de assinatura e uso eficiente da largura de banda da rede.

Confira alguns dos possíveis motivos para usar outros tipos de chaves de certificado:

  • Se você precisar oferecer suporte a clientes legados que não são compatíveis com certificados ECDSA, forneça certificados RSA-2048 além dos certificados ECDSA P-256.
  • Se você tiver requisitos de compliance específicos que exijam o uso de chaves maiores ou tipos específicos, use as chaves ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.

Por que escolher ECDSA em vez de RSA

A principal vantagem do ECDSA é a capacidade de fornecer um nível de segurança criptográfica equivalente com chaves significativamente menores em comparação com o RSA. Essa eficiência se traduz em benefícios tangíveis de desempenho e recursos. Uma chave menor não implica segurança mais fraca. O ECDSA é baseado no problema de logaritmo discreto de curva elíptica, que oferece mais segurança por unidade de chave e, em alguns casos, melhor eficiência computacional em comparação com o RSA.

Exemplo:

  • Uma chave ECDSA de 256 bits oferece um nível de segurança semelhante a uma chave RSA-3072.
  • Uma chave ECDSA de 384 bits oferece um nível de segurança maior do que qualquer tamanho de chave RSA amplamente compatível.

Principais benefícios do ECDSA:

  • Performance: as operações de assinatura ECDSA são significativamente menos intensivas em computação do que as operações RSA, oferecendo um nível de segurança equivalente. Isso reduz a carga da CPU e a latência, o que é crucial para sistemas de alta capacidade ou sensíveis à latência.

  • Eficiência: chaves e assinaturas menores exigem menos largura de banda e armazenamento, o que é especialmente benéfico para ambientes com recursos limitados como dispositivos móveis e de IoT.

Vários certificados SSL

O proxy de destino de um balanceador de carga de aplicativo pode referenciar até 15 certificados SSL do Compute Engine. O primeiro recurso de certificado SSL do Compute Engine referenciado é o certificado padrão (principal) do proxy de destino.

Para mais informações, consulte Proxies de destino e Certificados SSL na documentação de balanceamento de carga.

Processo de seleção de certificado

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

Depois que um cliente se conecta 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 criptografias TLS compatíveis (no ClientHello). O balanceador de carga seleciona um certificado com o algoritmo de chave pública compatível com o cliente. O cliente também pode enviar um nome de host de indicação de nome do servidor (SNI, na sigla em inglês) para o balanceador de carga como parte dessa negociação. Às vezes, os dados do nome do host da SNI são usados para ajudar o balanceador de carga a escolher qual certificado enviar ao cliente.

  • Se o proxy de destino do balanceador de carga referenciar apenas um certificado, esse certificado será usado, e o valor do nome do host SNI enviado pelo cliente não será relevante.

  • Se o proxy de destino do balanceador de carga referenciar dois ou mais certificados, ele usará o seguinte processo para selecionar um único certificado:

    • Se o cliente não enviar nenhum nome de host SNI no ClientHello, o balanceador de carga usará o primeiro certificado na lista.

    • Se o cliente enviar um nome do host SNI que não corresponda a nenhum nome comum de certificado (CN, na sigla em inglês) e não corresponda a nenhum nome alternativo (SAN) do certificado, o balanceador de carga usará o primeiro certificado na lista de certificados.

    • Em todas as outras situações, o balanceador de carga seleciona um certificado usando o seguinte processo de correspondência:

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

      • Para ilustrar o método de correspondência, considere um proxy de destino que referencia os dois certificados a seguir:

        • 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

      • Agora, considere os seguintes cenários:

        • Se o nome do host SNI enviado pelo cliente for cats.pets.example.com, o balanceador de carga usará o certificado A.
        • Se o nome do host SNI enviado pelo cliente for ferrets.pets.example.com, não haverá uma correspondência exata. Portanto, o balanceador de carga selecionará o certificado A ou o certificado B porque ambos incluem *.pets.example.com na lista de SANs. Nessa situação, não é possível controlar qual certificado é selecionado.

  • Depois que um certificado é selecionado, o balanceador de carga envia esse certificado ao cliente somente se o certificado selecionado usar um algoritmo de chave pública compatível com uma criptografia enviada pelo cliente no ClientHello. A negociação de TLS falha se o cliente não for compatível com um pacote de criptografia que inclua o algoritmo de chave pública (ECDSA ou RSA) do certificado selecionado pelo balanceador de carga.

A seguir