Certificados SSL (TLS)

Media CDN es compatible con la entrega de tráfico encriptado con TLS (HTTPS) desde tu propio nombre de dominio, además de compatibilidad con solicitudes firmadas. El contenido multimedia de CDN se entrega desde tu propio dominio (Usa tu propia propiedad o BYO) y no es necesario que lo entregue desde un dominio alojado en Google.

  • No hay cargos adicionales asociados con la entrega de tráfico SSL (TLS) o la obtención de certificados administrados por Google: la protección del tráfico del usuario final no debe ser prémium.
  • Media CDN admite certificados administrados por Google, lo que permite a Google administrar la rotación, las claves y la distribución segura a miles de nodos perimetrales, además de los certificados autoadministrados (subidos).
  • Cada servicio puede admitir hasta 5 certificados SSL.
  • Cada certificado administrado puede tener hasta 100 nombres (nombres alternativos del sujeto).

Te recomendamos entregar tu servicio de caché perimetral desde nombres de host dedicados (subdominios) y usar certificados administrados independientes para tus dominios de medios, como una buena práctica de seguridad.

Crea y emite certificados

Para validar, emitir y adjuntar un certificado SSL administrado (TLS) a un servicio de Media CDN, consulta Configura certificados SSL.

Tipos de certificados

Media CDN admite dos tipos de certificados:

  • Certificados administrados, que Google puede aprovisionar en tu nombre para los nombres de dominio de tu propiedad. No necesitas claves seguras y los certificados se renuevan de forma automática.
  • Certificados autoadministrados, que se suben directamente al administrador de certificados. Eres responsable de subir un certificado válido de confianza pública y de reemplazar el certificado antes de su vencimiento.

Debido a que los certificados administrados se pueden autorizar y emitir antes de dirigir el tráfico a Media CDN, puedes aprovisionar certificados antes de reducir el tráfico de producción y evitar el tiempo de inactividad.

En algunos casos, como cuando necesitas fijar claves en aplicaciones para dispositivos móviles o con la compatibilidad con dispositivos heredados con almacenes de confianza desactualizados, es posible que debas usar certificados autoadministrados. También puedes usar certificados administrados y autoadministrados en el mismo servicio si tienes nombres de dominio (hosts) específicos que requieran certificados autoadministrados.

Autoriza la emisión del certificado

Si deseas que tus certificados administrados por Google estén listos para usarse antes de que tu entorno de producción esté completamente configurado, por ejemplo, antes de iniciar una migración de otro proveedor a Google Cloud, puedes aprovisionarlos con DNS. autorizaciones. En esta situación, el administrador de certificados usa una validación basada en DNS. Cada autorización de DNS almacena información sobre el registro DNS que debes configurar y abarca un solo dominio, además de su comodín, por ejemplo, example.com y *.example.com.

Cuando creas un certificado administrado por Google, puedes especificar una o más autorizaciones de DNS para usar en el aprovisionamiento y la renovación de ese certificado. Puedes especificar la misma autorización de DNS en varios certificados. Las autorizaciones de DNS deben abarcar todos los dominios especificados en el certificado. de lo contrario, la creación y la renovación del certificado fallan.

Si deseas configurar una autorización de DNS, debes agregar un registro CNAME para un subdominio de validación anidado en tu dominio de destino a tu configuración de DNS. Este registro CNAME apunta a un dominio especial de Google Cloud que el administrador de certificados usa para verificar la propiedad del dominio.

En este dominio, el administrador de certificados expone un registro TXT generado a partir del desafío único que recibió de la CA. La CA debe poder acceder a este registro TXT para completar la verificación de la propiedad del dominio. Cuando creas la autorización de DNS para el dominio de destino, el Administrador de certificados muestra el registro CNAME correspondiente.

El registro CNAME también otorga permisos de administrador de certificados para el aprovisionamiento y la renovación de certificados de ese dominio dentro del proyecto de destino de Google Cloud. Para revocar estos permisos, quita el registro CNAME de tu configuración de DNS.

Varios dominios por certificado

Los certificados emitidos por el administrador de certificados te permiten especificar varios nombres de dominio (nombres de host) en el mismo certificado que los Nombres alternativos de entidad.

Puedes agregar varios dominios a un certificado si especificas una lista de dominios cuando creas un certificado, así como cualquier autorización coincidente que se requiera.

Cada autorización solo cubre el dominio exacto (por ejemplo, video.example.com) y el comodín (*.example.com). No abarca ningún subdominio explícito. Si deseas un certificado para eu.video.example.com, por ejemplo, debes configurar otra autorización de DNS para el dominio eu.video.example.com.

En los siguientes ejemplos, se muestra cómo adjuntar una autorización para video.example.com y eu.video.example.com:

gcloud

Usa el 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

Esto crea un certificado con la autorización de DNS en el estado AUTHORIZING y el certificado en el 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

Los dominios no pueden compartir una autorización de DNS. Debes especificar varios dominios y autorizaciones. El Administrador de certificados determina qué dominios requieren qué autorizaciones.

Para obtener información sobre cómo se emiten y activan los certificados, consulta Configura certificados SSL (TLS).

Renovación del certificado

