Forma correcta de obtener certificados de CA para verificación

He visto esto hecho con autenticación de clave SSH por teléfono. El procedimiento fue para mí generar claves privadas y públicas y enviar la pública al proveedor de alojamiento por correo electrónico. Luego me llamaban por teléfono, leían la mitad de la huella dactilar y me exigían que leyera la otra mitad. Si coincidieran, pondrían mi clave pública en el servidor y podría iniciar sesión.

Es poco probable que esto sea práctico para verificar los certificados SSL de Facebook, sin embargo, el punto clave es que la verificación se realizó utilizando un método diferente al de la transferencia original, lo que hace que el trabajo de un posible atacante sea mucho más difícil.

Si puede solicitar el certificado utilizando una computadora diferente en una conexión a Internet diferente y compararlo con el que tiene, puede estar razonablemente seguro de que tiene el certificado correcto.

SSL tiene cadenas de confianza que las claves SSH no tienen, por lo que debería ser adecuado verificar los certificados de CA raíz y usarlos para verificar el certificado de destino.

En Ubuntu, hay un paquete ca-certificates que contiene los certificados en los que confían los mantenedores de Ubuntu. Los propios certificados se pueden encontrar en /usr/share/ca-certificates . Otras distribuciones de Linux tendrán paquetes similares.

Solo estoy leyendo esto y veo que tienes una respuesta que funciona para ti ... pero la respuesta realmente nerd es "depende". Si está intentando obtener un certificado de servidor SSL, cualquier acceso al servidor SSL le proporcionará el certificado de la misma manera: el servidor lo ofrecerá y dará prueba de su posesión como parte del protocolo SSL.

La decisión crítica es decidir si confiar o no en el certificado.

Un certificado tiene varios elementos:  - Información sobre su propietario.  - Información sobre su emisor.  - Una cadena de certificados que conduce a un emisor raíz.  - información de validez.

Una comprobación fácil es "es el certificado válido"; si puede ver los datos, puede ver las fechas de inicio y finalización de la validez. Dependiendo de lo que estés haciendo, puedes verificar a mano o codificar algo para verificar cada conexión.

A continuación, es posible que desee averiguar si confía en su emisor. Los certificados autofirmados son intrínsecamente menos confiables, porque cualquiera puede firmarlos. Los navegadores tienen un almacén de certificados de confianza de "buenas apuestas": emisores certificados que producen certificados comercialmente. Pero existen otros emisores de pago, así como productos corporativos internos que pueden ser perfectamente confiables para sus propósitos. El paso 1 es decidir en qué certificado del emisor se debe confiar, lo que significa configurar un almacén de confianza localmente. El Paso 2 está verificando que el certificado presentado por el servidor no miente cuando reclama un emisor, eso es una verificación criptográfica en la firma digital del certificado. El paso 2 debe repetirse para cada certificado en la cadena ...

Por último, para mayor seguridad, es posible que desee verificar que el certificado no esté revocado. Esto se puede hacer a través de un par de protocolos PKI, o manualmente en la mayoría de los sitios web de emisores comerciales. Un certificado puede contener información sobre cómo verificar su estado como parte de su información empaquetada (un punto de distribución de CRL o una extensión AIA) o puede que tenga que buscar en Google para encontrar la respuesta.

El alcance de la comprobación de un certificado de servidor debe ser acorde con el riesgo de la información que le dará al servidor.

Se firma un certificado. Esto significa que viene con su propia seguridad. La validez de un certificado proviene de su firma por parte de una autoridad de certificación, no de la forma en que lo obtiene. Durante los primeros pasos de una conexión SSL / TLS (el "protocolo de enlace"), el cliente debe obtener un conocimiento confiable de la clave pública del servidor; el cliente puede hacerlo de la forma que crea conveniente, pero a menudo implica encontrar una ruta de certificado , es decir, un conjunto de certificados que culminan en un certificado que contiene el nombre del servidor y la clave pública del servidor. Para suavizar las operaciones, el servidor incluye una ruta potencial en uno de los mensajes de intercambio que envía al cliente.

Validación de una ruta de certificado implica verificar la firma de cada certificado, con respecto a la clave pública que figura en el certificado anterior (también hay muchas otras cosas que se verifican, consulte la sección 6 de RFC 5280 si está realmente aburrido un día). El punto de la firma es proteger contra la alteración y demostrar la procedencia. Cómo obtuvo el certificado es irrelevante; para el caso, podría haber sido entregado a usted por el mismo Diablo, no afectará la seguridad.

Sin embargo, todavía tienes que estar en algún lugar. Como se mencionó anteriormente, la firma de cada certificado en la ruta debe verificarse con la clave pública contenida en el certificado anterior . ¿Cómo verificamos la firma en el certificado first en la ruta? Para eso, necesitamos un ancla de confianza : esa es una clave de nombre y pública que se conoce a priori , por ejemplo. está integrado en el software cliente (después de todo, usted confía en el software en sí mismo para no registrar todos los datos intercambiados y sus pulsaciones de teclas, por lo que también puede confiar en el almacenamiento de algunas claves públicas). Los anclajes de confianza se codifican tradicionalmente como certificados raíz : no son certificados reales (su firma es ficticia o, a menudo, una "autofirma" que no tiene ninguna función, excepto rellenar el espacio para una firma en un formato de certificado ) pero aún asumen el formato externo (como un grupo de bytes) de un certificado.

Los "certificados raíz" deben obtenerse de forma segura, ya que no se pueden verificar de ninguna manera; Toda tu confianza viene de ellos. A continuación se muestra una lista de (al comienzo de) la lista de certificados raíz incorporados en Firefox (es decir, los certificados que el Sr. Firefox encontró adecuados para las cosas en su navegador y que yo, siendo un usuario vago, "confío" por defecto):