Descripción general de los certificados SSL

SSL/TLS es el protocolo criptográfico más usado en Internet. Técnicamente, TLS es el sucesor de SSL, aunque los términos a veces se usan de forma indistinta, como en este documento.

La seguridad de la capa de transporte (TLS) se usa para encriptar información mientras se envía a través de una red, lo que proporciona privacidad entre un cliente y un servidor o un balanceador de cargas. Un balanceador de cargas de aplicaciones o un balanceador de cargas de red de proxy que usa SSL requiere al menos una clave privada y un certificado SSL.

En esta página, se analizan los certificados SSL y la encriptación en tránsito entre un balanceador de cargas de aplicaciones o un balanceador de cargas de red de proxy que usa SSL y sus clientes. Para obtener detalles sobre la encriptación en tránsito entre el balanceador de cargas de Google Cloud y sus backends, consulta Encriptación en los backends.

Importante: Google Cloud recomienda enfáticamente usar el Administrador de certificados como tu herramienta principal de administración de certificados para las implementaciones de balanceador de cargas. Si bien los certificados SSL de Compute Engine (certificados clásicos) siguen siendo compatibles, tienen limitaciones notables. En cambio, la API moderna del Administrador de certificados (certificatemanager.googleapis.com) admite comodines, escalamiento sin interrupciones y actualizaciones dinámicas y sin interrupciones.

Métodos de configuración de certificados

Google Cloud ofrece tres métodos de configuración de certificados para los balanceadores de cargas de aplicaciones que usan proxies HTTPS de destino y los balanceadores de cargas de red de proxy que usan proxies SSL de destino.

• El proxy de destino hace referencia a los certificados SSL de Compute Engine: Con este método, el proxy de destino del balanceador de cargas puede hacer referencia a hasta 15 recursos de certificado SSL de Compute Engine. Cada recurso de certificado SSL de Compute Engine contiene la clave privada, el certificado correspondiente y, de forma opcional, los certificados de la AC.

• El proxy de destino hace referencia a un mapa de certificados del Administrador de certificados: con este método, el proxy de destino del balanceador de cargas hace referencia a un solo mapa de certificados. El mapa de certificados admite miles de entradas de forma predeterminada y puede escalar a millones de entradas. Cada entrada contiene datos de la clave privada y del certificado.

• El proxy de destino hace referencia a los certificados del Administrador de certificados directamente: Con este método, el proxy de destino del balanceador de cargas puede hacer referencia a un máximo de 100 certificados del Administrador de certificados.

Compatibilidad con el balanceador de cargas

En la siguiente tabla, se muestran los métodos de configuración de certificados que admite cada balanceador de cargas.

Balanceador de cargas	Método de configuración de certificados
	Certificados SSL de Compute Engine	Administrador de certificados (mapa de certificados)	Administrador de certificados (certificados individuales)
Balanceadores de cargas de aplicaciones (proxies HTTPS de destino)
Balanceador de cargas de aplicaciones externo global	Autoadministrado Administrado por Google	Autoadministrado Administrado por Google
Balanceador de cargas de aplicaciones clásico	Autoadministrado Administrado por Google	Autoadministrado Administrado por Google
Balanceador de cargas de aplicaciones externo regional	Autoadministrado Administrado por Google		Autoadministrado Administrado por Google
Balanceador de cargas de aplicaciones interno regional	Autoadministrado Administrado por Google		Autoadministrado Administrado por Google
Balanceador de cargas de aplicaciones interno entre regiones			Autoadministrado Administrado por Google
Balanceadores de cargas de red de proxy (proxies SSL de destino)
Balanceador de cargas de red del proxy externo global	Autoadministrado Administrado por Google	Autoadministrado Administrado por Google
Balanceador de cargas de red del proxy clásico	Autoadministrado Administrado por Google	Autoadministrado Administrado por Google

Reglas de métodos de configuración

Google Cloud aplica las siguientes reglas de métodos de configuración de certificados:

• Para los balanceadores de cargas que admiten certificados SSL de Compute Engine y mapas de certificados del Administrador de certificados: el proxy de destino del balanceador de cargas puede hacer referencia de forma simultánea a un mapa de certificados y a uno o más certificados SSL de Compute Engine.

  Precaución: Cuando usas certificados de Compute Engine y mapas de certificados, se ignoran todos los certificados SSL de Compute Engine y el balanceador de cargas solo usa los certificados del mapa de certificados.

