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 utilizan indistintamente, como en este documento.
Seguridad en la capa de transporte (TLS) se usa para cifrar la 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 carga. Un balanceador de carga de aplicaciones o un balanceador de carga de red proxy que utilice SSL requiere al menos una clave privada y un certificado SSL.
Método de configuración de certificados
En el caso de los balanceadores de carga de aplicaciones que usan proxies HTTPS de destino, el proxy de destino del balanceador de carga debe hacer referencia a entre 1 y 15 certificados SSL de Compute Engine. Cada recurso de certificado SSL de Compute Engine contiene la clave privada, el certificado correspondiente y, opcionalmente, los certificados de CA.
Compatibilidad con balanceadores de carga
En la siguiente tabla se muestra qué métodos de configuración de certificados admite cada balanceador de carga.
| Balanceador de carga | Método de configuración del certificado: proxy de destino references... | |||
|---|---|---|---|---|
| Certificados SSL de Compute Engine | Un mapa de certificados de Certificate Manager | Directamente en Certificate Manager | ||
| Balanceadores de carga de aplicaciones (proxies HTTPS de destino) | ||||
| Balanceador de carga de aplicación externo regional | Admite
certificados regionales autogestionados gestionados por Google |
Gestionado por el usuario Gestionado por Google |
||
| Balanceador de carga de aplicación interno regional | Admite
certificados regionales autogestionados gestionados por Google |
Gestionado por el usuario Gestionado por Google |
||
Tipos de certificados
Puedes crear certificados SSL autogestionados para tus balanceadores de carga.
Certificados de SSL autogestionados
Los certificados SSL autogestionados son certificados que obtienes, aprovisionas y renuevas tú mismo. Los certificados autogestionados pueden ser de cualquiera de los siguientes tipos de certificado de clave pública:
- Validación de dominio (DV)
- Validación de la organización (OV)
- Certificados de validación ampliada (EV)
Puedes crear certificados SSL autogestionados con recursos de certificados SSL de Compute Engine. Para obtener más información, consulta Usar certificados SSL autogestionados.
Tipos de claves admitidos
Se admiten los siguientes tipos de claves para los certificados SSL de Compute Engine autogestionados regionales:
- RSA-2048
- RSA-3072
- RSA-4096
- ECDSA P-256
- ECDSA P-384
Usar certificados con claves ECDSA
En esta sección se explica 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 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 motivos por los que se pueden usar otros tipos de claves de certificado:
- Si necesitas admitir clientes antiguos que no admiten certificados ECDSA, puedes proporcionar certificados RSA-2048 además de certificados ECDSA P-256.
- Si tienes requisitos de cumplimiento específicos que te obligan a usar tamaños de clave más grandes o tipos de clave concretos, 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 es que ofrece un nivel de seguridad criptográfica equivalente con claves significativamente más pequeñas que RSA. Esta eficiencia se traduce en ventajas tangibles en cuanto al rendimiento y los recursos. Una clave más pequeña no implica una seguridad menor. ECDSA se basa en el problema del logaritmo discreto de curva elíptica, que proporciona una seguridad más sólida por unidad de clave y, en algunos casos, una mayor 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 de 3072 bits.
- Una clave ECDSA de 384 bits proporciona un nivel de seguridad mayor que cualquier tamaño de clave RSA ampliamente admitido.
Ventajas principales de ECDSA:
Rendimiento: las operaciones de firma ECDSA requieren muchos menos recursos computacionales que las operaciones RSA, pero ofrecen un nivel de seguridad equivalente. De esta forma, se reduce la carga de la CPU y la latencia, lo que es fundamental para los sistemas de alto rendimiento o sensibles a la latencia.
Eficiencia: las claves y las firmas más pequeñas requieren menos ancho de banda y almacenamiento, lo que resulta especialmente útil en entornos con recursos limitados, como los dispositivos móviles y de IoT.
Varios certificados SSL
Un proxy de destino de un balanceador de carga de aplicaciones 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) del proxy de destino.
Para obtener más información, consulta los artículos Proxies de destino y Certificados SSL en la documentación sobre el balanceo de carga.
Proceso de selección de certificados
El siguiente proceso de selección de certificados se aplica a los balanceadores de carga cuyos proxies de destino hacen referencia a varios certificados SSL de Compute Engine.
Después de que un cliente se conecte al balanceador de carga, el cliente y el balanceador de carga negociarán una sesión TLS. Durante la negociación de la sesión TLS, el cliente envía al balanceador de carga una lista de cifrados TLS que admite (en ClientHello). El balanceador de carga 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 de nombre de servidor (SNI) al balanceador de carga como parte de esta negociación. A veces, los datos del nombre de host de SNI se usan para ayudar al balanceador de carga a elegir el certificado que debe enviar al cliente.
Si el proxy de destino del balanceador de carga hace referencia a un solo certificado, se usará ese certificado y el valor del nombre de host de SNI enviado por el cliente no será relevante.
Si el proxy de destino del balanceador de carga hace referencia a dos o más certificados, el balanceador de carga sigue este proceso para seleccionar un único certificado:
Si el cliente no ha enviado ningún nombre de host SNI en su
ClientHello, el balanceador de carga usa el primer certificado de su lista de certificados.Si el cliente envía un nombre de host SNI que no coincide con ningún nombre común (CN) de certificado ni con ningún nombre alternativo del sujeto (SAN) de certificado, el balanceador de carga usará el primer certificado de su lista de certificados.
En el resto de las situaciones, el balanceador de carga selecciona un certificado mediante el siguiente proceso de coincidencia:
La coincidencia se realiza por el sufijo más largo en los atributos de nombre común (CN) y nombre alternativo del sujeto (SAN) del certificado, con preferencia por los certificados ECDSA sobre los certificados RSA.
Para ilustrar el método de coincidencia, supongamos que un proxy de destino hace referencia a los dos certificados siguientes:
Certificado A
- CN:
cats.pets.example.com - SANs:
cats.pets.example.com,*.pets.example.com,*.example.com
- CN:
Certificado B
- CN:
dogs.pets.example.com - SANs:
dogs.pets.example.com,*.pets.example.com,*.example.com
- CN:
Ahora, veamos las siguientes situaciones:
- Si el nombre de host SNI enviado por el cliente es
cats.pets.example.com, el balanceador de carga usa el certificado A. - Si el nombre de host SNI enviado por el cliente es
ferrets.pets.example.com, no hay ninguna coincidencia exacta, por lo que el balanceador de carga selecciona el certificado A o el certificado B, ya que ambos incluyen*.pets.example.comen su lista de SANs. No puedes controlar qué certificado se selecciona en esta situación.
- Si el nombre de host SNI enviado por el cliente es
Una vez que se ha seleccionado un certificado, el balanceador de carga envía al cliente ese certificado solo si el certificado seleccionado usa un algoritmo de clave pública que sea compatible con un cifrado enviado por el cliente en el
ClientHello. La negociación de TLS falla si el cliente no admite un paquete de cifrado que incluya el algoritmo de clave pública (ECDSA o RSA) del certificado que haya seleccionado el balanceador de carga.