Certificats SSL (TLS)

Media CDN offre un support de premier ordre pour diffuser du trafic chiffré par TLS (HTTPS) depuis votre propre nom de domaine, mais aussi pour les requêtes signées. Le contenu Media CDN est diffusé à partir de votre propre domaine (domaine Bring-Your-Own ou BYO) et n'est pas nécessairement diffusé à partir d'un domaine hébergé par Google.

  • La diffusion du trafic SSL (TLS) et l'obtention de certificats gérés par Google n'entraînent aucuns frais supplémentaires : la protection du trafic de l'utilisateur final ne doit pas être un luxe.
  • Media CDN est compatible avec les certificats gérés par Google, ce qui permet à Google de gérer la rotation, les clés et la distribution sécurisée sur des milliers de nœuds périphériques, mais aussi avec les certificats autogérés (importés).
  • Chaque service peut accepter jusqu'à cinq certificats SSL.
  • Chaque certificat géré peut avoir jusqu'à 100 noms (noms d'objet alternatifs).

Nous vous recommandons de diffuser votre service de cache périphérique à partir de noms d'hôte dédiés (sous-domaines) et d'utiliser des certificats gérés distincts pour vos domaines multimédias dans le cadre des bonnes pratiques de sécurité.

Créer et émettre des certificats

Pour valider, émettre et associer un certificat SSL (TLS) géré à un service Media CDN, consultez la page Configurer des certificats SSL.

Types de certificat

Media CDN est compatible avec deux types de certificat :

  • Les certificats gérés, que Google peut provisionner en votre nom pour les noms de domaine vous appartenant. Vous n'avez pas besoin de clés sécurisées, et les certificats sont automatiquement renouvelés.
  • Les certificats autogérés, que vous importez directement dans le gestionnaire de certificats. Vous êtes tenu d'importer un certificat valide publiquement approuvé et de le remplacer avant son expiration.

Étant donné que les certificats gérés peuvent être autorisés et émis avant de diriger le trafic vers Media CDN, vous pouvez provisionner les certificats avant de basculer votre trafic de production afin d'éviter les temps d'arrêt.

Dans certains cas, par exemple lorsque vous avez besoin d'épingler des clés dans des applications mobiles ou de prendre en charge des anciens appareils avec des magasins de confiance obsolètes, vous devrez peut-être utiliser des certificats autogérés. Vous pouvez également utiliser des certificats gérés et autogérés sur le même service si vous avez des noms de domaine (hôtes) spécifiques qui nécessitent des certificats autogérés.

Autoriser l'émission de certificats

Si vous souhaitez que vos certificats gérés par Google soient prêts à être utilisés avant la configuration complète de votre environnement de production, par exemple avant de lancer une migration d'un autre fournisseur vers Google Cloud, vous pouvez les provisionner avec des autorisations DNS. Dans ce scénario, le gestionnaire de certificats utilise la validation basée sur DNS. Chaque autorisation DNS stocke des informations sur l'enregistrement DNS que vous devez configurer et couvre un seul domaine et son caractère générique, par exemple, example.com et *.example.com.

Lors de la création d'un certificat géré par Google, vous pouvez spécifier une ou plusieurs autorisations DNS à utiliser pour le provisionnement et le renouvellement de ce certificat. Vous pouvez spécifier la même autorisation DNS dans plusieurs certificats. Les autorisations DNS doivent couvrir tous les domaines spécifiés dans le certificat. Sans cela, la création et le renouvellement des certificats échouent.

La configuration d'une autorisation DNS nécessite l'ajout à votre configuration DNS d'un enregistrement CNAME pour un sous-domaine de validation imbriqué sous votre domaine cible. Cet enregistrement CNAME pointe vers un domaine Google Cloud spécial utilisé par le gestionnaire de certificats pour valider la propriété du domaine.

Au niveau de ce domaine, le gestionnaire de certificats expose un enregistrement TXT généré à partir de l'authentification unique reçue de l'autorité de certification. L'autorité de certification doit pouvoir accéder à cet enregistrement TXT pour terminer la validation de la propriété du domaine. Lorsque vous créez l'autorisation DNS pour le domaine cible, le gestionnaire de certificats renvoie l'enregistrement CNAME correspondant.