• Para los balanceadores de cargas que admiten certificados SSL de Compute Engine y certificados del Administrador de certificados conectados directamente: el proxy de destino del balanceador de cargas solo se puede configurar para hacer referencia a un máximo de 15 certificados SSL de Compute Engine o hasta 100 certificados del Administrador de certificados, no una combinación de ambos.

Tipos de certificados

Google Cloud admite certificados autoadministrados y administrados por Google.

Certificados SSL autoadministrados

Los certificados SSL autoadministrados son certificados que obtienes, aprovisionas y renuevas tú mismo. Los certificados autoadministrados pueden ser de cualquiera de estos tipos de certificado de clave pública:

• Validación de dominio (DV)
• Validación de organización (OV)
• Validación extendida (EV)

Puedes crear certificados SSL autoadministrados con los siguientes elementos:

• Recursos de certificados SSL de Compute Engine: Para obtener más información, consulta Usa certificados SSL autoadministrados.

• Administrador de certificados: Para obtener más información, consulta Descripción general de la implementación en la documentación del Administrador de certificados.

Certificados SSL administrados por Google

Los certificados SSL administrados por Google son certificados que Google Cloud obtiene, administra y renueva de manera automática. Los certificados administrados por Google son siempre certificados de validación de dominio (DV). No demuestran la identidad de una organización o de un individuo asociados con el certificado.

Los certificados administrados por Google que usan comodines solo son compatibles con el Administrador de certificados cuando se usa la autorización de DNS.

Puedes crear certificados SSL administrados por Google con lo siguiente:

• Recursos de certificados SSL de Compute Engine: Solo los recursos globales de Compute Engine sslCertificates admiten certificados SSL administrados por Google; regionSslCertificates no los admite. Los certificados SSL globales de Compute Engine solo admiten certificados administrados por Google de confianza pública. Para obtener más información, consulta Usa certificados SSL administrados por Google.
• Administrador de certificados: Los certificados del Administrador de certificados (tanto globales como regionales) admiten certificados administrados por Google de confianza pública y certificados administrados por Google de confianza privada. Para obtener más información, consulta Certificados en la documentación del Administrador de certificados.

Tipos de claves admitidos

Los balanceadores de cargas admiten certificados que usan claves privadas de diferentes tipos de claves. En la siguiente tabla, se muestra la compatibilidad con el tipo de clave según si los certificados son globales o regionales, y si son autoadministrados o administrados por Google.

Tipo de certificado SSL arrow_forward Tipo de clave arrow_downward	Certificados SSL de Compute Engine			Certificados SSL del Administrador de certificados
	Global		Regional	Global y regional
	Administración automática	Administrado por Google de confianza pública	Administración automática	Administración automática	Administrado por Google y de confianza pública	Administrado por Google con confianza privada
RSA-2048
RSA-3072
RSA-4096
ECDSA P-256
ECDSA P-384

Importante: Se generan cargos por conexión TLS cuando usas tipos de claves RSA-3072 o RSA-4096. Para obtener más información, consulta Todos los precios de herramientas de redes.

Para obtener más información sobre los certificados del Administrador de certificados, consulta la documentación del Administrador de certificados.

Usa certificados con claves ECDSA

En esta sección, se analiza por qué recomendamos ECDSA en lugar de RSA como práctica recomendada para las claves de firma de certificados.

Qué tipo de clave usar

ECDSA P-256 es la opción recomendada de tipo de clave para la mayoría de los certificados TLS, ya que ofrece una seguridad criptográfica sólida junto con un rendimiento excelente para las operaciones de firma y un uso eficiente del ancho de banda de la red.

Estos son algunos de los posibles motivos para usar otros tipos de claves de certificado:

• Si necesitas admitir clientes heredados que no admiten certificados ECDSA, puedes proporcionar certificados RSA-2048 además de los certificados ECDSA P-256.
• Si tienes requisitos de cumplimiento específicos que te exigen usar tamaños de clave más grandes o tipos de claves particulares, se pueden usar las claves ECDSA P-384, RSA-2048, RSA-3072 y RSA-4096.

