El Administrador de certificados usa un mecanismo de asignación flexible que te proporciona un control detallado sobre los certificados que puedes asignar y cómo entregarlos para cada nombre de dominio de tu entorno. El mecanismo incluye las siguientes entidades:
- Certificados
- Mapas de certificados
- Entradas del mapa de certificados
- Autorizaciones de dominio
En el siguiente diagrama, se ilustran las relaciones entre estas entidades para un proxy de destino típico especificado en una regla de reenvío del balanceador de cargas:
El Administrador de certificados admite proxies HTTPS de destino y proxies SSL de destino. Para obtener más información sobre las diferencias entre estos tipos de proxy, consulta Usa proxies de destino.
Para obtener información sobre los tipos de certificados que admite el Administrador de certificados, consulta Descripción general de la implementación.
Certificados
De forma predeterminada, un certificado representa un único certificado SSL de seguridad de la capa de transporte (TLS) X.509 que se emite para comodines de dominio o nombres de dominio específicos.
El Administrador de certificados admite los siguientes tipos de certificados:
- Los certificados administrados por Google son certificados que Google Cloud obtiene y administra por ti.
- Los certificados autoadministrados son certificados que obtienes, aprovisionas y renuevas tú mismo.
Cuando emites un certificado con una AC de confianza pública, la AC publica información sobre el dominio asociado en los registros de Certificado de transparencia, que son de acceso público. Esto forma parte del proceso estándar de emisión de certificados adoptado por todas las AC de confianza pública y se aplica a los certificados administrados por Google y a los autoadministrados. Sin embargo, si usas Certificate Authority Service para emitir el certificado administrado por Google, el Administrador de certificados no publicará información en los registros de Certificado de transparencia.
Para obtener más información, consulta Certificado de transparencia.
Para aprender a implementar un certificado con el Administrador de certificados, consulta Descripción general de la implementación.
Certificados administrados por Google
Administrar certificados TLS (SSL) administrados por Google para tus sitios web y aplicaciones puede ser una tarea compleja y lenta que, a menudo, implica configuración manual y mantenimiento regular. El Administrador de certificados es un servicio diseñado para optimizar este proceso a través de una plataforma centralizada. Puedes delegar la responsabilidad de emitir y renovar certificados al Administrador de certificados, lo que liberará tu tiempo para enfocarte en otras tareas críticas.
Puedes verificar la propiedad del dominio relevante con una autorización basada en un balanceador de cargas o una basada en DNS. El Administrador de certificados admite certificados RSA administrados por Google.
De forma predeterminada, la AC de Google emite certificados administrados por Google. Cuando se emite o se renueva un nuevo certificado administrado por Google, se usa una clave privada recién generada. Si no puedes obtener un certificado de la AC de Google para un dominio en particular, el Administrador de certificados recurre a la AC Let's Encrypt. Por ejemplo, es posible que la AC de Google rechace emitir un certificado para el dominio o que tu registro de autorización de AC impida de forma explícita que la AC de Google emita certificados para ese dominio.
No se admite la autenticación solo para el cliente.
Si quieres obtener instrucciones para restringir las AC que pueden emitir certificados para tus dominios, consulta Especifica las AC que pueden emitir tu certificado administrado por Google.
Ten en cuenta que los certificados regionales administrados por Google (versión preliminar) solo admiten autorizaciones basadas en DNS y obtienen certificados de la AC de Google.
Certificados administrados por Google emitidos por Certificate Authority Service
Si deseas usar tu propia cadena de confianza en lugar de depender de AC públicas aprobadas por Google para emitir tus certificados, puedes configurar el Administrador de certificados para usar un grupo de AC de Certificate Authority Service como el emisor del certificado. Para obtener más información sobre los grupos de AC, consulta Cómo crear grupos de AC.
Certificados autoadministrados
Si tus requisitos empresariales no te permiten usar certificados administrados por Google, puedes subir certificados emitidos por AC externas junto con sus claves asociadas. Eres responsable de emitir y renovar de forma manual los certificados autoadministrados.
El Administrador de certificados también te permite implementar certificados autoadministrados regionales en proxies de proxy web seguro y balanceadores de cargas regionales.
Mapas de certificados
Un mapa de certificados hace referencia a una o más entradas del mapa de certificados que asignan certificados específicos a nombres de host determinados. Las entradas del mapa de certificados también definen la lógica de selección que sigue el balanceador de cargas cuando se establecen conexiones con los clientes. Puedes asociar un mapa de certificados con varios proxies de destino para volver a usarlo en varios balanceadores de cargas.
Si un cliente solicita un nombre de host especificado en un mapa de certificados, el balanceador de cargas entrega los certificados asignados a ese nombre de host. De lo contrario, el balanceador de cargas entrega el certificado principal. Para obtener más información, consulta Lógica de selección de certificados.
Entradas del mapa de certificados
Una entrada del mapa de certificados es una lista de certificados entregados para un nombre de dominio específico. Puedes definir diferentes conjuntos de certificados para distintos nombres de dominio, como dominios o subdominios. Por ejemplo, puedes subir un certificado ECDSA y RSA, y asignarlos al mismo nombre de dominio. Cuando un cliente se conecta a ese nombre de dominio, el balanceador de cargas negocia el tipo de certificado que se entregará al cliente durante el protocolo de enlace.
Autorizaciones de dominio
El Administrador de certificados te permite demostrar la propiedad de los dominios para los que deseas emitir certificados administrados por Google, como se describe en la siguiente tabla.
| Autorización del balanceador de cargas | Autorización de DNS | |
|---|---|---|
| Complejidad de la configuración | No requiere pasos de configuración adicionales ni cambios en la configuración del DNS. | Requiere que crees una autorización de DNS y agregues su registro CNAME correspondiente a tu configuración de DNS. |
| Seguridad de red | Se debe poder acceder completamente al balanceador de cargas desde Internet en el puerto 443, incluida la configuración de DNS para todos los dominios que entrega el certificado. No funciona con otros parámetros de configuración. | Funciona con configuraciones de alta complejidad, como puertos que no sean 443 y capas de CDN frente al proxy de destino. |
| Velocidad de aprovisionamiento | Puedes aprovisionar certificados solo después de que el balanceador de cargas se haya configurado por completo y esté entregando tráfico de red. | Puedes aprovisionar certificados por adelantado, antes de que el proxy de destino esté listo para entregar tráfico de red. |
A fin de comprender cómo el Administrador de certificados verifica la propiedad del dominio con cada método, consulta Autorizaciones de dominio para certificados administrados por Google.
Configuración de emisión de certificados
Una configuración de emisión de certificados es un recurso que permite al Administrador de certificados usar un grupo de AC de tu propia instancia de Certificate Authority Service para emitir certificados administrados por Google en lugar de la AC de Google o la AC Let's Encrypt. Te permite especificar una serie de parámetros que rigen la emisión y el vencimiento de los certificados, así como seleccionar el algoritmo clave para los certificados emitidos de esta manera.
Configuración de confianza
Una configuración de confianza es un recurso que representa la configuración de tu infraestructura de clave pública (PKI) en el Administrador de certificados para su uso en situaciones de autenticación TLS mutua. Encapsula un solo almacén de confianza, que, a su vez, encapsula un ancla de confianza y, de forma opcional, uno o más certificados intermedios.
Para obtener más información sobre la autenticación TLS mutua, consulta Autenticación mutua de TLS en la documentación de Cloud Load Balancing.
Un recurso de configuración de confianza encapsula el almacén de confianza, el ancla de confianza y las entidades de certificado intermedias.
Almacenes de confianza
Un almacén de confianza representa la configuración del secreto de confianza en el Administrador de certificados para su uso en situaciones de autenticación TLS mutua. Encapsula un solo ancla de confianza y, de forma opcional, uno o más certificados intermedios.
Anclas de confianza
Un ancla de confianza representa un único certificado raíz para usar en situaciones de autenticación TLS mutua. Se encapsula dentro de un almacén de confianza.
Certificados intermedios
Un certificado intermedio representa un único certificado intermedio firmado por un certificado raíz o un certificado intermedio al que se hace referencia en el almacén de confianza de encapsulamiento para su uso en situaciones de autenticación TLS mutua.
Se pueden encapsular uno o más certificados intermedios dentro de un almacén de confianza, según la configuración de tu PKI. Todos los certificados intermedios especificados dentro de una configuración de confianza se incluyen como parte de la evaluación de confianza de cada solicitud de conexión, además de la lista de certificados intermedios especificada en la solicitud.
Certificados que requieren una lista de entidades permitidas
De manera opcional, si necesitas usar un certificado autofirmado, vencido o no válido, o si no tienes acceso a los certificados intermedios y raíz, puedes agregar ese certificado a la configuración de confianza en el campo allowlistedCertificates. No necesitas un almacén de confianza para agregar
un certificado a una lista de entidades permitidas.
Agregar un certificado a la lista de entidades permitidas significa que el certificado siempre se considerará válido, siempre que el certificado se pueda analizar, se establezca una prueba de posesión de la clave privada y se cumplan las restricciones del campo SAN del certificado.
Lógica de selección de certificados
En un nivel alto, el balanceador de cargas selecciona un certificado de la siguiente manera:
- Un cliente inicia un protocolo de enlace. Durante este paso, proporciona al balanceador de cargas una lista de algoritmos criptográficos que puede usar para completar el protocolo de enlace y, de forma opcional, un nombre de host.
El balanceador de cargas selecciona un certificado para completar el protocolo de enlace seguro basado en el nombre de host que proporciona el cliente y las entradas del mapa de certificados configurados. Los factores que determinan qué certificado selecciona el balanceador de cargas son los siguientes:
Coincidencia exacta con el nombre de host: Si el cliente proporciona un nombre de host que coincide de forma exacta con una entrada en el mapa de certificados aprovisionado, el balanceador de cargas selecciona el certificado correspondiente.
Coincidencia con el nombre de host comodín: Si el nombre de host del cliente no coincide con ninguna entrada, pero coincide con un nombre de host comodín en una entrada de mapa de certificados, el balanceador de cargas selecciona el certificado correspondiente de esa entrada. Por ejemplo, una entrada comodín configurada como
*.myorg.example.comabarca los subdominios de primer nivel dentro del dominiomyorg.example.com.Sin coincidencia de nombre de host y entrada de mapa de certificados principal preconfigurada: El balanceador de cargas selecciona una entrada de mapa de certificados principal preconfigurada en ausencia de una coincidencia de nombre de host o una entrada de mapa de certificados aprovisionado que coincida.
Fallo del protocolo de enlace: El protocolo de enlace falla si el balanceador de cargas no puede encontrar un certificado coincidente por los siguientes motivos:
- El cliente proporciona un nombre de host que no coincide con ningún nombre de host exacto o comodín especificado en todas las entradas del mapa de certificados aprovisionados, o que no proporciona ningún nombre de host.
- No se encuentra una entrada del mapa de certificados principal que coincida o si no configuraste una entrada de mapa de certificados principal.
Prioridad del certificado
El balanceador de cargas selecciona un certificado dentro de una entrada del mapa de certificados en función de lo siguiente:
- Tipo de certificado. Si el cliente que se conecta admite los certificados ECDSA más seguros, el balanceador de cargas los prioriza por sobre los certificados RSA. Si el cliente no indica compatibilidad con los certificados ECDSA, el balanceador de cargas entrega un certificado RSA en su lugar.
- Tamaño del certificado. El balanceador de cargas prioriza los certificados de menor a mayor.
Nombres de dominio comodín
Las siguientes reglas se aplican a los nombres de dominio comodines:
- Solo los certificados administrados por Google con autorización de DNS y los certificados administrados por Google con el servicio de CA admiten nombres de dominio comodín. Los certificados administrados por Google con autorización del balanceador de cargas no admiten nombres de dominio comodín.
- Cuando ambos se definen en la entrada, una concordancia exacta tiene prioridad sobre un comodín. Por ejemplo, si configuraste entradas de asignación de certificados para
www.myorg.example.comy*.myorg.example.com, una solicitud de conexión parawww.myorg.example.comsiempre selecciona la entrada parawww.myorg.example.com, incluso si también existe una para*.myorg.example.com. - Los nombres de dominio comodín solo coinciden con un nivel de subdominio. Por ejemplo, una solicitud de conexión para
host1.myorg.example.comselecciona una entrada de mapa de certificados para*.myorg.example.com, pero no una parahost1.hosts.myorg.example.com.
Public CA
Para usar la función de AC pública del Administrador de certificados, debes estar familiarizado con los siguientes conceptos:
Cliente de ACME. Un cliente de entorno automático de administración de certificados (ACME) es un cliente de administración de certificados que usa el protocolo ACME. Tu cliente de ACME debe admitir la vinculación de cuenta externa (EAB) para funcionar con la AC pública.
Vinculación de cuenta externa (EAB). Debes vincular cada cuenta de ACME que uses con la AC pública del Administrador de certificados al proyecto de Google Cloud de destino mediante la vinculación de cuenta externa. Para ello, debes registrar cada cuenta de ACME con un secreto vinculado a su proyecto de Google Cloud correspondiente. Para obtener más información, consulta Vinculación de cuenta externa.
Desafíos de Public CA
Cuando usas Public CA para solicitar un certificado, el Administrador de certificados te pide que demuestres tu control sobre los dominios que figuran en ese certificado. Puedes demostrar el control del dominio resolviendo desafíos. Public CA autoriza los nombres de dominio después de que demuestras el control de los dominios de destino.
Después de obtener las autorizaciones necesarias, puedes solicitar certificados que sean válidos solo por un período específico. Después de esta duración, debes volver a validar el nombre de dominio mediante la resolución de uno de los tres tipos de verificación para continuar solicitando certificados.
Tipos de verificaciones
Public CA admite los siguientes tipos de desafíos:
Desafío HTTP. Este desafío implica crear un archivo en una ubicación conocida en un servidor HTTP (puerto 80) para que Public CA lo recupere y verifique. Para obtener más información, consulta el desafío HTTP.
Desafío de negociación del protocolo de la capa de aplicaciones (ALPN) para TLS. Requiere que un servidor proporcione un certificado específico durante una negociación TLS en el puerto 443 para demostrar el control de un dominio. Para obtener más información, consulta la extensión de desafío TLS-ALPN de ACME.
Desafío de DNS. Requiere agregar un registro DNS en una ubicación definida para demostrar el control de un dominio. Para obtener más información, consulta Desafío de DNS.
Si usas el desafío HTTP o el desafío TLS-ALPN para validar un nombre de dominio, el cliente solo puede solicitar que los nombres de dominio validados se incluyan en un certificado. Si usas el desafío de DNS, el cliente también puede solicitar que los subdominios de ese nombre de dominio se incluyan en un certificado.
Por ejemplo, si validas *.myorg.example.com mediante el desafío de DNS, el certificado comodín cubre de forma automática subdomain1.myorg.example.com y subdomain2.myorg.example.com. Sin embargo, si validas myorg.example.com con un desafío HTTP o TLS-ALPN, el cliente solo puede solicitar que se incluya myorg.example.com en el certificado y no puedes validar *.myorg.example.com mediante verificaciones que no son de DNS.
Lógica de la solución de desafío
La lógica del desafío de la AC pública es la siguiente:
- Public CA proporciona un token aleatorio.
- El cliente pone el token a disposición en una ubicación bien definida. La ubicación depende del desafío.
- El cliente le indica a Public CA que preparó el desafío.
- Public CA verifica si el token presente en la ubicación esperada coincide con el valor esperado.
El nombre de dominio se autoriza después de que se completa este proceso. El cliente puede solicitar un certificado con ese nombre de dominio. Solo necesitas resolver un desafío por nombre de dominio.