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 dansdnsResourceRecord.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 pourmedia.example.com
,uk.media.example.com
etstaging.media.example.com
, mais pas pourwww.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 champfailure_reason
de la réponse d'API contient la valeurCAA
. - 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'applicationEDGE_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
- Consultez la section Configurer des certificats SSL.
- Assurez-vous de bien comprendre la connectivité client et la compatibilité des protocoles.
- Examinez la façon dont les connexions SSL (TLS) sont établies pour vos origines.