El número de nombres es una cantidad muy pequeña de datos en general; Si se empuja a entregar el certificado sobre un umbral de tamaño de paquete, el retraso agregado no afectará perceptiblemente a los usuarios humanos que tienen conexiones de banda ancha u otras conexiones de alta velocidad. La computadora receptora tendrá hasta 14 cadenas adicionales para escanear; de nuevo, una cantidad imperceptible de gastos generales para cualquier usuario humano en particular.
Qualys SSL Labs realizó una encuesta de certificados hace unos años, y presentó su Los resultados se encuentran en Blackhat . Encontraron muchos problemas que contribuyeron a problemas de rendimiento. En el caso de varios nombres de dominio, encontraron un certificado con 354 nombres de dominio no relacionados, ¡y el certificado fue de 8.2KB de largo! Así que sí, hay una línea que probablemente no quieras cruzar, y 354 parece cruzarla.
Otro problema común que encontraron impactando en el rendimiento fue que algunas cadenas de validación eran demasiado largas. Hace mucho tiempo, algunos arquitectos de PKI defendían un enfoque de múltiples niveles, donde cada certificado estaría firmado por una CA raíz, una o dos CA subordinadas y una o dos CA de políticas. La ejecución de RSA math en cuatro pasos de validación diferentes es lo que atasca a los clientes, mucho más que el tamaño de los certificados. (¡Qualys encontró 8 certificados con una profundidad de firma de 6!) Para mantener el rendimiento lo más alto posible, mantenga la cadena de firmas lo más corta posible.
También vieron que el 43% de los servidores enviaban demasiados certificados. Normalmente, incluiría el certificado del servidor y cualquier certificado de firma intermedio necesario para validarlo hasta la raíz (el certificado raíz normalmente se encuentra en el navegador, a menos que sea un certificado autofirmado). Muchos sitios desperdiciaban ancho de banda al incluir certificados adicionales No es necesario validar su sitio. ¡Un sitio envió un archivo de certificado que contenía 116 certificados!
Finalmente, encontraron muchos certificados que eran simplemente malos. Fueron autofirmados, caducaron, usaron algoritmos débiles o tuvieron otros defectos que hicieron que su protección fuera menos que óptima. De todas las cosas que necesita lograr con un certificado, la seguridad es la número uno, el rendimiento no lo es. Así que recomiendo usar su herramienta de análisis y descubrir qué piensan de su configuración. enlace . Ejecuto esta comprobación cada vez que cambio la configuración de mi servidor y después de actualizar mi certificado.
ACTUALIZACIÓN: cambié a usar un script nmap para verificar mi servidor. Asegúrese de que está ejecutando una versión actualizada de nmap, luego ejecute nmap --unprivileged -sV --script ssl-enum-ciphers -p 433 example.org . Esto mostrará una lista de los cifrados admitidos por el servidor y proporcionará un grado de letra que indica la seguridad de cada uno, y un grado general para su servidor. Bueno para encontrar cosas como versiones desactualizadas y no seguras de SSL / TLS, cifrados de 64 bits, etc. Y puede ejecutarlo en cualquier host y puerto, para que pueda probar servidores de aplicaciones, servicios web, servidores internos que están detrás de sus firewalls. , etc.