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 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 SSL de destino proxies. 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 que admite el Administrador de certificados; consulta Descripción general de la implementación.
Certificados
De forma predeterminada, un certificado representa una sola seguridad de la capa de transporte X.509 (TLS) (SSL) que se emite para nombres de dominio o dominios específicos comodines.
El Administrador de certificados admite los siguientes tipos de certificados:
- Los certificados administrados por Google son certificados que Google Cloud que obtiene y administra por ti.
- Los certificados autoadministrados son certificados que obtienes, aprovisionas y renovarte.
Cuando se emite un certificado con una AC de confianza pública, la AC publica información sobre el dominio asociado a los registros de Certificado de transparencia, que sean de acceso público. 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 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 la configuración manual y un mantenimiento regular. El Administrador de certificados es un servicio una plataforma centralizada para ayudarte a agilizar este proceso. Puedes delegar la responsabilidad de emitir y renovar certificados a Administrador de certificados, lo que te permite enfocarte en otras tareas esenciales.
Puedes verificar la propiedad del dominio relevante con balanceador de cargas Autorización basada en DNS. El Administrador de certificados admite RSA certificados 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 puede obtener un certificado de la AC de Google para un dominio en particular El Administrador de certificados recurre a la CA de Let's Encrypt. Para Por ejemplo, la AC de Google podría negarse a emitir un certificado para el dominio. tu registro de autorización de CA prohíbe explícitamente que la AC de Google emita certificados para ese dominio.
No se admite la autenticación solo para el 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 certificados basados en DNS autorización y obtener 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, Crea grupos de AC.
Certificados autoadministrados
Si los requisitos de tu empresa no te permiten usar herramientas certificados, puedes subir certificados emitidos por AC externas junto con sus claves asociadas. Eres responsable de emitir y renovar manualmente 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 reutilizar en varios balanceadores de cargas.
Si un cliente solicita un nombre de host especificado en un mapa de certificados, la carga 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 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 en los que quieres emitir certificados administrados por Google, como se describe a continuación desde una tabla de particiones.
| 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 la correspondiente registro CNAME a tu configuración de DNS. |
| Seguridad de red | Se debe poder acceder 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 otras configuraciones. | Funciona con configuraciones de alta complejidad, como puertos que no sean 443 y CDN frente al proxy de destino. |
| Velocidad de aprovisionamiento | Solo puedes aprovisionar certificados después de que el balanceador de cargas se haya completamente configurada y entrega tráfico de red. | Puedes aprovisionar certificados por adelantado, antes de que el proxy de destino lista 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.
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 para 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 de Let's Encrypt. Te permite para especificar una serie de parámetros que rigen la emisión y el vencimiento de los certificados, así como seleccionar el algoritmo de la 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 un almacén de confianza, un ancla de confianza y un certificado intermedio entidades.
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 único certificado raíz para usar en TLS mutua de autenticación de usuario. Se encapsula dentro de un almacén de confianza.
Certificados intermedios
Un certificado intermedio representa un único certificado intermedio firmado mediante un certificado raíz o un certificado intermedio al que se haga referencia en las almacén de confianza de encapsulamiento para usar en la autenticación TLS mutua reales.
Uno o más certificados intermedios se pueden encapsular 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 especificadas en la solicitud.
Certificados que requieren una lista de entidades permitidas
De manera opcional, si necesitas usar un certificado autofirmado,
haya vencido o no sea válido por algún otro motivo, o si no tienes acceso a los permisos de administrador
certificados intermedios, puedes agregarlo 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.
Si agregas un certificado a la lista de entidades permitidas, el certificado siempre estará se consideran válidos siempre que el certificado se pueda analizar, una prueba de clave privada y las limitaciones en el campo SAN del certificado los objetivos de la empresa.
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 basado en en el nombre de host que proporciona el cliente y el mapa de certificados configurado de entradas de registro. Los factores que determinan qué certificado qué selecciones son las 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 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 comodín configurada como
*.myorg.example.comabarca los subdominios de primer nivel dentro 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 aprovisionada 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 de mapa de certificados según lo siguiente:
- Tipo de certificado. Si el cliente que se conecta admite la versión más segura de ECDSA certificados, el balanceador de cargas los prioriza por sobre los certificados RSA. Si el botón no indica compatibilidad con certificados ECDSA, el balanceador de cargas publica un certificado RSA.
- Tamaño del certificado. El balanceador de cargas prioriza los certificados 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 AC admiten nombres de dominio con comodines. Los certificados administrados por Google con autorización del balanceador de cargas no admiten nombres de dominio comodín.
- Una concordancia exacta tiene prioridad sobre un comodín cuando ambos están definidos en el
entrada. Por ejemplo, si configuraste entradas de mapas 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 una también existe una entrada para*.myorg.example.com. - Los nombres de dominio con comodines solo coinciden con un nivel de subdominio. Para
Por ejemplo, una solicitud de conexión para
host1.myorg.example.comselecciona un certificado entrada de mapa 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 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 cuenta externa (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 hacerlo, debes registrar cada Cuenta de ACME a través de un Secret vinculado a su proyecto de Google Cloud correspondiente. Para obtener más información, consulta Cuenta externa. vinculación.
Desafíos de Public CA
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. Public CA autoriza los nombres de dominio después de que pruebes tu control de 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 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 la AC pública lo recupere y verifique. Para obtener más información, consulta el 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 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 el desafío TLS-ALPN para validar un nombre de dominio, el cliente solo puede solicitar el dominio validado nombres que se incluirán en un certificado. Si usas el desafío de DNS, el también puede solicitar que los subdominios de ese nombre de dominio se incluyan 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 tienen cobertura automática
por el certificado comodín. Sin embargo, si validas myorg.example.com con un protocolo
el desafío TLS-ALPN que el cliente solo puede solicitar para incluir myorg.example.com en
y no puedes validar *.myorg.example.com mediante verificaciones 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:
- Public CA proporciona un token aleatorio.
- El cliente pone el token a disposición en una ubicación bien definida. El la ubicación depende del desafío.
- El cliente le indica a Public CA que preparó la desafío.
- Public CA verifica si el token está presente en el rango de la ubicación 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.