Por qué elegir ECDSA en lugar de RSA

La principal ventaja de ECDSA radica en su capacidad de proporcionar un nivel de seguridad criptográfica equivalente con claves significativamente más pequeñas en comparación con RSA. Esta eficiencia se traduce en beneficios tangibles de rendimiento y recursos. Una clave más pequeña no implica una seguridad más débil: ECDSA se basa en el problema del logaritmo discreto de la curva elíptica, que proporciona una seguridad más sólida por unidad de clave y, en algunos casos, una mejor eficiencia de procesamiento en comparación con RSA.

Por ejemplo:

• Una clave ECDSA de 256 bits proporciona un nivel de seguridad similar al de una clave RSA-3072.
• Una clave ECDSA de 384 bits proporciona un nivel de seguridad mayor que cualquier tamaño de clave RSA ampliamente compatible.

Estos son los beneficios clave de ECDSA:

• Rendimiento: Las operaciones de firma de ECDSA requieren un uso de procesamiento mucho menor que las operaciones de RSA que proporcionan un nivel de seguridad equivalente. Esto reduce la carga de la CPU y la latencia, lo que es fundamental para los sistemas de alta capacidad de procesamiento o sensibles a la latencia.

• Eficiencia: Las claves y firmas más pequeñas requieren menos ancho de banda y almacenamiento, lo que es especialmente beneficioso para entornos con recursos limitados, como dispositivos móviles y de IoT.

Múltiples certificados SSL

Un balanceador de cargas de aplicaciones o un balanceador de cargas de red de proxy puede alojar dos o más certificados SSL de forma simultánea cuando su proxy de destino se configura con un método de configuración de certificados compatible. Como práctica recomendada, usa el Administrador de certificados cuando se necesiten varios certificados SSL.

• Para los balanceadores de cargas que admiten certificados SSL de Compute Engine: el proxy de destino del balanceador de cargas puede hacer referencia a un máximo de 15 certificados SSL de Compute Engine. El primer recurso de certificado SSL de Compute Engine al que se hace referencia es el certificado predeterminado (principal) para el proxy de destino.

• Para los balanceadores de cargas que admiten un mapa de certificados del Administrador de certificados: El proxy de destino del balanceador de cargas hace referencia a un solo mapa de certificados. El mapa de certificados admite miles de entradas de mapa de certificados. Puedes configurar la entrada de certificado que será el certificado predeterminado (principal) del mapa de certificados.

• Para los balanceadores de cargas que admiten la referencia directa a los certificados del Administrador de certificados: El proxy de destino del balanceador de cargas puede hacer referencia a un máximo de 100 certificados del Administrador de certificados. El primer recurso de certificado SSL del Administrador de certificados al que se hace referencia es el certificado predeterminado (principal) para el proxy de destino.

Para obtener más información, consulta las secciones siguientes:

• Proxies de destino y certificados SSL en la documentación del balanceo de cargas.

• Cuotas y límites de recursos en la documentación del Administrador de certificados.

Proceso de selección del certificado

El siguiente proceso de selección de certificados se aplica a los balanceadores de cargas cuyos proxies de destino hacen referencia a varios certificados SSL de Compute Engine o a varios certificados del Administrador de certificados.

El proceso de selección de certificados es diferente si el proxy de destino de un balanceador de cargas hace referencia a un mapa de certificados del Administrador de certificados. Para obtener detalles sobre el proceso de selección de certificados de un mapa de certificados, consulta Lógica de selección de certificados en la documentación del Administrador de certificados.

Importante: El proceso de selección de certificados no tiene en cuenta los atributos notValidBefore ni notValidAfter. El balanceador de cargas puede entregar un certificado vencido si se configura un certificado vencido. Puedes evitar esta situación con los certificados administrados por Google.

Después de que un cliente se conecta al balanceador de cargas, el cliente y el balanceador de cargas negocian una sesión de TLS. Durante la negociación de sesión de TLS, el cliente envía al balanceador de cargas una lista de algoritmos de cifrado de TLS que admite (en ClientHello). El balanceador de cargas selecciona un certificado cuyo algoritmo de clave pública sea compatible con el cliente. El cliente también puede enviar un nombre de host de indicación del nombre del servidor (SNI) al balanceador de cargas como parte de esta negociación. Los datos de nombre de host de SNI a veces se usan para ayudar al balanceador de cargas a elegir qué certificado debe enviar al cliente.