L'enregistrement CNAME accorde également des autorisations au gestionnaire de certificats pour le provisionnement et le renouvellement des certificats pour ce domaine dans le projet Google Cloud cible. Pour révoquer ces autorisations, supprimez l'enregistrement CNAME de votre configuration DNS.

Plusieurs domaines par certificat

Les certificats émis par le gestionnaire de certificats vous permettent de spécifier plusieurs noms de domaine (noms d'hôte) sur le même certificat en tant que noms d'objet alternatifs.

Pour ajouter plusieurs domaines à un certificat, spécifiez une liste de domaines lors de la création d'un certificat, ainsi que toutes les autorisations requises.

Chaque autorisation ne couvre que le domaine exact (par exemple, video.example.com) et le caractère générique (*.example.com). L'autorisation ne couvre aucun sous-domaine explicite. Si vous souhaitez obtenir un certificat pour eu.video.example.com, par exemple, vous devez configurer une autre autorisation DNS pour le domaine eu.video.example.com.

Les exemples suivants montrent comment associer une autorisation pour video.example.com et eu.video.example.com :

gcloud

Exécutez la commande 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

Cela crée un certificat avec l'autorisation DNS à l'état AUTHORIZING et le certificat à l'état 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

Les domaines ne peuvent pas partager une autorisation DNS. Vous devez spécifier plusieurs domaines et autorisations. Le gestionnaire de certificats détermine les domaines qui requièrent les autorisations.

Pour en savoir plus sur l'émission et l'activation des certificats, consultez la page Configurer des certificats SSL (TLS).

Renouvellement de certificat

Les certificats gérés sont automatiquement renouvelés par le gestionnaire de certificats. Les certificats renouvelés sont automatiquement envoyés au réseau périphérique mondial de Google pour chaque service actif que vous avez configuré.

  • Afin d'améliorer la sécurité et la conformité, les certificats EDGE_CACHE ont une période de validité courte (30 jours) par rapport à la norme actuelle du secteur de 90 jours (avec un intervalle de renouvellement de 60 jours).
  • Le renouvellement du certificat est généralement initié lorsque le certificat expire dans 10 jours.
  • Aucune action n'est requise de votre part lorsqu'un certificat est renouvelé. Le nouveau certificat remplace automatiquement le certificat existant avant la date d'expiration, sans impact sur votre trafic.

Comme le pipeline d'émission revalide le contrôle du domaine avant le renouvellement, assurez-vous de ne pas supprimer les enregistrements DNS configurés pour l'autorisation DNS. La suppression de l'enregistrement utilisé pour l'authentification DCV (Domain Control Validation) entraîne l'impossibilité de renouveler vos certificats et empêche les clients de se connecter en HTTPS (TLS) une fois le certificat expiré.

Enregistrements CAA et autorités racine

Pour vérifier la compatibilité avec les appareils clients, y compris les Smart TV, smartphones et boîtiers de streaming plus anciens, vous trouverez l'ensemble des autorités de certification racine utilisées par Google sur le site pki.goog.

Pour autoriser le gestionnaire de certificats et Media CDN à émettre des certificats pour un domaine disposant d'enregistrements CAA existants, ajoutez l'enregistrement CAA pki.goog :

DOMAIN_NAME. CAA 0 issue "pki.goog"

Les domaines qui ne possèdent pas d'enregistrements CAA existants n'ont pas besoin d'ajouter cet enregistrement, mais nous vous le recommandons de le faire dans le cadre des bonnes pratiques.

En savoir plus sur les enregistrements CAA

Résoudre les problèmes d'émission de certificats

Les enregistrements DNS non valides ou manquants sont la cause la plus fréquente des échecs d'émission (ou de renouvellement). Dans une telle situation, le gestionnaire de certificats ne peut pas valider la propriété du domaine.

  • Vérifiez que l'enregistrement DNS est accessible via le DNS public. La valeur de l'enregistrement CNAME _acme-challenge (le trait de soulignement est requis) pour votre domaine doit renvoyer la valeur fournie dans dnsResourceRecord.data au moment de la création de l'autorisation. Vous pouvez utiliser le DNS public de Google pour vérifier rapidement que l'enregistrement peut être résolu et est bien valide.
  • Assurez-vous que les domaines pour lesquels vous demandez des certificats correspondent bien aux autorisations (ou sont des sous-domaines) que vous associez à la requête de certificat. Par exemple, une autorisation pour media.example.com vous permet d'émettre des certificats pour media.example.com, uk.media.example.com et staging.media.example.com, mais pas pour www.example.com.
  • Les enregistrements CAA existants sur votre domaine peuvent empêcher le gestionnaire de certificats d'émettre des certificats pour votre domaine. Vous devez vous assurer qu'il existe un enregistrement CAA pour pki.goog afin de permettre à Google de délivrer des certificats pour vos domaines autorisés. Si le problème est dû à une restriction d'enregistrement CAA, le champ failure_reason de la réponse d'API contient la valeur CAA.
  • Vous ne pouvez associer que des certificats dont le champ d'application est EDGE_CACHE à un service de cache périphérique. Si vous n'avez pas spécifié explicitement un champ d'application EDGE_CACHE lors de la création du certificat, vous devez émettre à nouveau le certificat en utilisant une autorisation DNS existante.

Lors de la création d'un certificat avec plusieurs noms de domaine, toute autorisation de domaine non valide empêche l'émission ou le renouvellement du certificat. Cela garantit que tous les domaines demandés sont inclus dans le certificat émis. Assurez-vous que la configuration des enregistrements DNS, du nom de domaine et des enregistrements CAA est valide pour chacun des domaines associés à un certificat.

Motifs d'échec

Le tableau suivant décrit les motifs d'échec pouvant être renvoyés lors de la tentative d'émission d'un certificat et leurs causes, et fournit des suggestions de solutions :

Type Erreur Procédure de dépannage
Autorisation DNS CONFIG Nous n'avons pas pu valider le certificat via DNS. Dans la plupart des cas, cela signifie que l'enregistrement DNS est manquant ou non valide (incorrectement copié), ou que vous essayez d'émettre un certificat pour un sous-domaine qui n'est pas un enfant du domaine autorisé.
Autorisation DNS CAA L'émission d'un certificat est interdite par l'ensemble actuel d'enregistrements CAA [CAA records](/media-cdn/docs/ssl-cerificates#caa-records-roots) associés au domaine. Il est également possible que l'enregistrement CAA ait été mis à jour très récemment.
Autorisation DNS RATE_LIMITED (Inhabituel) Vous émettez peut-être des certificats à une vitesse supérieure à celle acceptée par l'autorité de certification ou le domaine (par exemple, des dizaines par minute ou plus).
Certificate AUTHORIZATION_ISSUE L'autorisation du domaine individuel a échoué. Vérifiez la valeur de managed.authorizationAttemptInfo.failureReason pour le domaine afin de comprendre pourquoi l'autorisation a échoué.

Limites des certificats

Vous pouvez émettre jusqu'à 1 000 certificats gérés et 1 000 autorisations DNS par projet. Pour connaître les autres limites et quotas associés, consultez la documentation Quotas et limites.

Versions TLS compatibles

Media CDN est compatible avec les versions TLS suivantes, qui correspondent à la configuration de règle SSL COMPATIBLE.

Version TLS Compatible Algorithmes de chiffrement inclus
SSL 3.0 Non N/A (non compatible)
TLS 1.0 ✔ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS 1.1 ✔ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS 1.2 ✔ 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

De plus :

  • Les appareils qui ne sont pas compatibles avec les versions modernes de TLS (telles que TLS 1.3) négocient automatiquement une version TLS compatible (à condition qu'il n'existe pas de version minimale définie).
  • TLS 1.0 et TLS 1.1 sont activés par défaut pour permettre la plus grande compatibilité possible avec les appareils.
  • Media CDN n'est pas compatible avec l'association de règles SSL à un service.

Étapes suivantes