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étodos de configuração de certificado

OGoogle Cloud oferece três métodos de configuração de certificado para balanceadores de carga de aplicativo que usam proxies HTTPS de destino e balanceadores de carga de rede de proxy que usam proxies SSL de destino.

O proxy de destino faz referência aos certificados SSL do Compute Engine: com esse método, o proxy de destino do balanceador de carga pode referenciar até 15 recursos de certificado 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.
O proxy de destino faz referência a um mapa de certificados do Certificate Manager: com esse método, o proxy de destino do balanceador de carga faz referência a um único mapa de certificados. O mapa de certificados é compatível com milhares de entradas por padrão e pode ser escalonado para milhões de entradas. Cada entrada contém dados de chave privada e certificado.
O proxy de destino faz referência direta aos certificados do Certificate Manager: com esse método, o proxy de destino do balanceador de carga pode referenciar até 100 certificados do Certificate Manager.

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 global	Autogerenciado Gerenciado pelo Google	Autogerenciado Gerenciado pelo Google
Balanceador de carga de aplicativo clássico	Autogerenciado Gerenciado pelo Google	Autogerenciado Gerenciado pelo Google
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
Balanceador de carga de aplicativo interno entre regiões			Autogerenciado Gerenciado pelo Google
Balanceadores de carga de rede proxy (proxies SSL de destino)
Balanceador de carga de rede de proxy externo global	Autogerenciado Gerenciado pelo Google	Autogerenciado Gerenciado pelo Google
Balanceador de carga de rede de proxy clássico	Autogerenciado Gerenciado pelo Google	Autogerenciado Gerenciado pelo Google

Regras do método de configuração

OGoogle Cloud aplica as seguintes regras de método de configuração de certificado:

Para balanceadores de carga que oferecem suporte a certificados SSL do Compute Engine e mapas de certificados do Certificate Manager: o proxy de destino do balanceador de carga pode referenciar simultaneamente um mapa de certificados e um ou mais certificados SSL do Compute Engine.

Atenção : quando você usa certificados do Compute Engine e mapas de certificados, todos os certificados SSL do Compute Engine são ignorados e apenas os certificados do mapa de certificados são usados pelo balanceador de carga.
Para balanceadores de carga que aceitam certificados SSL do Compute Engine e certificados do Gerenciador de Certificados anexados diretamente: o proxy de destino do balanceador de carga só pode ser configurado para referenciar até 15 certificados SSL do Compute Engine ou até 100 certificados do Gerenciador de Certificados, não uma combinação de ambos.

Tipos de certificado

OGoogle Cloud aceita certificados autogerenciados e gerenciados pelo Google.

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.
Certificate Manager: para mais informações, consulte Visão geral da implantação na documentação do Certificate Manager.

Certificados SSL gerenciados pelo Google

Os certificados SSL gerenciados pelo Google são aqueles que o Google Cloud recebe, gerencia e renova automaticamente. Os certificados gerenciados pelo Google são de validação de domínio (DV, na sigla em inglês). Eles não comprovam a identidade de uma organização ou indivíduo associado ao certificado.

Os certificados gerenciados pelo Google que usam caracteres curinga só são compatíveis com o Gerenciador de Certificados ao usar a autorização de DNS.

É possível criar certificados SSL gerenciados pelo Google usando:

Recursos de certificado SSL do Compute Engine: somente os recursos globais do Compute Engine sslCertificates são compatíveis com certificados SSL gerenciados pelo Google. Os recursos regionSslCertificates não são compatíveis. Os certificados SSL globais do Compute Engine são compatíveis apenas com certificados gerenciados pelo Google com confiança pública. Para mais informações, consulte Usar certificados SSL gerenciados pelo Google.
Gerenciador de certificados: os certificados do Gerenciador de certificados (globais e regionais) são compatíveis com certificados gerenciados pelo Google com confiança pública e privada. Para mais informações, consulte Certificados na documentação do Certificate Manager.

Tipos de chave compatíveis

Os balanceadores de carga são compatíveis com certificados que usam chaves privadas de diferentes tipos de chave. A tabela a seguir mostra os tipos de chave compatíveis, dependendo se os certificados são globais ou regionais e se são autogerenciados ou gerenciados pelo Google.

Tipo de certificado SSL arrow_forward Tipo de chave arrow_downward	Certificados SSL do Compute Engine			Certificados SSL do Certificate Manager
	Global		Regional	Global e regional
	Autogerenciado	Gerenciado pelo Google e com confiança pública	Autogerenciado	Autogerenciado	Gerenciado pelo Google e com confiança pública	Certificados gerenciados pelo Google com confiança particular
RSA-2048
RSA-3072
RSA-4096
ECDSA P-256
ECDSA P-384

Para saber mais sobre os certificados do Certificate Manager, consulte a documentação do Certificate Manager.

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

Um balanceador de carga de aplicativo ou balanceador de carga de rede de proxy pode hospedar dois ou mais certificados SSL simultaneamente quando o proxy de destino é configurado usando um método de configuração de certificado compatível. Como prática recomendada, use o Gerenciador de Certificados quando vários certificados SSL forem necessários.

Para balanceadores de carga compatíveis com certificados SSL do Compute Engine: o proxy de destino do balanceador de carga 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 balanceadores de carga que aceitam um mapa de certificados do Certificate Manager: o proxy de destino do balanceador de carga faz referência a um único mapa de certificados. O mapa de certificados é compatível com milhares de itens no mapa de certificados. É possível configurar qual entrada de certificado é o certificado padrão (principal) para o mapa de certificados.
Para balanceadores de carga que aceitam referências diretas a certificados do Certificate Manager: o proxy de destino do balanceador de carga pode referenciar até 100 certificados do Certificate Manager. O primeiro recurso de certificado SSL do Certificate Manager 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.
Cotas e limites de recursos na documentação do Gerenciador de Certificados.

Processo de seleção de certificados

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 ou vários certificados do Certificate Manager.

O processo de seleção de certificado será diferente se o proxy de destino de um balanceador de carga fizer referência a um mapa de certificados do Certificate Manager. Para detalhes sobre o processo de seleção de um mapa de certificados, consulte Lógica de seleção de certificados na documentação do Certificate Manager.

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.

Preços

Para saber os preços dos certificados SSL do Compute Engine e do Cloud Load Balancing, consulte Preços de rede: Cloud Load Balancing.

Para saber os preços do Certificate Manager, consulte a página de preços do Certificate Manager.

A seguir

Visão geral do Certificate Manager

Faça um teste

Se você começou a usar o Google Cloudagora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US $300 em créditos para executar, testar e implantar cargas de trabalho.

Comece a usar sem custos financeiros