O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

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 às vezes 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 balanceador de carga de rede de proxy que usa SSL requer pelo menos uma chave privada e um certificado SSL.

Nesta página, falamos sobre certificados SSL e criptografia em trânsito entre um balanceador de carga de aplicativo ou balanceador de carga de rede de proxy que usa SSL e os clientes dele. Para detalhes sobre a criptografia em trânsito entre o balanceador de carga do Google Cloud e os back-ends dele, consulte Criptografia para os back-ends.

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 são compatíveis com cada balanceador de carga.

Balanceador de carga	Método de configuração de certificado
Balanceador de carga	Certificados SSL do Compute Engine	Gerenciador de certificados (mapa de certificados)	Gerenciador de certificados (certificados individuais)
Balanceadores de carga de aplicativo (proxies HTTPS de destino)
Balanceador de carga de aplicativo externo regional	Autogerenciado Gerenciado pelo Google		Autogerenciado Gerenciado pelo Google
Balanceador de carga de aplicativo interno regional	Autogerenciado Gerenciado pelo Google		Autogerenciado Gerenciado 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 conseguidos, 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 chave 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, analisamos 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 é o tipo de chave recomendado para a maioria dos certificados TLS, oferecendo segurança criptográfica forte, 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 chave 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 tamanhos de chave maiores ou tipos de chave específicos, use as chaves ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.

Por que escolher o ECDSA em vez do 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 em uma segurança mais fraca. O ECDSA é baseado no problema do logaritmo discreto de curva elíptica, que oferece uma segurança mais forte 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 ao de 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 aceito.

Principais benefícios 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 que oferecem 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 de processamento 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 certificados

O processo de seleção de certificado a seguir se aplica a balanceadores de carga com proxies de destino que fazem referência a 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 fizer referência a 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 fizer referência a dois ou mais certificados, o balanceador de carga usará o seguinte processo para selecionar um único certificado:
- Se o cliente não tiver enviado nenhum nome de host SNI no ClientHello, o balanceador de carga usará o primeiro certificado na lista de certificados.
- 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 com os atributos de certificado de nome comum (CN, na sigla em inglês) e nome alternativo do sujeito (SAN, na sigla em inglês). Se apenas um certificado corresponder ao nome do host SNI, o balanceador de carga selecionará esse certificado. Se vários certificados corresponderem ao nome do host SNI, o balanceador de carga os priorizará na seguinte ordem:
    - Correspondência exata do nome do host: as correspondências exatas com o CN ou o SAN têm precedência sobre as correspondências de caracteres curinga.
    - Correspondência de nome do host com caractere curinga: se não houver uma correspondência exata, o balanceador de carga verificará se há uma correspondência de CN ou SAN com caractere curinga. Um caractere curinga (*) corresponde apenas ao subdomínio de primeiro nível (por exemplo, *.pets.example.com corresponde a cats.pets.example.com, e não a *.example.com).
    - Tipo de chave de certificado: os certificados ECDSA são preferíveis aos certificados RSA.
    - Tamanho da cadeia de certificados: se vários certificados tiverem a mesma especificidade de correspondência e o mesmo algoritmo de chave pública, o balanceador de carga priorizará o certificado com o menor tamanho de cadeia de certificados (em bytes) para minimizar a largura de banda da rede durante o handshake de TLS.
  - Para ilustrar o método de correspondência, considere um proxy de destino que referencie 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á correspondência exata, e os certificados A e B vão corresponder a *.pets.example.com na lista de SANs. Se os dois certificados usarem o mesmo algoritmo de chave pública, o balanceador de carga selecionará o certificado com o menor tamanho de cadeia de certificados. Se os tamanhos das cadeias de certificados também forem idênticos, o balanceador de carga vai selecionar o Certificado A ou o Certificado B, e não será possível controlar qual certificado será selecionado.
Depois que um certificado é selecionado, o balanceador de carga o envia 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 falhará 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.