La distinción depende de algunos detalles sobre el certificado autofirmado y cómo reaccionarán el navegador y el sistema operativo.
Un certificado normal incluye una extensión Basic Constraints que contiene una bandera que indica si el certificado es para una CA o no; cuando el indicador es TRUE , el certificado se considera aceptable como emisor para otros certificados. Si la extensión falta por completo, el certificado debe considerarse como no CA.
Los certificados raíz de CA son "especiales"; No son verdaderos certificados. Son anclajes de confianza ; una TA es, nominalmente, una clave pública junto con un nombre. Es tradicional codificar anclajes de confianza como certificados, y como un certificado incluye un campo para una firma, algunos bytes deben almacenarse allí; allí nuevamente, la Tradición dice que haremos el certificado autofirmado . Sin embargo, nadie realmente comprueba esa firma; Los bytes basura de aproximadamente el tamaño correcto servirían igual de bien.
El punto difícil es que la interpretación de las extensiones de certificado, si las hay, que se encuentran en dicho "certificado de CA raíz", no es estándar. En particular, algunos CA históricos raíz datan de antes de la invención de la extensión Basic Constraints ; como certificados verdaderos, se interpretarían como "no CA", pero como son anclajes de confianza disfrazados de certificados, las reglas de interpretación normales no se aplican.
Por lo tanto, en algunos navegadores o sistemas operativos, un certificado que no es de CA (que carece de una extensión Basic Constraints , o incluso que presenta uno con el indicador cA establecido en FALSE ), una vez instalado en la tienda "CA raíz", muy bien puede comenzar a ser aceptado como un CA. Por lo tanto, la confidencialidad de la clave privada para cualquier certificado instalado en el almacén de confianza del usuario es bastante crítica.
¿Cuál es la diferencia en tu caso? Después de todo, en tu situación, hay dos opciones:
- Crea un certificado autofirmado para su servidor y el usuario lo instala como "de confianza".
- Crea un certificado CA autofirmado, que el usuario instala como "de confianza". Usted emite un certificado normal para su servidor con esta CA.
En ambos casos, el usuario entrega su seguridad a algún certificado suyo, que el usuario instala como "confiable". Entonces, ¿qué cambiaría?
La diferencia es que si utiliza una CA personalizada, puede almacenar la clave privada correspondiente con una buena protección. Por ejemplo, usted hace el negocio de CA en una computadora portátil que se mantiene fuera de línea en todo momento. No hay posibilidad de una explotación remota cuando no hay ninguna red. La CA raíz siempre debe estar fuera de línea y usarse solo como parte de los procedimientos manuales y las llaves USB para la transferencia de datos. Por otro lado, su servidor es, bueno, un servidor, por lo que está en línea y está intrínsecamente expuesto. Un atacante que piratee su servidor puede obtener una copia de la clave privada del servidor. Si la clave pública correspondiente se ha instalado como "raíz de confianza" en las máquinas de los usuarios, el atacante también gana mucho apalancamiento en estas máquinas.
Dicho brevemente, hacer una CA personalizada distinta del certificado del servidor (como se usa durante todo el día) permite una mejor protección de la clave privada y, por lo tanto, un menor riesgo de una escalada de potencia del atacante catastrófico.
Hay navegadores que no son tan vulnerables . Lo que realmente desea, con un certificado de servidor autofirmado, es que los usuarios confíen en ese certificado only para las conexiones SSL (no como CA), y solo para esa específica servidor. Firefox sabe cómo hacerlo; se denomina "excepción de seguridad" en la terminología de Firefox (consulte Preferencias - > Avanzadas - > Certificados - > Ver certificados, luego la pestaña "Servidores").