Motivo del nombre del sujeto en un certificado X.509

Su pregunta no parece ser la razón para el Nombre del sujeto, que es para identificar al sujeto, sino si funciona.

Gutmann escribe de manera colorida y detallada sobre cosas que en realidad no importan la mayor parte del tiempo, aunque cuando lo hacen es muy útil conocerlas. Sí, el esquema completo de nombres X.500 especificado para ser usado en los certificados X.509 en general es un monstruo. (Los diseños de los comités se representan tradicionalmente como camellos, aunque en este caso el pulpo parece apropiado).

Sin embargo, los certificados SSL / TLS y, en particular, los certificados web server , que es el único tipo con el que se encuentra la mayoría de las personas y el único caso específico en su pregunta: evite el problema utilizando realmente solo el atributo CommonName en el Asunto (nombre) debe contener un nombre de dominio (DNS) "totalmente calificado", también conocido como FQDN, o posiblemente (pero rara vez) una dirección IP; o en la actualidad generalmente la extensión SubjectAlternativeName para contener FQDN (s) y posiblemente direcciones IP. Aunque en la operación real (especialmente en su escala mundial actual) el DNS tampoco es perfecto, la mayoría de las personas pueden entenderlo fácilmente, y ciertamente el nombre de dominio en una URL http:// o https:// es bastante fácil de ver.

Una CA legítima debería emitir un certificado para un nombre de dominio dado solo al 'propietario' de ese dominio, aunque exactamente lo que cuenta como propiedad varía un poco. Puede visitar cada sitio de CA y consultar sus procesos y reglas de validación / aplicación, o consultar CA / Browser Forum en Requisitos de línea de base que establece los ( mínimo) estándares para que las CA se incluyan en los almacenes de confianza de la mayoría de los navegadores y sistemas operativos (al menos en los dispositivos de los consumidores) y, por lo tanto, en los que la mayoría de los usuarios terminan confiando.

Por lo tanto, si las CA hacen su trabajo y el atacante M no puede engañar o forzar a una CA de confianza para que le emita un certificado para el dominio D, lo que ha ocurrido en un pequeño número de casos, pero no tantos como para ser un gran problema: M no puede hacerse pasar por el sitio web del dominio D. A pesar de que le proporciona un DNS falso (o enrutamiento de IP, otra posibilidad), no puede presentar y probar la posesión de la clave para un certificado válido para D y falla el protocolo SSL / TLS.

A menos que, por supuesto, usted o el proveedor de su navegador o sistema operativo o dispositivo en su nombre, confíe en una CA que emita certificados falsos, por cualquiera de una variedad de razones. Por ejemplo, puede encontrar una docena de preguntas y respuestas aquí y otras páginas de pila sobre el fiasco Lenovo Superfish del año pasado: agregaron software a una gran cantidad de PC con Windows que utilizaron su propia CA para mitigar sus conexiones HTTPS con el fin declarado de proporcionar publicidad más relevante, pero expusieron la clave privada de CA (fija) y luego cualquier otra persona podría MitM. Tuvieron que publicar herramientas para eliminar el software ofensivo y el certificado de CA, y para detectar cualquiera que se deslizara a través del navegador y los fabricantes de sistemas operativos también pusieron en su lista negra su certificado.

Una de las razones por las que me importa es que dos entidades (Alice y Bob) pueden obtener certificados de una CA en la que confío, pero eso no significa que confíe en Alice de la misma manera que lo hago con Bob. Esto es relevante cuando piensa en servidores, pero es más claro cuando lo mira en el contexto de los certificados de cliente. El certificado se utiliza para autenticar al cliente y podemos hacerlo porque confiamos en la CA. Pero para saber qué derechos (si los hay) tiene ese cliente en un contexto dado, necesito saber quiénes son, no solo dónde se firmó su certificado. Simplemente saber que el CA no es suficiente para eso. Es cierto que si no tiene control sobre cómo se asignan los DN, realmente no puede contar con ellos, por lo que es importante entender qué nivel de identificación realmente necesita y si el certificado lo otorga de manera confiable.

  

"Los certificados digitales asignan claves públicas a las entidades"

Esto solo es cierto para los certificados de validación de la organización (OV) y la validación extendida (EV). El certificado de validación de dominio (DV) solo asigna claves públicas al "controlador" del nombre de dominio, pero no da ninguna indicación de la identidad del "controlador". Los procesos de validación de certificados OV y EV, por otro lado, están diseñados para vincular una clave pública con un nombre de dominio y una identidad de empresa / organización registrada.

Las Autoridades Públicas de Certificados solo tienen permitido poner información validada en el Asunto / DN del certificado. En todos los principales navegadores web, los usuarios expertos pueden ver todos estos detalles del certificado haciendo clic en en el botón de candado en la barra de URL .

Esta es la razón por la que el certificado DV solo contiene el nombre de dominio, ya que esa es la única información que la CA ha validado. Un certificado OV y EV contiene el nombre legal de la empresa, la jurisdicción legal de la empresa y, por lo general, el número de registro único de la empresa en una base de datos de empresas del gobierno (o en otras bases de datos de empresas calificadas). Este número de registro puede ser utilizado por usuarios expertos para buscar la empresa en las bases de datos relevantes.

A veces, el nombre legal de una empresa no es necesariamente el mismo que el público conoce, y es por eso que algunos sitios tienen nombres extraños en su certificado. En este caso, la empresa puede tener un nombre DBA (haciendo negocios como) también adjuntado en el certificado. La CA también debe poder validar este nombre alternativo antes de que lo pongan en el certificado.

El gran problema con DN es que hay poca estandarización sobre qué colocar allí. Esto significa que diferentes CA ponen cosas ligeramente diferentes en el DN. Si bien esto está bien cuando el DN es leído y verificado por el ser humano, la falta de un estándar hace que sea difícil para el programa automatizado usar el DN para averiguar a qué organización se refiere.