В настоящее время я использую самоподписанный сертификат для внутренней разработки и хочу убедиться, что знаю о любых реальных рисках безопасности.
Вот как я все устроил.
Корневой сертификат
Сертификат для личного сайта
Существуют ли какие-либо другие данные, кроме закрытого ключа для корневого сертификата, которые представляют угрозу безопасности, если их кто-то завладеет?
Собственный самозаверяющий сертификат не представляет опасности, если люди знают, что это самоподписанный сертификат. Самый большой риск они представляют для клиентов.
Например, когда вы распространяете клиенту и устанавливаете начальное соединение, вы должны убедиться, что они подтвердили его действительность, но, кроме этого, единственное преимущество использования стороннего поставщика состоит в том, что вам не нужно беспокоиться о злоумышленник притворяется вашим сервером, но это означает, что вы были бы взломаны с самого начала, а также столкнулись бы с множеством других проблем.
Итак, самая большая угроза безопасности заключается в том, что люди не сообщают, что это самозаверяющий сертификат, и не проверяют его местоположение. По крайней мере, по моему мнению. Кроме того, они не управляются ЦС, поэтому вы не можете отозвать сертификаты, и вам придется фактически переделать ключ, если что-то будет скомпрометировано - но для внутренней системы я бы действительно не беспокоился об этом.
Сертификат вашего сайта (+ закрытый ключ) следует рассматривать как любой сертификат сайта. Если кто-то получит закрытый ключ, он сможет выдать себя за ваш сайт. Существует небольшая разница в том, как вы должны доверять службе хостинга сертификат, выданный коммерческим центром сертификации.
Риски здесь смягчаются тем фактом, что, поскольку вы создали свой собственный ЦС, мало кто будет доверять этому ЦС по умолчанию. Это риск, который фактически ограничен теми, кто решил доверять вашему ЦС.
То же самое относится к закрытому ключу CA. Тот, кто завладеет его закрытым ключом, может выдать любой сертификат.
Самые большие проблемы возникают из-за того, что пользовательские интерфейсы имеют тенденцию относиться ко всем доверенным центрам сертификации одинаково (за исключением сертификатов EV) или очень похожим образом, если пользователь не обращает внимания. В результате, если злоумышленник (а) имел закрытый ключ вашего ЦС и (б) знал пользователя, который доверяет этому ЦС-сертификату, он может создать сертификат, действительный для любого веб-сайта, который они хотят.
Ваша оценка рисков должна учитывать, кто решит доверять этому внутреннему ЦС. Коммерческие центры сертификации, как правило, имеют строгие политики в отношении защиты своих закрытых ключей (обычно не извлекаемое хранилище на смарт-картах и т.п.): это часто является требованием, которое необходимо одобрить для включения в большинство браузеров.
Точнее о «другой информации». При проектировании CA может быть важно иметь политику относительно того, какие атрибуты и как, например, структурированы DN субъектов. Я знал несколько центров сертификации, которые никогда не раскрывали личность пользователя явно в сертификате (который обычно является общедоступным и часто виден во время рукопожатия для перехватчика), поэтому DN субъекта был просто внутренним идентификатором, известным CA ( и, возможно, связаны с фактическим именем между службой и центром сертификации с помощью зашифрованного обратного канала или аналогичного механизма).