Мы добавили два сертификата CA - 1 корневой CA и 1 связанный промежуточный CA - в соответствующую ОС. доверенный магазин (/ и т.д. / SSL / сертификаты в нашем SuSE 11), потому что они не были предоставлены хранилищем доверенных сертификатов ОС (и, вероятно, никогда не будут, поскольку их нет в репо).
Недавно эти два сертификата исчезли после автоматического обновления, с очевидным эффектом, что клиенты больше не могли подключаться через tls.
Оглядываясь назад, мы не уверены, сделали ли мы обычную переработку записей, т.е.
# c_rehash /etc/ssl/certs
ЕСЛИ мы не выполняли повторное хеширование: могло ли это быть причиной удаления соответствующих сертификатов во время обновления?
Или всегда существует риск потери сертификатов, если они добавляются в хранилище доверенных сертификатов вручную (в рассматриваемой системе есть две библиотеки ssl: openssl и mozilla-nss)?
Вы не добавляете подчиненные центры сертификации в хранилище якорей доверия. Вы явно доверяете только корневому ЦС (якорь доверия) и неявно доверяете всем сертификатам, подписанным этим корневым ЦС или любым подчиненным ЦС этого Корня.
Если вы не можете построить цепочку между конечным объектом и якорем доверия, проверьте, представляет ли конечный объект все сертификаты между собой и якорем доверия. Видеть RFC 5256, раздел 7.4.2в частности certificate_list; который гласит, что все сертификаты (с необязательно Root) должны быть представлены в рукопожатии TLS.
Кроме того, клиенты Microsoft имеют возможность загружать недостающие сертификаты подчиненного ЦС, если URL-адрес сертификата указан в расширении AIA. Другие, такие как Mozilla Firefox, не будут использовать это расширение, ссылаясь на конфиденциальность пользователей в качестве оправдания.
Обратите внимание: если вы явно доверяете подчиненному ЦС, нет гарантии, что ваш клиент будет проверять отзыв своего сертификата. Если в будущем подчиненный будет скомпрометирован и отозван корневым центром сертификации, ваш клиент вполне может продолжать доверять ему. Это будет зависеть от конкретной реализации.