Certificados SSL (TLS)

A RFC de conteúdo multimédia tem suporte de primeira classe para publicar tráfego encriptado com TLS (HTTPS) a partir do seu próprio nome de domínio, bem como suporte para pedidos assinados. A RFC de conteúdo multimédia é publicada a partir do seu próprio domínio (Bring-Your-Own ou domínio BYO) e não tem de ser publicada a partir de um domínio alojado pela Google.

  • Não existem custos adicionais associados à publicação de tráfego SSL (TLS) ou à obtenção de certificados geridos pela Google: a proteção do tráfego do utilizador final não deve ser premium.
  • A RFC 5280 define os formatos de certificado X.509.
  • Cada serviço pode suportar até 5 certificados SSL.
  • Cada certificado gerido pode ter até 100 nomes (nomes alternativos do requerente).

Recomendamos que publique o seu serviço de cache na extremidade a partir de nomes de anfitrião (subdomínios) dedicados e que use certificados geridos separados para os seus domínios de multimédia como uma boa prática de segurança.

Crie e emita certificados

Para validar, emitir e anexar um certificado SSL (TLS) gerido a um serviço do Media CDN, consulte o artigo Configurar certificados SSL.

Tipos de certificados

A RFC de multimédia suporta dois tipos de certificados:

  • Certificados geridos, que a Google pode aprovisionar em seu nome para nomes de domínio que lhe pertencem. Não precisa de chaves seguras e os certificados são renovados automaticamente.
  • Certificados autogeridos, que carrega diretamente para o Gestor de certificados. É responsável por carregar um certificado válido e publicamente fidedigno, bem como substituir o certificado antes da respetiva data de validade.

Uma vez que os certificados geridos podem ser autorizados e emitidos antes de direcionar o tráfego para a CDN de multimédia, pode aprovisionar certificados antes de transferir o tráfego de produção e evitar o tempo de inatividade.

Em alguns casos, como quando precisa de fixação de chaves em aplicações para dispositivos móveis ou suporte para dispositivos antigos com repositórios de confiança desatualizados, pode ter de usar certificados autogeridos. Também pode usar certificados geridos e autogeridos no mesmo serviço se tiver nomes de domínios específicos (anfitriões) que exijam certificados autogeridos.

Autorizar a emissão de certificados

A autorização de DNS permite-lhe validar a propriedade do domínio e aprovisionar certificados geridos pela Google, mesmo antes de o ambiente de produção estar totalmente configurado. Esta opção é particularmente útil quando está a migrar certificados para o Google Cloud.

O Gestor de certificados valida a propriedade do domínio através de registos de DNS. Cada autorização de DNS armazena informações sobre um registo de DNS e abrange um único domínio e o respetivo caráter universal (por exemplo, myorg.example.com e *.myorg.example.com). Um caráter universal abrange apenas o primeiro nível de subdomínio e não abrange níveis de subdomínio mais profundos. Por exemplo, *.myorg.example.com não abrange sub.subdomain.myorg.example.com.

Quando cria um certificado gerido pela Google, pode usar uma ou mais autorizações de DNS para aprovisionar e renovar certificados. Se tiver vários certificados para um único domínio, pode usar a mesma autorização de DNS para todos os certificados. No entanto, as suas autorizações de DNS têm de abranger todos os domínios indicados no certificado. Caso contrário, a criação e a renovação de certificados falham.

Para configurar a autorização de DNS, tem de adicionar um registo CNAME à configuração de DNS. Pode usar este registo para validar o subdomínio no seu domínio de destino. O registo CNAME aponta para um domínio Google Cloud especial que o Gestor de certificados usa para validar a propriedade do seu domínio. Quando cria uma autorização de DNS, o Gestor de certificados devolve este registo CNAME e valida a sua propriedade.

Lembre-se de que o registo CNAME também concede ao Gestor de certificados a autorização para aprovisionar e renovar certificados para o domínio de destino no seu projetoGoogle Cloud . Para revogar estas autorizações, remova o registo CNAME da configuração do DNS.

Autorização de DNS por projeto

A autorização de DNS por projeto permite-lhe gerir certificados de forma independente em cada Google Cloud projeto. Com a autorização de DNS por projeto, o Gestor de Certificados pode emitir e processar certificados para cada projeto separadamente. As autorizações e os certificados DNS usados num projeto são autónomos e não interagem com artefactos de outros projetos.

Para ativar a autorização de DNS por projeto, escolha a opção PER_PROJECT_RECORD quando criar uma autorização de DNS. Em seguida, recebe um registo CNAME único que inclui um subdomínio e um destino específico desse projeto. Deve adicionar este registo CNAME à zona de DNS do domínio relevante.

