☰

Поврежденное хранилище ключей (SSL) / обнаружение поддельных SSL-сертификатов

tag-icon • tag-icon linux ssl certificate
Поврежденное хранилище ключей (SSL) / обнаружение поддельных SSL-сертификатов

Отказ от ответственности: я новичок в SSL, нахожу его немного запутанным и мне нужен быстрый ответ.

Мне сказали, что есть опасность, что мое "хранилище ключей" может быть повреждено, поэтому я пытаюсь изучить его и разобраться в нем. Я использую Arch Linux.

Я вижу много забавных вещей в /etc/ssl/certs(и я полагаю, что вопрос № 1: «это и есть „хранилище ключей“?»), но этот список стал гораздо более разумным, когда я прошел по нему readlink -fи удалил дубликаты. Похоже, что все мои сертификаты из /usr/share/ca-certificates/. Большая их часть находится в mozilla/подкаталоге, но есть и другие подкаталоги, например:

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

Моя главная проблема в том, что я не знаю, как обнаружить подозрительный сертификат. Просто зайти на эти сайты кажется нелогичным (т. е. у них может быть то же вредоносное ПО, которое изначально потенциально повредило мое хранилище ключей).

ca-certificatesэто пакет, установленный моим менеджером пакетов; могу ли я просто удалить его и переустановить? Это безопасно?

ОБНОВЛЯТЬ:

Проблема, которая побудила это расследование, была в нераспознанном сертификате VeriSign. В частности, мне дали подпись с сертификатом, которого у меня не было (но, по-видимому, должен был быть) и которому я доверял.

Я нашел эту страницу на сайте VeriSign, на которой перечислен целый ряд сертификатов: http://www.verisign.com/support/roots.html ...и поэтому я начал проверять отпечатки пальцев установленных мной сертификатов по отношению к тем, что есть на сайте.

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

Результат: Один не совпадает. Звучит как важный: "VeriSign Class 1 Public Primary CA".

Осложнения: Мой менеджер пакетов сообщает мне, что контрольная сумма моих существующих сертификатов в порядке. Более того, отпечаток пальца на сертификате, который я должен иметь, совпадаетни одинни тот, что у меня есть, ни тот, что указан на сайте VeriSign.

решение1

Сертификаты, выдаваемые конечным объектам (например, веб-серверу) CA, обычно выдаются через промежуточный (т. е. цепной) CA. Для этого есть несколько причин. Когда CA впервые начали выдавать сертификаты таким образом, операторы серверов часто не могли установить промежуточный CA, из-за чего пользователи, у которых нет кэшированной (или установленной) копии цепного сертификата, оказывались в ситуации, когда у них были и корневой сертификат, и сертификат EE, но не было возможности их подключить. Сегодня это встречается гораздо реже, но, возможно, это проблема, с которой вы столкнулись — это из-за посещения публичного сервера? Если да, то я посмотрю для вас. Вы всегда можете посмотреть issuerName сертификата EE, который вы не можете проверить, и посмотреть, сможете ли вы найти соответствующий сертификат «промежуточного CA» на сайте VeriSign. Если это так, вы сможете проверить EE с помощью промежуточного, а промежуточный — с помощью корневого. Если вы собираетесь делать это вручную, я предлагаю вам также выполнить проверку сертификата — OCSP поддерживается VeriSign во всех их CA... большинство (все?) премиум-CA по этой форме проверки в реальном времени/близком к реальному времени... в противном случае следующими по эффективности были бы CRL.

Связанный контент