Что будет с полем CN Common Name в сертификате

Прежде чем исследовать историю SSL, давайте рассмотрим по сути, что такое цифровой сертификат. В принципе, цифровой сертификат - это привязка прав и ограничений к ключу, другими словами цифровой сертификат будет определять следующее: «Владелец частного ключа, связанного с этим сертификатом, может по праву использовать имя Джона Смита при подписании документов».

Когда первоначально задуманные цифровые сертификаты использовались для связывания предметов (людей и ресурсов) с их представлениями в каталогах. Вот почему имя субъекта сертификата структурировано как Distinguished Name (DN), которое позволяет каталогу однозначно идентифицировать предмет. При поиске ключа шифрования для пользователя в корпоративном каталоге этот подход имеет смысл; однако он не работает так хорошо в Интернете, где нет глобального каталога пользователей.

Это приводит нас к SSL, представленному в середине 1990-х годов в то время, когда почти все крупные предприятия уже развертывали каталоги и центры сертификации в рамках своих систем управления идентификацией. В течение этого времени был только один способ представить концепцию объекта сертификата, и это было связано с использованием поля Common Name (CN), в результате чего DNS-имя сервера SSL было помещено в поле CN. Хотя технически приемлемо, поле CN первоначально предназначалось для фактического имени пользователя.

После того, как протокол SSL был доработан и широко принят, Целевая группа Internet Engineering Task Force (IEFT) выпустила профиль для X.509, в котором была представлена ​​концепция альтернативных имен объектов (SAN), в которой могут быть размещены имена, не связанные с каталогом. Это создало проблему, потому что сертификаты уже были стандартизованы при использовании поля Common Name для имен, не связанных с каталогом.

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

Другая проблема с использованием этого подхода заключается в том, что приложения не знают, какой тип значения ожидать в поле Common Name. Является ли значение именем человека или является DNS-именем? Это проблема, потому что часто возникают правила, требующие проверки части данных перед ее использованием, и это особенно верно для DNS-имен. С 1999 года (когда стандарт RFC 2549 был стандартизован) мы были на медленном пути перехода от использования общих имен для доменных имен к использованию альтернативных имен объектов.

В 2012 году Стэнфордские исследователи опубликовали статью под названием « Самый опасный код в мире: проверка SSL-сертификатов в несерверном программном обеспечении », в котором было обнаружено множество приложений, которые не смогли выполнить самые основные задачи проверки сертификатов правильно и в результате являются источником множества уязвимостей безопасности. Приложения, обсуждавшиеся в документе, дали пользователям ложное чувство безопасности не из-за злобы, а из-за отсутствия понимания технологии, и большая часть этого - это сложность, с которой связано 18 лет технологической эволюции.

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

Мы видим, что это происходит несколькими путями. Сначала CA / Browser Forum работал с браузерами для определения набора базовых методов, которые должны соответствовать всем сертификатам; мы также видим, что браузеры делают проверки здравомыслия, чтобы гарантировать, что эти практики на самом деле следуют.

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

В настоящее время большинство центров сертификации включают в себя первое имя DNS из альтернативного имени субъекта в поле «Общее имя», но это делается главным образом по причинам, связанным с наследием, и в какой-то момент в будущем остановится. Когда сертификаты будут немного меньше, а жизнь разработчиков может быть немного проще.

С учетом сказанного Трудно оценить, когда поле CN полностью обесценится от сертификатов, поскольку даже сегодня новые разрабатываемые приложения используют поле CN и поле SAN, и если приложение не смотрит в поле SAN, приложение будет вероятно, не работают в большом количестве развертываний. Это усугубляется использованием совместного хостинга, который используется еще чаще из-за проблемы с исчерпанием адреса IPv4 В итоге, эти приложения уже не работают повсюду и скоро будут работать в меньшем количестве мест.