El administrador de certificados renueva automáticamente los certificados administrados. Los certificados actualizados se envían de forma automática al perímetro global de Google para cada servicio activo que hayas configurado.

  • Los certificados EDGE_CACHE tienen un período de validez corto (30 días) para mejorar la seguridad y el cumplimiento, en comparación con el estándar actual de la industria de 90 días (con un intervalo de renovación de 60 días).
  • Por lo general, la renovación del certificado se inicia cuando el certificado tiene 10 días de caducidad.
  • No es necesario realizar ninguna acción cuando se renueva un certificado. El certificado nuevo reemplaza de forma automática el certificado existente antes de la fecha de vencimiento, sin afectar su tráfico en vivo.

Debido a que la canalización de emisión vuelve a validar el control del dominio antes de la renovación, asegúrate de no borrar los registros DNS configurados para la autorización DNS. Borrar el registro que se usa para demostrar el DCV (validación del control de dominio) da como resultado la incapacidad de renovar tus certificados y evita que los clientes se conecten a través de HTTPS (TLS) cuando el certificado vence.

Registros y raíces de CAA

Para verificar la compatibilidad con dispositivos cliente, incluidos los televisores inteligentes, los smartphones y los decodificadores más antiguos, puedes encontrar el conjunto completo de CA raíz que usa Google en pki.goog.

Para permitir que el Administrador de certificados y la CDN de medios emitan certificados para un dominio con registros de CAA existentes, agrega el registro de CAA pki.goog:

DOMAIN_NAME. CAA 0 issue "pki.goog"

Los dominios que no tienen registros de CAA existentes no necesitan agregar este registro, pero recomendamos hacerlo.

Obtén más información sobre los registros de CAA.

Solucionar problemas relacionados con la emisión de certificados

La causa más común de la emisión con errores (o la renovación) se debe a registros DNS no válidos o faltantes, que impiden que el Administrador de certificados valide la propiedad del dominio.

  • Comprueba que se pueda acceder al registro DNS a través de DNS público. El valor del registro CNAME _acme-challenge (el guion bajo es obligatorio) para tu dominio debe mostrar el valor proporcionado en el dnsResourceRecord.data desde el momento en que creaste la autorización. Puedes usar el DNS público de Google para verificar con rapidez que el registro se pueda resolver y sea válido.
  • Asegúrate de que los dominios a los que solicitas certificados coincidan, o son subdominios de, las autorizaciones que asocias a la solicitud de certificado. Por ejemplo, una autorización para media.example.com te permite emitir certificados para media.example.com, uk.media.example.com y staging.media.example.com, pero no www.example.com,
  • Los registros de CAA existentes en tu dominio podrían evitar que el Administrador de certificados emita certificados para tu dominio. Debes asegurarte de que haya un registro CAA para pki.goog que permita que Google emita certificados para tus dominios autorizados. Si el problema se debe a una restricción del registro CAA, el campo failure_reason en la respuesta de la API contiene un valor de CAA.
  • Solo puedes adjuntar certificados con el alcance EDGE_CACHE a un servicio de caché perimetral. Si no especificaste de forma explícita un permiso de EDGE_CACHE cuando creaste el certificado, debes volver a emitirlo con una autorización de DNS existente.

Cuando se crea un certificado con varios nombres de dominio, cualquier autorización de dominio no válida evita que el certificado se emita o renueve. Esto garantiza que todos los dominios solicitados se incluyan en el certificado emitido. Asegúrate de que el registro DNS, el nombre de dominio y la configuración del registro CAA sean válidos para cada uno de los dominios asociados con un certificado.

Motivo de la falla

En la siguiente tabla, se describen los motivos de falla que pueden mostrarse cuando se intenta emitir un certificado, sus causas y las correcciones sugeridas:

Tipo Error Pasos para solucionar problemas
Autorización de DNS CONFIG No pudimos validar el certificado mediante DNS. En la mayoría de los casos, esto significa que falta el registro DNS, no es válido (se copió de forma incorrecta) o intentas emitir un certificado para un subdominio que no es secundario del dominio autorizado.
Autorización de DNS CAA La emisión del certificado está prohibida por el conjunto actual de [registros de CAA](/media-cdn/docs/ssl-cerifytes#caa-records-roots) asociados con el dominio o es posible que el registro de CAA solo haya sido actualizadas.
Autorización de DNS RATE_LIMITED (Es poco frecuente) puedes emitir certificados a una velocidad más rápida que la que acepta la CA o el dominio (por ejemplo, decenas por minuto o más).
Certificado AUTHORIZATION_ISSUE No se pudo autorizar el dominio individual. Verifica el valor de managed.authorizationRetryInfo.failureReason del dominio para comprender por qué falló la autorización.

Límites de certificados

Puedes emitir hasta 1,000 certificados administrados y 1,000 autorizaciones de DNS por proyecto. Para conocer otros límites y cuotas, consulta la documentación Cuotas y límites.

Versiones de TLS compatibles

Media CDN es compatible con las siguientes versiones de TLS, que coinciden con la configuración COMPATIBLE de la política de SSL.

Versión de TLS Se admite Algoritmos de cifrado incluidos
SSL 3.0 No N/A: No admitido
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

Además, ten en cuenta lo siguiente:

  • Los dispositivos que no admiten versiones modernas de TLS (como TLS 1.3) negocian de forma automática una versión compatible de TLS (siempre que no haya un conjunto de versiones mínimo).
  • TLS 1.0 y TLS 1.1 están habilitados de forma predeterminada para habilitar la compatibilidad de dispositivos más amplia.
  • La CDN de medios no admite la conexión de políticas de SSL a un servicio.

¿Qué sigue?