El Administrador de certificados usa un mecanismo de asignación flexible que te brinda control detallado sobre los certificados que 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 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.
Con el Administrador de certificados, puedes adjuntar tus certificados de las siguientes maneras:
- Si implementas certificados en balanceadores de cargas de aplicaciones externos globales, usa mapas de certificados adjuntos a proxies de destino y entradas de mapas de certificados. Para obtener más información, consulta Implementa un certificado autoadministrado global.
- Si implementas certificados en balanceadores de cargas de aplicaciones externos regionales, balanceadores de cargas de aplicaciones internos regionales o puertas de enlace de Proxy web seguro, adjunta los certificados directamente a los proxies de destino o a las puertas de enlace del Proxy web seguro. Para obtener más información, consulta Implementa un certificado regional autoadministrado.
- Si implementas certificados en balanceadores de cargas de aplicaciones internos entre regiones, adjunta los certificados con el permiso
ALL_REGIONSdirectamente a los proxies de destino. Los balanceadores de cargas de aplicaciones internos entre regiones no admiten certificados administrados por Google con autorización del balanceador de cargas. Sin embargo, sí admiten la autorización de DNS y la autorización de Certificate Authority Service.
Certificados
De forma predeterminada, un certificado representa un solo certificado de seguridad de la capa de transporte (TLS) (SSL) 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 del Certificado de transparencia, a los que se puede acceder de forma pública. Esto es 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 Certificate Authority Service para emitir tu certificado administrado por Google, el Administrador de certificados no publicará ninguna información en los registros de Transparencia de certificados.
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
La administración de certificados TLS (SSL) administrados por Google para tus sitios web y aplicaciones puede ser una tarea compleja y lenta que, a menudo, implica una configuración manual y un mantenimiento regular. El Administrador de certificados es un servicio diseñado para ayudarte a optimizar este proceso, a través de una plataforma centralizada. Puedes delegar al Administrador de certificados la responsabilidad de emitir y renovar certificados, lo que te ahorrará tiempo para enfocarte en otras tareas esenciales.
Puedes verificar la propiedad del dominio relevante a través de la autorización basada en balanceador de cargas o 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, este usa una clave privada recién generada. Si no puedes obtener un certificado de la CA de Google para un dominio en particular, el Administrador de certificados recurre a la CA de Let's Encrypt. Por ejemplo, la AC de Google podría negarse a emitir un certificado para el dominio o tu registro de autorización de AC prohíbe de forma explícita que la AC de Google emita certificados para ese dominio.
No se admite la autenticación solo del 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 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 las 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 entidad emisora 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 de forma manual los certificados autoadministrados.
El administrador de certificados también te permite implementar certificados regionales autoadministrados en los proxies de proxy web seguro y en los 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 las conexiones del cliente. Puedes asociar un mapa de certificados con varios proxies de destino para volver a utilizarlo 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 de 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 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 se requieren pasos de configuración adicionales ni cambios en la configuración del DNS. | Requiere que crees una autorización de DNS y agregues el registro CNAME correspondiente a tu configuración de DNS. |
| Seguridad de red | El balanceador de cargas debe ser totalmente accesible desde Internet en el puerto 443, incluida la configuración de DNS para todos los dominios que entrega el certificado. No funciona con otras configuraciones. | Funciona con opciones de configuración de alta complejidad, como puertos que no sean 443 y capas de CDN frente al proxy de destino. |
| Velocidad de aprovisionamiento | Solo puedes aprovisionar certificados 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. |
Para comprender cómo el Administrador de certificados verifica la propiedad del dominio mediante 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 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 cantidad de parámetros que rigen la emisión y el vencimiento de 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 las entidades del almacén de confianza, los anclas de confianza y los certificados intermedios.
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 certificado raíz único 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 certificado intermedio único firmado por un certificado raíz o un certificado intermedio al que se hace referencia en el almacén de confianza de encapsulamiento para usarlo 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 en 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 incluidos en la lista de entidades permitidas
Un certificado incluido en la lista de entidades permitidas representa cualquier certificado que se puede encapsular dentro de la configuración de confianza para que siempre se consideren válidos. Un certificado incluido en la lista de entidades permitidas siempre se considera válido, siempre y cuando se pueda analizar, se establezca una prueba de posesión de la clave privada y se cumplan las restricciones en el campo de SAN del certificado. Los certificados vencidos también se consideran válidos cuando están en la lista de entidades permitidas. No necesitas un almacén de confianza mientras usas certificados incluidos en la lista de entidades permitidas.
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 en función del nombre de host que proporciona el cliente y las entradas configuradas del mapa de certificados. 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 del nombre de host del comodín: Si el nombre de host del cliente no coincide con ninguna entrada, pero sí con un nombre de host comodín en una entrada de mapa de certificado, 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 en el dominiomyorg.example.com.No hay coincidencia de nombre de host y entrada de mapa de certificado principal preconfigurada: el balanceador de cargas selecciona una entrada de mapa de certificados principal preconfigurada ante la ausencia de una coincidencia de nombre de host o una entrada de mapa de certificados aprovisionado que coincida.
Fallo de protocolo de enlace: el protocolo de enlace falla si el balanceador de cargas no puede encontrar un certificado que coincida debido a 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 no proporciona ningún nombre de host.
- No se encuentra una entrada del mapa de certificado principal que coincida o si no has configurado una entrada del mapa de certificado principal.
Prioridad de certificados
El balanceador de cargas selecciona un certificado dentro de una entrada de 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 certificados ECDSA, el balanceador de cargas entrega un certificado RSA en su lugar.
- Tamaño del certificado. El balanceador de cargas prioriza los certificados del más pequeño al más grande.
Nombres de dominio comodín
Las siguientes reglas se aplican a los nombres de dominio de comodín:
- Solo los certificados administrados por Google con autorización de DNS y los certificados administrados por Google con CA Service 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.
- Una coincidencia 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 enwww.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 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 trabajar con Public CA.
Vinculación de cuentas externas (EAB). Debes vincular cada cuenta de ACME que uses con la CA 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 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 enumerados en ese certificado. Puedes demostrar el control del dominio resolviendo desafíos. Public CA autoriza los nombres de dominio después de que demuestras que tienes el control de los dominios de destino.
Después de obtener las autorizaciones requeridas, puedes solicitar certificados que sean válidos solo por un período específico. Después de este plazo, debes volver a validar el nombre de dominio. Para ello, debes resolver uno de los tres tipos de verificación a fin de seguir 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 la negociación del protocolo de la capa de aplicaciones (ALPN) TLS. Requiere que un servidor proporcione un certificado específico durante una negociación TLS en el puerto 443 para demostrar el control sobre un dominio. Para obtener más información, consulta Extensión del desafío TLS-ALPN de ACME.
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 el desafío HTTP 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 se incluyan subdominios de ese nombre de dominio en un certificado.
Por ejemplo, si validas *.myorg.example.com con el desafío de DNS, subdomain1.myorg.example.com y subdomain2.myorg.example.com se cubrirán de forma automática con el certificado comodín. 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 con los desafíos que no sean DNS.
Lógica de la solución del desafío
La lógica del desafío de CA 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 debes resolver un desafío por nombre de dominio.