☰

Almacén de claves (SSL) dañado/detección de certificados SSL falsos

tag-icon • tag-icon linux ssl certificate
Almacén de claves (SSL) dañado/detección de certificados SSL falsos

Descargo de responsabilidad: soy nuevo en SSL, lo encuentro un poco confuso y necesito una respuesta lo antes posible.

Me dijeron que existía el peligro de que mi "almacén de claves" estuviera dañado, así que estoy tratando de examinarlo y darle sentido. Estoy usando Arch Linux.

Veo muchas cosas divertidas /etc/ssl/certs(y supongo que la pregunta número 1 es: "¿Es esto lo que es el 'almacén de claves'?"), pero esa lista se volvió mucho más sensata cuando la pasé toda readlink -fy eliminé los duplicados. Parece que todos mis certificados son de /usr/share/ca-certificates/. La mayor parte de ellos están en el mozilla/subdirectorio, pero hay otros subdirectorios como:

brazil.gov.br/
cacert.org/
debconf.org/
gouv.fr/
signet.pl/
spi-inc.org/

Mi principal problema es que no sé cómo detectar un certificado sospechoso. Simplemente ir a estos sitios parece contrario a la intuición (es decir, pueden tener el mismo malware que potencialmente corrompió mi almacén de claves en primer lugar).

ca-certificateses un paquete instalado por mi administrador de paquetes; ¿Puedo simplemente purgarlo y luego reinstalarlo? ¿Es seguro hacerlo?

ACTUALIZAR:

El problema que motivó esta investigación fue un certificado de VeriSign no reconocido. Específicamente, me dieron una firma con un certificado que no tenía (pero presumiblemente debería) tener y en el que confiaba.

Encontré esta página en el sitio de VeriSign que enumera una gran cantidad de certificados: http://www.verisign.com/support/roots.html ...y entonces comencé a comparar las huellas digitales de los certificados que instalé con las del sitio.

for cert in /etc/ssl/certs/Veri[Ss]ign*; do
    printf "%s: " $cert
    openssl x509 -noout -in $cert -fingerprint
done

El resultado: uno no coincide. También parece importante: "CA primaria pública de clase 1 de VeriSign".

Complicaciones: Mi administrador de paquetes me dice que la suma de verificación de mis certificados existentes está bien. Además, la huella digital en el certificado que se supone que debo tener coincideniel que tengo ni el que aparece en el sitio de VeriSign.

Respuesta1

Los certificados emitidos a entidades finales (por ejemplo, servidor web) por una CA generalmente se emiten a través de una CA intermedia (también conocida como cadena). Hay varias razones para esto. Cuando las CA comenzaron a emitir certificados de esta manera, era muy común que los operadores de servidores no instalaran la CA intermedia, visitando así a los usuarios que no tenían una copia en caché (o instalada) del certificado de cadena en una situación en la que tenían tanto el certificado raíz como el certificado raíz. y el certificado EE pero no hay forma de conectarlos. Esto es mucho menos común hoy en día, pero puede ser el problema al que se enfrenta (se debe a visitar un servidor público). Si es así, lo comprobaré. Siempre puede echar un vistazo al nombre del emisor del certificado EE que no puede verificar y ver si puede encontrar un certificado de "CA intermedia" coincidente en el sitio de VeriSign. De ser así, debería poder verificar el EE con el certificado EE intermedio y el intermedio con la raíz Si va a hacer esto manualmente, le sugiero que también realice la validación del certificado: VeriSign admite OCSP en todas sus CA... la mayoría (¿todas?) de las CA premium en esta forma de tiempo real/casi real. validación de tiempo... de lo contrario, lo siguiente mejor serían las CRL.

información relacionada