Зачем нужны самозаверенные сертификаты открытого ключа
Начало:
1. Криптография: простейшие термины этой науки
2. Система шифрования с открытым ключом
3. Зачем нужны центры сертификации при асимметричном шифровании
Веб-приложения по определению являются приложениями (программами), созданными по архитектуре «клиент-сервер». «Клиентом» при этом очень часто является браузер пользователя веб-приложения. Между браузером и веб-сервером налаживается общение, которое в наше время часто шифруется (применяется система шифрования с открытым ключом). Большинство веб-сайтов (веб-приложений) сегодня работает с клиентами по протоколу HTTPS, пришедшему на смену протоколу HTTP (формально HTTPS - тот же протокол HTTP, только при шифрованном обмене сообщениями между клиентом и веб-сервером).
Веб-разработчики часто разрабатывают веб-приложения локально, на одном компьютере. При этом веб-сервер и клиент находятся на одном и том же компьютере, компьютере веб-разработчика. Для тестирования созданного веб-приложения в такой ситуации следует обеспечить условия, похожие на те, в которых веб-приложение будет работать, когда оно будет развернуто на рабочем сервере (серверах). То есть для тестирования следует обеспечить и общение между веб-сервером и клиентом (браузером) по протоколу HTTPS (с применением системы шифрования с открытым ключом).
А для обеспечения общения по протоколу HTTPS на веб-сервере требуется наличие сертификата открытого ключа. Вообще, как было описано в предыдущем посте, сертификаты открытого ключа выдают центры сертификации. В большинстве из них услуга выдачи сертификата платная, но существуют и некоммерческие центры сертификации (например, «Let’s Encrypt»).
Однако, при попытке получить сертификат открытого ключа в центре сертификации для имени хоста «localhost», которое обычно используется при локальной веб-разработке, возникает еще одна проблема: центр сертификации не выдает сертификаты открытого ключа для имени хоста «localhost». Например, об этом можно прочитать на сайте центра сертификации «Let’s Encrypt»:
https://letsencrypt.org/docs/certificates-for-localhost/
Причина проста: имя хоста «localhost» не может принадлежать кому-то конкретно (что, в частности, удостоверяется выдаваемым сертификатом открытого ключа), потому что это имя используется на всех локальных компьютерах для обозначения локального сайта (сайта, доступного только в рамках данного компьютера). Для локальной разработки по ссылке выше рекомендуют использовать самозаверенный сертификат.
Что такое самозаверенный сертификат
Самозаверенный (самоподписанный) сертификат по-английски называют «self-signed certificate».
https://ru.wikipedia.org/wiki/Самозаверенный_сертификат
https://en.wikipedia.org/wiki/Self-signed_certificate
Из названия этого сертификата уже должно быть примерно понятно (с учетом информации, изложенной в предыдущих постах этой серии постов), что он собой представляет и как его получить.
Как было описано в предыдущем посте, обычно в сертификате открытого ключа, полученном от центра сертификации, присутствует сам открытый ключ, информация о его владельце и электронная подпись центра сертификации (напомню, электронная подпись выполняется закрытым (секретным) ключом центра сертификации, а может быть проверена открытым ключом центра сертификации, доступным всем).
Таким образом, мы можем получить самозаверенный сертификат своего открытого ключа, поместив в файл сертификата свой открытый ключ, информацию о себе и подписав полученный сертификат своим закрытым (секретным) ключом.
Как создать самозаверенный сертификат
Файл сертификата не создается вручную, для этого используется соответствующее программное обеспечение. В операционных системах «Windows» для этого удобно использовать соответствующий командлет программы-оболочки «PowerShell»:
https://learn.microsoft.com/en-us/powershell/module/pki/new-selfsignedcertificate
Еще следует упомянуть широко известную кроссплатформенную («Linux», «macOS», «Windows») библиотеку и набор инструментов «OpenSSL». Ее тоже можно использовать для создания самозаверенного сертификата открытого ключа.
Почему самозаверенные сертификаты не используют на рабочих веб-серверах
Самозаверенный сертификат предполагается к использованию только в случаях, подобных описанному выше. То есть, например, для тестирования разрабатываемого веб-приложения на локальном веб-сервере. При этом сервер и клиент, в принципе, являются одним и тем же персонажем - веб-разработчиком, который выступает то в роли разработчика, то при тестировании - в роли клиента. В такой ситуации вообще не существует какого-то постороннего злоумышленника, который захочет взломать шифрованное общение между сервером и клиентом. Только сам разработчик может выступить в роли злоумышленника, если захочет протестировать устойчивость создаваемого веб-приложения ко взлому. Ситуация полностью находится под контролем веб-разработчика.
При использовании самозаверенного сертификата на рабочем веб-сервере он не обеспечит того, для чего сертификаты были созданы - безопасности шифрованного обмена. Шифрованный обмен с самозаверенным сертификатом не защищен от атаки посредника, описанной в предыдущем посте. Злоумышленник может подменить самозаверенный сертификат своим самозаверенным сертификатом и после этого сможет читать сообщения. Сертификат открытого ключа, полученный от центра сертификации, злоумышленник подменить не сможет, так как открытый ключ центра сертификации имеет широкую известность, его подмена сразу же будет раскрыта.
Кроме этого, самозаверенный сертификат невозможно отозвать в случае обнаружения компрометации сертификата. Не существует общеизвестной базы данных с самозаверенными сертификатами открытого ключа, в которую можно сообщить об отзыве данного самозаверенного сертификата. В случае центра сертификации этот центр имеет общеизвестную базу данных, в которую можно занести факт компрометации сертификата. Все пользователи сертификатов открытого ключа смогут своевременно получить информацию о компрометации выданного центром сертификата открытого ключа и выведут его из употребления.
Корневые сертификаты
В общем, про самозаверенные сертификаты я всё, что хотел, рассказал. Но в этом контексте дополнительно не повредит знать о том, что такое «корневой сертификат».
https://en.wikipedia.org/wiki/Root_certificate
Центр сертификации выдает очень много сертификатов открытого ключа, которые подписывает своей электронной подписью с помощью своего закрытого ключа. В зависимости от величины центра сертификации он может выдавать тысячи, сотни тысяч или даже миллионы сертификатов открытого ключа. Если закрытый ключ центра сертификации будет скомпрометирован, то как следствие будут скомпрометированы и все подписанные этим закрытым ключом выданные сертификаты открытого ключа. Это может привести к падению всего веба.
Для смягчения вышеописанной опасности главный центр сертификации может делегировать все полномочия (или только их часть) второстепенным центрам сертификации. Те, в свою очередь, могут делегировать свои полномочия еще более мелким центрам сертификации и так далее. При компрометации закрытого ключа любого из центров сертификации этой системы будет скомпрометирована только небольшая часть всех выданных сертификатов открытого ключа, а не все выданные сертификаты. Так получается смягчение негативных последствий.
Описанная цепочка делегирования полномочий от главного центра сертификации к второстепенному, а затем от второстепенного к третьестепенному и так далее, называется «цепочкой доверия».
https://ru.wikipedia.org/wiki/Цепочка_доверия
https://en.wikipedia.org/wiki/Chain_of_trust
Первичный (главный) центр сертификации в цепочке доверия называют корневым центром сертификации, так как от него начинается цепочка доверия (цепочка делегирования полномочий по выдаче сертификатов открытого ключа).
Для проверки сертификата открытого ключа, выданного одним из второстепенных (не корневых) центров сертификации в цепочке доверия проверяется сертификат самого этого центра сертификации, подписанный более высшим в цепочке центром сертификации. Затем проверяется сертификат открытого ключа более высшего в цепочке центра сертификации и так далее, до корневого центра сертификации.
Сертификат открытого ключа корневого центра сертификации называют «корневым сертификатом» в данной цепочке доверия. Корневой сертификат является самозаверенным сертификатом, то есть он содержит открытый ключ корневого центра сертификации, информацию о корневом центре сертификации и электронную подпись корневого центра сертификации, выполненную с помощью закрытого ключа корневого центра сертификации.
В случае корневого сертификата его защитой от подделки со стороны злоумышленников является его широкая распространенность и широкая известность. Поэтому случай подделки корневого сертификата будет сразу же разоблачен, в отличие от самозаверенного сертификата обычного веб-разработчика (самозаверенный сертификат обычного веб-разработчика не обладает широкой распространенностью и широкой известностью, его подделка если и будет разоблачена, то нескоро).
1. Криптография: простейшие термины этой науки
2. Система шифрования с открытым ключом
3. Зачем нужны центры сертификации при асимметричном шифровании
Веб-приложения по определению являются приложениями (программами), созданными по архитектуре «клиент-сервер». «Клиентом» при этом очень часто является браузер пользователя веб-приложения. Между браузером и веб-сервером налаживается общение, которое в наше время часто шифруется (применяется система шифрования с открытым ключом). Большинство веб-сайтов (веб-приложений) сегодня работает с клиентами по протоколу HTTPS, пришедшему на смену протоколу HTTP (формально HTTPS - тот же протокол HTTP, только при шифрованном обмене сообщениями между клиентом и веб-сервером).
Веб-разработчики часто разрабатывают веб-приложения локально, на одном компьютере. При этом веб-сервер и клиент находятся на одном и том же компьютере, компьютере веб-разработчика. Для тестирования созданного веб-приложения в такой ситуации следует обеспечить условия, похожие на те, в которых веб-приложение будет работать, когда оно будет развернуто на рабочем сервере (серверах). То есть для тестирования следует обеспечить и общение между веб-сервером и клиентом (браузером) по протоколу HTTPS (с применением системы шифрования с открытым ключом).
А для обеспечения общения по протоколу HTTPS на веб-сервере требуется наличие сертификата открытого ключа. Вообще, как было описано в предыдущем посте, сертификаты открытого ключа выдают центры сертификации. В большинстве из них услуга выдачи сертификата платная, но существуют и некоммерческие центры сертификации (например, «Let’s Encrypt»).
Однако, при попытке получить сертификат открытого ключа в центре сертификации для имени хоста «localhost», которое обычно используется при локальной веб-разработке, возникает еще одна проблема: центр сертификации не выдает сертификаты открытого ключа для имени хоста «localhost». Например, об этом можно прочитать на сайте центра сертификации «Let’s Encrypt»:
https://letsencrypt.org/docs/certificates-for-localhost/
Причина проста: имя хоста «localhost» не может принадлежать кому-то конкретно (что, в частности, удостоверяется выдаваемым сертификатом открытого ключа), потому что это имя используется на всех локальных компьютерах для обозначения локального сайта (сайта, доступного только в рамках данного компьютера). Для локальной разработки по ссылке выше рекомендуют использовать самозаверенный сертификат.
Что такое самозаверенный сертификат
Самозаверенный (самоподписанный) сертификат по-английски называют «self-signed certificate».
https://ru.wikipedia.org/wiki/Самозаверенный_сертификат
https://en.wikipedia.org/wiki/Self-signed_certificate
Из названия этого сертификата уже должно быть примерно понятно (с учетом информации, изложенной в предыдущих постах этой серии постов), что он собой представляет и как его получить.
Как было описано в предыдущем посте, обычно в сертификате открытого ключа, полученном от центра сертификации, присутствует сам открытый ключ, информация о его владельце и электронная подпись центра сертификации (напомню, электронная подпись выполняется закрытым (секретным) ключом центра сертификации, а может быть проверена открытым ключом центра сертификации, доступным всем).
Таким образом, мы можем получить самозаверенный сертификат своего открытого ключа, поместив в файл сертификата свой открытый ключ, информацию о себе и подписав полученный сертификат своим закрытым (секретным) ключом.
Как создать самозаверенный сертификат
Файл сертификата не создается вручную, для этого используется соответствующее программное обеспечение. В операционных системах «Windows» для этого удобно использовать соответствующий командлет программы-оболочки «PowerShell»:
https://learn.microsoft.com/en-us/powershell/module/pki/new-selfsignedcertificate
Еще следует упомянуть широко известную кроссплатформенную («Linux», «macOS», «Windows») библиотеку и набор инструментов «OpenSSL». Ее тоже можно использовать для создания самозаверенного сертификата открытого ключа.
Почему самозаверенные сертификаты не используют на рабочих веб-серверах
Самозаверенный сертификат предполагается к использованию только в случаях, подобных описанному выше. То есть, например, для тестирования разрабатываемого веб-приложения на локальном веб-сервере. При этом сервер и клиент, в принципе, являются одним и тем же персонажем - веб-разработчиком, который выступает то в роли разработчика, то при тестировании - в роли клиента. В такой ситуации вообще не существует какого-то постороннего злоумышленника, который захочет взломать шифрованное общение между сервером и клиентом. Только сам разработчик может выступить в роли злоумышленника, если захочет протестировать устойчивость создаваемого веб-приложения ко взлому. Ситуация полностью находится под контролем веб-разработчика.
При использовании самозаверенного сертификата на рабочем веб-сервере он не обеспечит того, для чего сертификаты были созданы - безопасности шифрованного обмена. Шифрованный обмен с самозаверенным сертификатом не защищен от атаки посредника, описанной в предыдущем посте. Злоумышленник может подменить самозаверенный сертификат своим самозаверенным сертификатом и после этого сможет читать сообщения. Сертификат открытого ключа, полученный от центра сертификации, злоумышленник подменить не сможет, так как открытый ключ центра сертификации имеет широкую известность, его подмена сразу же будет раскрыта.
Кроме этого, самозаверенный сертификат невозможно отозвать в случае обнаружения компрометации сертификата. Не существует общеизвестной базы данных с самозаверенными сертификатами открытого ключа, в которую можно сообщить об отзыве данного самозаверенного сертификата. В случае центра сертификации этот центр имеет общеизвестную базу данных, в которую можно занести факт компрометации сертификата. Все пользователи сертификатов открытого ключа смогут своевременно получить информацию о компрометации выданного центром сертификата открытого ключа и выведут его из употребления.
Корневые сертификаты
В общем, про самозаверенные сертификаты я всё, что хотел, рассказал. Но в этом контексте дополнительно не повредит знать о том, что такое «корневой сертификат».
https://en.wikipedia.org/wiki/Root_certificate
Центр сертификации выдает очень много сертификатов открытого ключа, которые подписывает своей электронной подписью с помощью своего закрытого ключа. В зависимости от величины центра сертификации он может выдавать тысячи, сотни тысяч или даже миллионы сертификатов открытого ключа. Если закрытый ключ центра сертификации будет скомпрометирован, то как следствие будут скомпрометированы и все подписанные этим закрытым ключом выданные сертификаты открытого ключа. Это может привести к падению всего веба.
Для смягчения вышеописанной опасности главный центр сертификации может делегировать все полномочия (или только их часть) второстепенным центрам сертификации. Те, в свою очередь, могут делегировать свои полномочия еще более мелким центрам сертификации и так далее. При компрометации закрытого ключа любого из центров сертификации этой системы будет скомпрометирована только небольшая часть всех выданных сертификатов открытого ключа, а не все выданные сертификаты. Так получается смягчение негативных последствий.
Описанная цепочка делегирования полномочий от главного центра сертификации к второстепенному, а затем от второстепенного к третьестепенному и так далее, называется «цепочкой доверия».
https://ru.wikipedia.org/wiki/Цепочка_доверия
https://en.wikipedia.org/wiki/Chain_of_trust
Первичный (главный) центр сертификации в цепочке доверия называют корневым центром сертификации, так как от него начинается цепочка доверия (цепочка делегирования полномочий по выдаче сертификатов открытого ключа).
Для проверки сертификата открытого ключа, выданного одним из второстепенных (не корневых) центров сертификации в цепочке доверия проверяется сертификат самого этого центра сертификации, подписанный более высшим в цепочке центром сертификации. Затем проверяется сертификат открытого ключа более высшего в цепочке центра сертификации и так далее, до корневого центра сертификации.
Сертификат открытого ключа корневого центра сертификации называют «корневым сертификатом» в данной цепочке доверия. Корневой сертификат является самозаверенным сертификатом, то есть он содержит открытый ключ корневого центра сертификации, информацию о корневом центре сертификации и электронную подпись корневого центра сертификации, выполненную с помощью закрытого ключа корневого центра сертификации.
В случае корневого сертификата его защитой от подделки со стороны злоумышленников является его широкая распространенность и широкая известность. Поэтому случай подделки корневого сертификата будет сразу же разоблачен, в отличие от самозаверенного сертификата обычного веб-разработчика (самозаверенный сертификат обычного веб-разработчика не обладает широкой распространенностью и широкой известностью, его подделка если и будет разоблачена, то нескоро).