¿Un certificado SSL barato reduce la seguridad del cifrado?

Un certificado SSL barato no necesariamente reduce la seguridad del cifrado. Siempre que lo emita una autoridad de certificación de confianza para los navegadores de destino, se utilicen claves y algoritmos de firma adecuados y se implemente TLS correctamente, un certificado de bajo coste también puede proporcionar una protección fiable de las comunicaciones. No existe una relación directa y sencilla entre el precio del certificado y la solidez del cifrado de una conexión HTTPS.

Al elegir un certificado SSL barato, el personal de control de calidad y seguridad debe desglosar la cuestión: si el certificado es de confianza, qué configuración de cifrado utiliza realmente la conexión y si el certificado puede mantenerse vigente de forma continua. El precio puede influir en la verificación de identidad, la cobertura de dominios, el soporte técnico y los servicios de gestión, pero no demuestra directamente que la conexión sea más segura o más vulnerable.

Si ambos usan HTTPS, ¿qué se obtiene al pagar más?

Lo que suele llamarse «certificado SSL» se utiliza principalmente en sitios web junto con el protocolo TLS. El certificado acredita la asociación entre un dominio y una clave pública; después, el navegador y el servidor negocian los parámetros de conexión durante el protocolo de enlace. La transmisión de contenidos como páginas web y formularios de consulta está protegida por claves de sesión generadas durante esa negociación, no por el precio del certificado.

Por eso, la idea de que «un certificado más caro ofrece un mayor número de bits de cifrado» puede llevar a conclusiones erróneas. El algoritmo y la longitud de la clave pública del certificado, el algoritmo de firma del certificado, el método de intercambio de claves TLS y el algoritmo de cifrado de sesión son aspectos distintos que deben comprobarse. La indicación «cifrado de alta seguridad» en la página de un producto no basta para determinar la seguridad de la conexión final.

La diferencia de precio entre certificados puede deberse a los siguientes aspectos:

• Alcance de la verificación de identidad: DV verifica el control del dominio; OV y EV también incluyen la verificación de la identidad de la organización. Una verificación de identidad más exhaustiva no aumenta automáticamente la solidez del cifrado de la sesión.
• cobertura de dominios: los certificados para un solo dominio, para varios dominios y los comodín tienen alcances distintos. Al comprar, conviene compararlos con la lista real de sitios y subdominios.
• Servicios de entrega y operación: la asistencia para la implementación, los avisos de vencimiento, la renovación automática y la respuesta ante incidencias, entre otros, influyen en los costes de gestión y la continuidad del negocio de la empresa.

Para un sitio corporativo informativo, un sitio de consultas de comercio exterior o una página de destino de marketing, si no existen requisitos adicionales de presentación de la identidad de la organización o exigencias contractuales, un certificado DV de confianza y correctamente configurado puede satisfacer las necesidades de protección de las comunicaciones HTTPS. En actividades que impliquen pagos o datos sensibles, también hay que evaluar los requisitos del proveedor de servicios de pago y las normas aplicables; no se debe dar por superada la auditoría de seguridad basándose únicamente en el nivel del certificado.

Para validar un certificado de bajo coste, compruebe primero la conexión real

La validación de seguridad debe realizarse en los dominios y puntos de acceso disponibles en línea. Que el archivo del certificado sea correcto no significa que todas las conexiones ofrecidas por el servidor, la CDN y el proxy inverso también lo sean.

Compruebe primero la confianza y la identidad. Confirme que el dominio figura en el campo de nombres alternativos del sujeto del certificado, que el certificado está dentro de su periodo de validez, que el servidor proporciona los certificados intermedios necesarios y que los navegadores y sistemas utilizados habitualmente por los clientes de destino pueden establecer una cadena de certificados de confianza. Que el acceso funcione desde un ordenador de la oficina no significa que no haya problemas de compatibilidad en los dispositivos de los clientes de otros países.

Compruebe después los protocolos y algoritmos. Centre las comprobaciones de implementación en TLS 1.2 y TLS 1.3, y desactive las versiones obsoletas de SSL y las primeras versiones de TLS. Para TLS 1.2, compruebe también los conjuntos de cifrado y dé prioridad a métodos de intercambio de claves que admitan confidencialidad directa y a algoritmos de cifrado autenticado adecuados. También deben verificarse por separado los algoritmos de clave pública y de firma del certificado; no dé por superadas todas las comprobaciones solo porque se admita «TLS 1.3».