Vários domínios por certificado

Os certificados emitidos pelo Certificate Manager permitem-lhe especificar vários nomes de domínios (nomes de anfitriões) no mesmo certificado como nomes alternativos do requerente.

Pode adicionar vários domínios a um certificado especificando uma lista de domínios quando cria um certificado, bem como todas as autorizações correspondentes necessárias.

Cada autorização abrange apenas o domínio exato (por exemplo, video.example.com) e o caráter universal (*.example.com). Não abrange subdomínios explícitos. Se quiser um certificado para eu.video.example.com, por exemplo, tem de configurar outra autorização de DNS para o domínio eu.video.example.com.

Os exemplos seguintes mostram como anexar uma autorização para video.example.com e eu.video.example.com:

gcloud

Use o comando gcloud certificate-manager certificates:

gcloud certificate-manager certificates create video-example-com \
    --domains="video.example.com,eu.video.example.com" \
    --dns-authorizations="video-example-com-auth,eu-video-example-com-auth" \
    --scope=EDGE_CACHE

Isto cria um certificado com a autorização de DNS no estadoAUTHORIZING e o certificado no estado PROVISIONING:

managed:
authorizationAttemptInfo:
- domain: video.example.com
  state: AUTHORIZED
dnsAuthorizations:
- projects/123456/locations/global/dnsAuthorizations/video-example-com-auth
- projects/123456/locations/global/dnsAuthorizations/eu-video-example-com-auth
domains:
- video.example.com
state: PROVISIONING
scope: EDGE_CACHE
subjectAlternativeNames:
- video.example.com

Os domínios não podem partilhar uma autorização de DNS. Tem de especificar vários domínios e autorizações. O Gestor de certificados determina que domínios requerem que autorizações.

Para saber como os certificados são emitidos e ativados, consulte o artigo Configure certificados SSL (TLS).

Renovação do certificado

Os certificados geridos são renovados automaticamente pelo Gestor de certificados. Os certificados renovados são enviados automaticamente para a rede global da Google para cada serviço ativo que configurou.

  • Os certificados EDGE_CACHE têm um período de validade curto (30 dias) para melhorar a segurança e a conformidade, em comparação com a norma atual da indústria de 90 dias (com um intervalo de renovação de 60 dias).
  • Normalmente, a renovação do certificado é iniciada quando faltam 10 dias para a respetiva expiração.
  • Não tem de tomar medidas quando um certificado é renovado. O novo certificado substitui automaticamente o certificado existente antes da data de validade, sem qualquer impacto no seu tráfego em direto.

Uma vez que o pipeline de emissão revalida o controlo do domínio antes da renovação, certifique-se de que não elimina os registos de DNS configurados para autorização de DNS. A eliminação do registo usado para demonstrar a DCV (validação do controlo do domínio) resulta na incapacidade de renovar os seus certificados e impede que os clientes estabeleçam ligação através de HTTPS (TLS) quando o certificado expira.

Registos e raízes de CAA

Para verificar a compatibilidade com dispositivos cliente, incluindo smart TVs, smartphones e caixas de streaming mais antigos, pode encontrar o conjunto completo de ACs raiz que a Google usa em pki.goog.

Para permitir que o Certificate Manager e a rede de CDN de multimédia emitam certificados para um domínio com registos CAA existentes, adicione o registo CAA:pki.goog

DOMAIN_NAME. CAA 0 issue "pki.goog"

Os domínios que não têm registos CAA existentes não precisam de adicionar este registo, mas recomendamos que o façam como prática recomendada.

Leia mais sobre os registos CAA.

Limites de certificados

Pode emitir até 1000 certificados geridos e 1000 autorizações de DNS por projeto. Para outros limites e quotas relacionados, consulte a documentação Quotas e limites .

Versões de TLS compatíveis

A RFC 5246 (TLS 1.2) é a versão mínima suportada.

Versão de TLS Suportado Cifras incluídas
SSL 3.0 Não N/A (não suportado)
TLS 1.0 Não N/A (não suportado)
TLS 1.1 Não N/A (não suportado)
TLS 1.2 ✔ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384
TLS 1.3 ✔ TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256

Além disso:

  • Os dispositivos que não suportam versões modernas do TLS (como o TLS 1.3) negociam automaticamente uma versão do TLS suportada.
  • O TLS 1.2 é a versão de TLS mínima suportada para a CDN de multimédia.
  • A RFC de multimédia não suporta a anexação de políticas SSL a um serviço.

Resolva problemas de emissão de certificados

Se tiver algum erro com a emissão de certificados, veja como resolver problemas de emissão de certificados.

O que se segue?