El Administrador de certificados usa un mecanismo de asignación flexible que te proporciona un control detallado sobre qué certificados puedes asignar y cómo entregarlos para cada nombre de dominio en tu entorno. El mecanismo incluye las siguientes entidades:
- Certificados
- Mapas de certificados
- Entradas de mapas 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 y SSL de destino. Para obtener más información sobre las diferencias entre estos tipos de proxy, consulta Cómo usar proxies de destino.
Para obtener información sobre los tipos de certificados que admite el Administrador de certificados, consulta la descripción general de la implementación.
Certificados
De forma predeterminada, un certificado representa un solo 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 Cloudobtiene 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, esta publica información sobre el dominio asociado en los registros de transparencia de certificados, a los que se puede acceder de forma pública. Esto forma parte del proceso estándar de emisión de certificados que adoptan todas las AC de confianza pública y se aplica a los certificados administrados por Google y a los autoadministrados. Sin embargo, si usas el servicio de la AC para emitir tu certificado administrado por Google, el Administrador de certificados no publica información en los registros de transparencia de certificados.
Para obtener más información, consulta Certificado de transparencia.
Para obtener información sobre cómo implementar un certificado con el Administrador de certificados, consulta Descripción general de la implementación.
Certificados administrados por Google
La administración de certificados TLS (SSL) administrados por Google para tus sitios web y aplicaciones puede ser una tarea compleja y que consume mucho tiempo, que a menudo implica la configuración manual y el mantenimiento periódico. Certificate Manager es un servicio diseñado para ayudarte a optimizar este proceso, ya que proporciona una plataforma centralizada. Puedes delegar la responsabilidad de emitir y renovar certificados al Administrador de certificados, lo que te permitirá liberar tiempo para enfocarte en otras tareas fundamentales.
Puedes verificar la propiedad del dominio relevante mediante la autorización basada en el balanceador de cargas o en el 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 renueva un certificado nuevo administrado por Google, se usa una clave privada generada recientemente. Si no puedes obtener un certificado de la AC de Google para un dominio en particular, el Administrador de certificados recurre a la AC de Let's Encrypt. Por ejemplo, la AC de Google podría rechazar emitir un certificado para el dominio, o bien tu registro de autorización de AC prohíbe explícitamente que la AC de Google emita certificados para ese dominio.
No se admite la autenticación solo del cliente.
Para obtener instrucciones sobre cómo 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 solo admiten la autorización basada 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 que use un grupo de AC del Certificate Authority Service como emisor de certificados. Para obtener más información sobre los grupos de AC, consulta Crea grupos de AC.
Certificados autoadministrados
Si los requisitos de tu empresa 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 manualmente los certificados autoadministrados.
El Administrador de certificados también te permite implementar certificados regionales autoadministrados 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 para asignar 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 establece conexiones de cliente. Puedes asociar un mapa de certificados con varios proxies de destino para su reutilización 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 de mapas de certificados
Una entrada de mapa de certificados es una lista de certificados que se entregan para un nombre de dominio específico. Puedes definir diferentes conjuntos de certificados para diferentes nombres de dominio, como dominios o subdominios. Por ejemplo, puedes subir un certificado ECDSA y un certificado 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 de tu 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 al balanceador de cargas de forma completa desde Internet en el puerto 443, incluida la configuración de DNS de todos los dominios que entrega el certificado. No funciona con otras configuraciones. | Funciona con configuraciones de alta complejidad, como puertos distintos del 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é abasteciendo el tráfico de red. | Puedes aprovisionar certificados con anticipación, antes de que el proxy de destino esté listo para entregar el tráfico de red. |
Para 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.
Parámetros de configuración de emisión de certificados
Una configuración de emisión de certificados es un recurso que permite que el Administrador de certificados use 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 de 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 de 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 TLS mutua en la documentación de Cloud Load Balancing.
Un recurso de configuración de confianza encapsula las entidades del almacén de confianza, el ancla de confianza y el certificado intermedio.
Almacenes de confianza
Un almacén de confianza representa la configuración de 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 solo certificado raíz para su uso en situaciones de autenticación TLS mutua. Se encapsula en un almacén de confianza.
Certificados intermedios
Un certificado intermedio representa un solo certificado intermedio firmado por un certificado raíz o un certificado intermedio al que se hace referencia en el almacén de confianza encapsulado para su uso en situaciones de autenticación TLS mutua.
Se pueden encapsular uno o más certificados intermedios en 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 para cada solicitud de conexión, además de la lista de certificados intermedios especificados 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 raíz y intermedios, 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 este siempre se considera válido, siempre que se pueda analizar, se establezca la 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, le proporciona al balanceador de cargas una lista de algoritmos criptográficos que puede usar para completar el protocolo de enlace y, de manera opcional, un nombre de host.
El balanceador de cargas selecciona un certificado para completar el protocolo de enlace seguro según el nombre de host que proporciona el cliente y las entradas del mapa de certificados configuradas. Los factores que determinan qué certificado selecciona el balanceador de cargas son los siguientes:
Coincidencia exacta de nombre de host: Si el cliente proporciona un nombre de host que coincide exactamente con una entrada en el mapa de certificados aprovisionado, el balanceador de cargas selecciona el certificado correspondiente.
Coincidencia de nombre de host con comodín: Si el nombre de host del cliente no coincide con ninguna entrada, pero sí con un nombre de host con comodín en una entrada de mapa de certificados, el balanceador de cargas selecciona el certificado correspondiente de esa entrada. Por ejemplo, una entrada de comodín configurada como
*.myorg.example.comabarca los subdominios de primer nivel del dominiomyorg.example.com.No hay coincidencia de nombre de host y hay una entrada de mapa de certificados principal preconfigurada: El balanceador de cargas selecciona una entrada de mapa de certificados principal preconfigurada cuando no hay una coincidencia de nombre de host o una entrada de mapa de certificados aprovisionado que coincida.
Falla de enlace: El 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 aprovisionadas, o no proporciona ningún nombre de host.
- No se encuentra una entrada de 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 de mapa de certificados según lo siguiente:
- Tipo de certificado. Si el cliente que se conecta admite los certificados ECDSA más seguros, el balanceador de cargas los prioriza sobre los certificados RSA. Si el cliente no indica compatibilidad con certificados ECDSA, el balanceador de cargas entrega un certificado RSA.
- Tamaño del certificado. El balanceador de cargas prioriza los certificados del más pequeño al más grande.
Nombres de dominio con comodines
Las siguientes reglas se aplican a los nombres de dominio con comodines:
- Solo los certificados administrados por Google con autorización de DNS y los certificados administrados por Google con el servicio de AC admiten nombres de dominio con comodines. Los certificados administrados por Google con autorización de balanceador de cargas no admiten nombres de dominio de comodín.
- Una concordancia exacta tiene prioridad sobre un comodín cuando ambos se definen en la entrada. Por ejemplo, si configuraste entradas de mapa de certificados para
www.myorg.example.comy*.myorg.example.com, una solicitud de conexión awww.myorg.example.comsiempre selecciona la entrada parawww.myorg.example.com, incluso si también existe una entrada para*.myorg.example.com. - Los nombres de dominio con comodines 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 parahost1.hosts.myorg.example.com.
AC pública
Para usar la función de AC pública del Administrador de certificados, debes familiarizarte 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 cuentas externas (EAB) para funcionar con la AC pública.
Vinculación de cuentas externas (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 cuentas externas. 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 cuentas externas.
Desafíos de las AC públicas
Cuando usas una AC pública para solicitar un certificado, el Administrador de certificados te pide que demuestres tu control sobre los dominios que se indican en ese certificado. Para demostrar el control del dominio, debes resolver desafíos. La AC pública autoriza los nombres de dominio después de que demuestres tu control sobre los dominios de destino.
Después de obtener las autorizaciones necesarias, puedes solicitar certificados que solo sean válidos durante un período específico. Después de este período, debes volver a validar el nombre de dominio resolviendo uno de los tres tipos de desafíos para seguir solicitando certificados.
Tipos de desafíos
La AC pública 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 la AC pública lo recupere y verifique. Para obtener más información, consulta Desafío HTTP.
Desafío de negociación de protocolo de la capa de aplicación (ALPN) de TLS. Requiere que un servidor proporcione un certificado específico durante una negociación de TLS en el puerto 443 para demostrar el control sobre un dominio. Para obtener más información, consulta Extensión de desafío de ACME TLS-ALPN.
Desafío de DNS: Requiere agregar un registro DNS específico en una ubicación definida para demostrar el control sobre un dominio. Para obtener más información, consulta Desafío de DNS.
Si usas la prueba HTTP o la prueba 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 la verificación de DNS, el cliente también puede solicitar que se incluyan subdominios de ese nombre de dominio en un certificado.
Por ejemplo, si validas *.myorg.example.com con el desafío de DNS, el certificado comodín cubre automáticamente 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 incluir myorg.example.com en el certificado y no puedes validar *.myorg.example.com con los desafíos que no son de DNS.
Desafía la lógica de la solución
La lógica de desafío de la AC pública es la siguiente:
- La AC pública 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 la AC pública que preparó el desafío.
- La AC pública 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 debes resolver un desafío por nombre de dominio.