Por último, compruebe dónde termina TLS. Si se utiliza una CDN o un proxy en la nube, el certificado que suele ver el navegador es el del nodo perimetral. Si la conexión entre el nodo perimetral y el servidor de origen utiliza HTTP sin cifrar, o está cifrada pero no valida el certificado, los visitantes aún pueden ver una página HTTPS aparentemente normal. Por eso, hay que comprobar por separado el punto de acceso público y la conexión de retorno al servidor de origen.

El registro de validación debe incluir, como mínimo, el dominio, la hora de la comprobación, la cadena de certificados, el protocolo negociado y los resultados de las configuraciones clave. Si los sitios multilingües, las tiendas en línea y las páginas de destino de anuncios están distribuidos en distintas plataformas, hay que comprobar cada punto de acceso real para evitar declarar que todo está conforme tras revisar únicamente el sitio principal.

Los riesgos de las opciones de bajo coste suelen estar en la entrega y la renovación

El bajo precio no constituye por sí mismo un defecto, pero un alcance de compra poco claro puede generar riesgos. Algunas ofertas solo incluyen la emisión del certificado; la instalación, la renovación automática y la resolución de incidencias quedan a cargo de la empresa. Si esta no cuenta con las capacidades operativas necesarias, el ahorro en la compra puede convertirse en costes por interrupciones del sitio y resolución de problemas.

También hay que definir claramente quién se responsabiliza de gestionar la clave privada. Esta debe generarse y almacenarse en un entorno controlado, con acceso restringido, y no debe circular sin control por herramientas de mensajería o correo electrónico. Si el proveedor del sitio web la custodia, deben acordarse los procedimientos para acceder a la clave, gestionar cambios de personal, revocar el certificado y emitir uno nuevo. Comprar un certificado más caro tampoco puede compensar la filtración de una clave privada.

Es necesario verificar todo el proceso de renovación automática: si la validación puede completarse a tiempo, si se obtiene un certificado nuevo, si se instala en todos los nodos y si el servicio lo carga correctamente. Una notificación de «renovación correcta» no es suficiente; la supervisión también debe comprobar el certificado que se ofrece realmente en Internet. Los certificados de corta duración dependen especialmente de la automatización, por lo que la empresa debe reservar tiempo para gestionar fallos de validación, cambios de permisos y ajustes en la resolución de dominios.

Además, HTTPS protege los datos durante la transmisión. No corrige las vulnerabilidades del sitio, no impide el uso de contraseñas débiles en el panel de administración ni garantiza la seguridad de los datos de formularios una vez almacenados. Tras validar el certificado de un sistema de consultas o una tienda en línea, todavía hay que comprobar por separado los permisos de la aplicación, el almacenamiento de datos y los scripts de terceros.

¿Cuándo se puede elegir una opción barata y cuándo merece la pena pagar más?

Si un certificado de bajo coste cumple los requisitos de compatibilidad con los sistemas de confianza, cobertura de dominios, configuración criptográfica y gestión de renovaciones, la empresa puede utilizarlo. Al comparar ofertas, pida a los proveedores que detallen el tipo de certificado, los dominios cubiertos, el alcance de la implementación, quién se responsabiliza de la renovación y cómo responden ante incidencias. Así evitará comparar como si fueran equivalentes el «coste del certificado» y el «coste de la gestión integral».

Si la empresa tiene muchos sitios, publica cambios con frecuencia o carece de personal especializado en operaciones, puede resultar más valioso pagar más por una gestión unificada, una implementación automática y un servicio de respuesta claramente definido. Si la actividad requiere realmente la verificación de la identidad de la organización, debe elegirse el tipo de certificado correspondiente.

La evaluación de compra debe permitir responder finalmente a estas preguntas: ¿pueden los clientes de destino confiar en esta conexión?, ¿es adecuada la configuración de cifrado?, ¿quién se responsabiliza de la clave privada?, ¿se podrá sustituir el certificado antes de que caduque? Si todas estas preguntas tienen respuestas verificables, una opción de bajo coste puede ser una elección razonable para reducir costes. Recibir únicamente un certificado y una dirección HTTPS no basta para superar una validación de seguridad.