El Administrador de certificados usa un mecanismo de asignación flexible que te brinda un control detallado sobre los certificados que puedes asignar y 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 ver más sobre las diferencias entre estos tipos de proxy, consulta Usa proxies de destino.
Para obtener información sobre los tipos de certificados compatibles, 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 adoptado por todas las AC de confianza pública, y se aplica a los certificados administrados por Google y los certificados autoadministrados. Sin embargo, si usas Certificate Authority Service para emitir tu Certificado administrado por Google, el Administrador de certificados no publica ningún información a 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 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 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 RSA certificados 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 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 (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 usar AC públicas aprobadas por Google para emitir tus certificados, puedes configurar el Administrador de certificados para que use un Grupo de AC de Certificate Authority Service como el emisor del certificado. 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 permite implementar certificados autoadministrados en Los proxies del proxy web seguro y los regionales de cargas HTTP(S) externos regionales.
Mapas de certificados
El mapa de certificados hace referencia a una o más entradas que asignan certificados específicos con nombres de host específicos. Las entradas del mapa de certificados también definen la lógica de selección que sigue el balanceador de cargas cuando se establece el cliente conexiones de red. 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, la carga 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. Puedes definir diferentes conjuntos de certificados para distintos nombres de dominio como dominios o subdominios. Por ejemplo, puedes subir un ECDSA y un RSA. certificado de Google y asignarlas 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 tu DNS. configuración. | 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 otros parámetros de configuración. | 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 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, opcionalmente, 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
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, proporciona el balanceador de cargas con 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 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 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 certificado 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 aprovisionados 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 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 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.
- Una concordancia exacta tiene prioridad sobre un comodín cuando ambos están definidos en el
entrada. Por ejemplo, si configuraste entradas del mapa 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 comodín 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 conocer con los siguientes conceptos:
Cliente de ACME. Un cliente del entorno automático de administración de certificados (ACME) es un certificado de administración de identidades y accesos 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 el Administrador de certificados CA pública al proyecto de Google Cloud de destino mediante la vinculación de cuenta externa. 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 Public CA para solicitar un certificado, El Administrador de certificados te pide que demuestres tu control de los dominios que figura en ese certificado. Puedes demostrar el control del dominio resolviendo 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 plazo, debes volver a validar el nombre de dominio resolviendo uno de los tres tipos de desafío 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 un dominio conocido en un servidor HTTP (puerto 80) para que Public CA recupere y verificar. 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 un que el 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 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.
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. 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 necesitas resolver una desafío por nombre de dominio.