SSL/TLS es el protocolo criptográfico más utilizado en Internet. Técnicamente, TLS es el sucesor de SSL, aunque a veces los términos se usan indistintamente, 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.
Método de configuración del certificado
En el caso de los balanceadores de cargas de aplicaciones que usan proxies HTTPS de destino, el proxy de destino del balanceador de cargas debe hacer referencia a entre uno y 15 certificados 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 CA.
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 del certificado: El proxy de destino hace referencia a… | |||
|---|---|---|---|---|
| Certificados SSL de Compute Engine | Un mapa de certificados del Administrador de certificados | Certificados del Administrador de certificados directamente | ||
| Balanceadores de cargas de aplicaciones (proxies HTTPS de destino) | ||||
| Balanceador de cargas de aplicaciones externo regional | Admite certificados regionales autoadministrados administrados por Google |
Administrada por el usuario Administrada por Google |
||
| Balanceador de cargas de aplicaciones interno regional | Admite certificados regionales autoadministrados administrados por Google |
Administrada por el usuario Administrada por Google |
||
Tipos de certificados
Puedes crear certificados SSL autoadministrados para tus balanceadores de cargas.
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 recursos de certificados SSL de Compute Engine. Para obtener más información, consulta Usa certificados SSL autoadministrados.
Tipos de claves admitidos
Los siguientes tipos de claves son compatibles con los certificados SSL de Compute Engine autoadministrados regionales:
- RSA-2048
- RSA-3072
- RSA-4096
- ECDSA P-256
- ECDSA P-384
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 el tipo de clave recomendado para la mayoría de los certificados TLS, ya que ofrece una sólida seguridad criptográfica junto con un excelente rendimiento 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 exigen que uses tamaños de clave más grandes o tipos de clave particulares, puedes usar 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 curva elíptica, que proporciona una mayor seguridad por unidad de clave y, en algunos casos, una mejor eficiencia computacional 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 mayor nivel de seguridad que cualquier tamaño de clave RSA ampliamente compatible.
Beneficios clave de ECDSA:
Rendimiento: Las operaciones de firma ECDSA requieren significativamente menos recursos de procesamiento que las operaciones RSA que proporcionan un nivel de seguridad equivalente. Esto reduce la carga y la latencia de la CPU, lo que es fundamental para los sistemas de alto rendimiento 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 los entornos con recursos limitados, como los dispositivos móviles y de IoT.
Múltiples certificados SSL
El proxy de destino de un balanceador de cargas de aplicaciones puede hacer referencia a hasta 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 obtener más información, consulta Proxies de destino y Certificados SSL en la documentación del balanceo de cargas.
Proceso de selección de certificados
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.
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 solo 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 que no coincide con ningún nombre alternativo del sujeto 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 con el sufijo más largo en relación con los atributos de nombre común (CN) y de nombre alternativo del sujeto (SAN), con preferencia para los certificados de ECDSA en lugar de los RSA.
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
- CN:
Certificado B
- CN:
dogs.pets.example.com - SAN:
dogs.pets.example.com,*.pets.example.com,*.example.com
- CN:
Ahora, considera las siguientes situaciones:
- Si el nombre de host de SNI que envía el cliente es
cats.pets.example.com, el balanceador de cargas usa el certificado A. - Si el nombre de host de SNI que envió el cliente es
ferrets.pets.example.com, no hay una coincidencia exacta, por lo que el balanceador de cargas selecciona cualquiera de los certificados A o B, ya que ambos incluyen*.pets.example.comen su lista de SAN. No puedes controlar qué certificado se selecciona en esta situación.
- Si el nombre de host de SNI que envía el cliente es
Después de seleccionar un certificado, el balanceador de cargas se lo envía al cliente solo si el certificado seleccionado usa un algoritmo de clave pública que es compatible con un algoritmo de cifrado que el cliente envió en
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.