Самоподписанный сертификат

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

Например, если владелец веб-сайта использует самозаверяющий сертификат для предоставления услуг HTTPS, люди, посещающие этот веб-сайт, не могут быть уверены, что они подключены к месту назначения. Насколько им известно, третья сторона-злоумышленник может перенаправить соединение, используя другой самозаверяющий сертификат с тем же именем владельца. Соединение по-прежнему зашифровано, но не обязательно ведет к намеченной цели. Для сравнения, сертификат, подписанный доверенным центром сертификации, предотвращает эту атаку, поскольку веб-браузер пользователя отдельно проверяет сертификат на соответствие выдавшему его центру сертификации. Сертификат злоумышленника не проходит эту проверку.

Преимущества

Самозаверяющие сертификаты можно создавать бесплатно с использованием широкого спектра инструментов, включая OpenSSL , Java keytool, Adobe Reader, wolfSSL и Apple Keychain. Их легко настроить; например, они могут иметь больший размер ключей или содержать дополнительные метаданные. Их использование не связано с проблемами доверия третьим лицам, которые могут неправильно подписать сертификаты. Транзакции с самозаверяющими сертификатами обычно представляют собой гораздо меньшую поверхность атаки , устраняя как сложную проверку цепочки сертификатов, так и ^{[ 1 ]} и отзыва сертификатов, проверки такие как CRL и OCSP .

Проблемы доверия

на базе центра сертификации В системе PKI стороны, участвующие в безопасной связи, должны доверять центру сертификации, т. е. помещать сертификаты центра сертификации в белый список доверенных сертификатов. Разработчики веб-браузеров могут использовать процедуры, определенные CA/Browser Forum, для внесения в белый список известных общедоступных центров сертификации. Отдельные группы и компании могут внести в белый список дополнительные частные сертификаты ЦС. Проблемы доверия объекта, принимающего новый самозаверяющий сертификат, аналогичны проблемам объекта, доверяющего добавлению нового сертификата CA. Стороны самозаверяющей PKI должны установить доверие друг к другу (используя процедуры вне PKI) и подтвердить точную передачу открытых ключей, например сравнить криптографический хэш внеполосный сертификата.

Существует множество тонких различий между сертификатами, подписанными ЦС, и самозаверяющими сертификатами, особенно в степени доверия, которое может быть установлено к утверждениям безопасности сертификата. Некоторые центры сертификации могут проверять личность человека, которому они выдают сертификат; например, военные США выдают карты общего доступа лично с несколькими формами других удостоверений личности. Центр сертификации может подтверждать подобные значения удостоверений, включая их в подписанный сертификат. Объект, проверяющий сертификат, может доверять информации в этом сертификате в той же степени, в какой он доверяет ЦС, подписавшему его (и, как следствие, процедурам безопасности, которые ЦС использовал для проверки заверенной информации).

Напротив, в случае самозаверяющего сертификата доверие к значениям в сертификате более сложное, поскольку объект обладает ключом подписи и всегда может создать новый сертификат с другими значениями. Например, датам действия самозаверяющего сертификата можно не доверять, поскольку организация всегда может создать и подписать новый сертификат, содержащий действительный диапазон дат.

Значениям в самозаверяющем сертификате можно доверять только в том случае, если значения были проверены вне канала во время принятия сертификата, и существует метод проверки того, что самозаверяющий сертификат не изменился после того, как ему стали доверять. Например, процедура доверия самоподписанному сертификату включает ручную проверку дат действия, а хэш сертификата заносится в белый список. ^{[ 2 ]} Когда сертификат предоставляется объекту для проверки, он сначала проверяет, что хэш сертификата соответствует эталонному хэшу в белом списке, и если они совпадают (указывая, что самозаверяющий сертификат такой же, как тот, которому ранее доверяли). ), то срокам действия сертификата можно доверять. Специальную обработку полей сертификата X.509 для самозаверяющего сертификата можно найти в RFC 3280. ^{[ 1 ]}

Отзыв самозаверяющих сертификатов отличается от отзыва сертификатов, подписанных центром сертификации. По своей природе ни один объект (ЦС или другие) не может отозвать самозаверяющий сертификат. Но можно сделать недействительным самоподписанный центр сертификации, удалив его из белого списка доверия. ^{[ 3 ]}

Использование

Самоподписанные сертификаты имеют ограниченное применение, например, в тех случаях, когда эмитент и единственный пользователь являются одним и тем же лицом. Например, шифрованная файловая система в Microsoft Windows выдает самозаверяющий сертификат от имени учетной записи пользователя для прозрачного шифрования и расшифровки файлов на лету. Другим примером является корневой сертификат , который представляет собой разновидность самозаверяющего сертификата.