• Si el proxy de destino del balanceador de cargas hace referencia a un solo certificado, se usa ese certificado y el valor del nombre de host de SNI que envía el cliente no es relevante.

• Si el proxy de destino del balanceador de cargas hace referencia a dos o más certificados, el balanceador de cargas usa el siguiente proceso para seleccionar un único certificado:

  • Si el cliente no envió ningún nombre de host de SNI en su ClientHello, el balanceador de cargas usa el primer certificado de su lista de certificados.

  • Si el cliente envía un nombre de host de SNI que no coincide con ningún nombre común de certificado (CN) y no coincide con ningún nombre de sujeto alternativo de certificado (SAN), el balanceador de cargas usa el primer certificado de su lista de certificados.

  • En todas las demás situaciones, el balanceador de cargas selecciona un certificado con el siguiente proceso de coincidencia:

    • La coincidencia se aplica en relación con los atributos de nombre común (CN) y de nombre alternativo del sujeto (SAN). Si solo un certificado coincide con el nombre de host de SNI, el balanceador de cargas selecciona ese certificado. Si varios certificados coinciden con el nombre de host de SNI, el balanceador de cargas los prioriza en el siguiente orden:

      • Coincidencia exacta del nombre de host: Las coincidencias exactas con el CN o el SAN tienen prioridad sobre las coincidencias con comodines.

      • Coincidencia de nombre de host con comodín: Si no hay una coincidencia exacta, el balanceador de cargas verifica si hay una coincidencia de CN o SAN con comodín. Un comodín (*) solo coincide con el subdominio de primer nivel (por ejemplo, *.pets.example.com coincide con cats.pets.example.com en lugar de *.example.com).

      • Tipo de clave de certificado: Se prefieren los certificados ECDSA en lugar de los certificados RSA.

      • Tamaño de la cadena de certificados: Si varios certificados tienen la misma especificidad de coincidencia y el mismo algoritmo de clave pública, el balanceador de cargas prioriza el certificado con el tamaño de cadena de certificados más pequeño (en bytes) para minimizar el ancho de banda de la red durante el protocolo de enlace TLS.

    • Para ilustrar el método de coincidencia, considera un proxy de destino que haga referencia a los siguientes dos certificados:

      • Certificado A

        • CN: cats.pets.example.com
        • SAN: cats.pets.example.com, *.pets.example.com, *.example.com

      • Certificado B

        • CN: dogs.pets.example.com
        • SAN: dogs.pets.example.com, *.pets.example.com, *.example.com

    • Ahora, considera las siguientes situaciones:

      • Si el nombre de host de SNI que envió el cliente es cats.pets.example.com, el balanceador de cargas usa el certificado A.

      • Si el nombre de host de SNI que envía el cliente es ferrets.pets.example.com, no hay una coincidencia exacta, y tanto el certificado A como el certificado B coinciden con *.pets.example.com en su lista de SAN. Si ambos certificados usan el mismo algoritmo de clave pública, el balanceador de cargas selecciona el certificado con el tamaño de cadena de certificados más pequeño. Si los tamaños de la cadena de certificados también son idénticos, el balanceador de cargas selecciona el certificado A o el certificado B, y no puedes controlar qué certificado se selecciona.

• Después de seleccionar un certificado, el balanceador de cargas envía al cliente ese certificado solo si el certificado seleccionado usa un algoritmo de clave pública que sea compatible con un algoritmo de cifrado que el cliente envió en el ClientHello. La negociación de TLS falla si el cliente no admite un conjunto de algoritmos de cifrado que incluya el algoritmo de clave pública (ECDSA o RSA) del certificado que seleccionó el balanceador de cargas.

Precios

Para conocer los precios de los certificados SSL de Compute Engine y de Cloud Load Balancing, consulta Precios de red: Cloud Load Balancing.

Para obtener más información sobre los precios del Administrador de certificados, consulta la página de precios del Administrador de certificados.

¿Qué sigue?

• Descripción general del Administrador de certificados

• Encriptación en los backends

• Informe de Encriptación en tránsito en Google Cloud

Pruébalo tú mismo

Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Comenzar gratis