Путаница в имени

Термины «самозаверяющий» и «самостоятельно выданный» иногда используются как взаимозаменяемые, а «самозаверяющий сертификат» иногда даже неправильно используется для обозначения сертификата, выданного частным (не пользующимся общественным доверием) центром сертификации. ^{[ 4 ]}^{[ 5 ]}^{[ 6 ]}

RFC 5280 определяет самоподписанные сертификаты как «самостоятельно выданные сертификаты, цифровая подпись которых может быть проверена открытым ключом, связанным с сертификатом». ^{[ 7 ]} тогда как сертификат, выданный самостоятельно, представляет собой сертификат, «в котором эмитент и субъект являются одним и тем же лицом». Хотя в строгом смысле RFC дает это определение только для сертификатов CA, нет никаких оснований принимать это определение и для сертификатов конечного объекта.

См. также

Центр сертификации § Слабость реализации схемы доверенной третьей стороны
X.509 — стандарт, описывающий наиболее широко используемый формат хранения сертификатов.
Let's Encrypt , центр сертификации, который предоставляет бесплатные сертификаты с проверкой домена. ^{[ 8 ]}

Ссылки

^ Jump up to: ^а ^б Хаусли, Расс; Полк, Тим; Форд, Уорик С.; Соло, Дэвид (май 2002 г.). «Профиль сертификата и CRL – RFC 3280» . www.tools.ietf.org . Архивировано из оригинала 26 апреля 2017 г. Проверено 6 апреля 2017 г.
^ «Как обойти SSLHandshakeException» . Архивировано из оригинала 01 августа 2021 г. Проверено 1 августа 2021 г.
^ «RFC 2459: Сертификат инфраструктуры открытых ключей Internet X.509 и профиль CRL» . www.ietf.org . Январь 1999 г. Архивировано из оригинала 14 декабря 2012 г. Проверено 3 января 2009 г.
^ «Как создать доверенные самоподписанные SSL-сертификаты и локальные домены для тестирования» . «Самоподписанный сертификат — это сертификат, подписанный лицом, создавшим его» . Проверено 15 февраля 2024 г.
^ «Создать самозаверяющий сертификат Шлюза приложений Azure с помощью пользовательского корневого центра сертификации» . Проверено 15 февраля 2024 г.
^ «Создание доверенного самозаверяющего SSL-сертификата браузера | автор Thijs Busser | Medium» . «Самозаверяющий SSL-сертификат, используемый для разработки веб-сайтов, требует корневого сертификата» . Проверено 15 февраля 2024 г.
^ https://datatracker.ietf.org/doc/html/rfc5280#section-3.2
^ «Публичная бета» . Давайте зашифруем . Архивировано из оригинала 07 апреля 2018 г. Проверено 6 декабря 2015 г.

[:0-1] Jump up to: ^а ^б Хаусли, Расс; Полк, Тим; Форд, Уорик С.; Соло, Дэвид (май 2002 г.). «Профиль сертификата и CRL – RFC 3280» . www.tools.ietf.org . Архивировано из оригинала 26 апреля 2017 г. Проверено 6 апреля 2017 г.

[2] «Как обойти SSLHandshakeException» . Архивировано из оригинала 01 августа 2021 г. Проверено 1 августа 2021 г.

[3] «RFC 2459: Сертификат инфраструктуры открытых ключей Internet X.509 и профиль CRL» . www.ietf.org . Январь 1999 г. Архивировано из оригинала 14 декабря 2012 г. Проверено 3 января 2009 г.

[4] «Как создать доверенные самоподписанные SSL-сертификаты и локальные домены для тестирования» . «Самоподписанный сертификат — это сертификат, подписанный лицом, создавшим его» . Проверено 15 февраля 2024 г.

[5] «Создать самозаверяющий сертификат Шлюза приложений Azure с помощью пользовательского корневого центра сертификации» . Проверено 15 февраля 2024 г.

[6] «Создание доверенного самозаверяющего SSL-сертификата браузера | автор Thijs Busser | Medium» . «Самозаверяющий SSL-сертификат, используемый для разработки веб-сайтов, требует корневого сертификата» . Проверено 15 февраля 2024 г.

[7] ttps://datatracker.ietf.org/doc/html/rfc5280#section-3.2

[8] «Публичная бета» . Давайте зашифруем . Архивировано из оригинала 07 апреля 2018 г. Проверено 6 декабря 2015 г.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]