Что такое SAN-сертификат и как его создавать с помощью OpenSSL | Укрнеймс.БЛОГ

Вот что можно защитить:

Мы будем рады ответить на любой Ваш вопрос, дать консультацию и совет. Приятного всем дня.

Что такое ssl-сертификат?

Многие наверняка слышали про

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

Что такое san-сертификат и как его создавать с помощью openssl

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
[ req_distinguished_name ]
countryName                 = Country Name (2 letter code)
stateOrProvinceName         = State or Province Name (full name)
localityName               = Locality Name (eg, city)
organizationName           = Organization Name (eg, company)
commonName                 = Common Name (e.g. server FQDN or YOUR name)
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1   = bestflare.com
DNS.2   = usefulread.com
DNS.3   = chandank.com

openssl req -out sslcert.csr -newkey rsa:2048 -nodes -keyout private.key -config san.cnf

openssl req -noout -text -in sslcert.csr | grep DNS

[root@Chandan test]# openssl req -noout -text -in sslcert.csr | grep DNS
               DNS:bestflare.com, DNS:usefulread.com, DNS:chandank.com
[root@Chandan test]#

Adobe air signing

Для подписи файлов .air

Требуется для всех приложений, основанных на AIR

Android

Для подписи и оптимизации .apk файлов для платформы Android

Code signing for apple

Позволяет разработчикам подписывать программы для Mac OS, а также обновления для программного обеспечения

Java code signing

Для подписи Java апплетов. Позволяет подписывать .jar файлы и Java приложения для настольных и мобильных устройств.

Распознается Java Runtime Environment (JRE)

Kernel mode signing

Сертификаты разработчика Kernel-Mode позволяют подписывать, так называемые kernel-mode приложения и драйвера устройств. 64 битная версия Windows Vista и Windows 7 требуют, чтобы все kernel-mode приложения были подписаны сертификатом и доверенного центра сертификации.

Microsoft authenticode

Для подписи 32 и 64 битных файлов (.exe, .cab, .dll, .ocx, .msi, .xpi и .xap файлы). Также позволяет подписывать код для Microsoft® Office, Microsoft VBA, Netscape Object Signing и Marimba Channel Signing.

Поддерживает приложения на Silverlight 4

Microsoft office vba signing

Подписывает VBA объекты, скрипты и макросы для файлов Microsoft Office .doc, .xls, и.ppt

Для Microsoft Office и дополнений, которые используют VBA

Microsoft windows phone

Для цифровой подписи приложений для Windows Phone и Xbox 360. Требуется для сервиса Microsoft App Hub

Qualcomm brew

Для тех, кто разрабатывает приложения под платформу BREW (Binary Runtime Environment for Wireless)

San ssl-сертификаты

Единые сертификаты связи (UCC), Мульт-доменные сертификаты, SAN SSL-сертификаты, как их только не называют, но всех их объединяет одно свойство, способность защищать множество доменов, субдоменов, локальных доменов (.local), сервера (server name: ‘myserver01’), они идеальны для продуктов Microsoft Exchange. Данные сертификаты работают как с внешними, так и внутренними доменными именами.

Sgc ssl-сертификаты

Сегодня, о данных сертификатах уже можно забыть, хотя их продолжают использовать, т.к. они принудительно увеличивают уровень шифрования для старых браузеров с 40-бит до полноценных 256-бит. Ваш сайт или онлайн система будет защищена и получит высочайшее доверие от всех Ваших пользователей. Лучшие сайты используют 128/256-битное шифрование.

Ssl c поддержкой субдоменов (wildcard)

Очень удобный сертификат, когда речь идёт о защите большого кол-во субдоменов в рамках одного домена. Он может защитить любое кол-во субдоменов, на неограниченном кол-ве серверов. Больше не нужно устанавливать 5-10-20 разных сертификатов, иметь столько же IP адресов (если не использовать технологию SNI), всё в рамках одного продукта. Часто их так же используют для обеспечения безопасности хостинг панелей, таких как Plesk, cPanel.

Ssl-cертификаты для по (codesigning ssl)

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

Ssl-сертификаты с проверкой компании (business validation)

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

Алгоритмы и длина ключа

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

Кроме длины ключа надо выбрать криптографические алгоритмы, которые будут использоваться. Здесь все зависит не только от предпочтений администратора и возможностей ПО, но и от области деятельности компании — кроме требований к сертификации и лицензированию средств криптографической защиты, используемых при обработке персональных данных и государственной тайны, существуют отраслевые стандарты, которые регламентируют использование конкретных алгоритмов.

Кроме того, необходимо правильно выбрать алгоритм хеширования, который используется для создания хешей сертификатов, которые потом подписываются УЦ. С одной стороны, довольно популярный алгоритм SHA1 рекомендуется прекратить использовать до конца текущего года, из-за атак на него, и перейти на SHA2.

Варианты использования ключа

В сертификате обязательно указывается, для каких целей будет использоваться соответствующий ключ — для создания подписи, шифрования, обмена ключами, аутентификации.

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

Данные шифруются с помощью секретного ключа симметричным алгоритмом, этот секретный ключ шифруется открытым ключом пользователя и помещается в заголовок зашифрованного файла. Секретный ключ может шифроваться не только открытым ключом пользователя, но и открытым ключом агента восстановления (data recovery agent).

В этом случае агент получает возможность расшифровать данные даже при утере пользовательского закрытого ключа. Второй путь — это архивирование и шифрование закрытого ключа пользователей с помощью открытых ключей агентов восстановления ключей (key recovery agent), и последующее восстановление пользовательского ключа в случае его утраты.

Варианты установки уц

Чтобы реализовать иерархическую модель доверия, существуют различные варианты установки ЦС. В Windows Server 2008 установка центра сертификации происходит через добавление роли Active Directory Certificate Services. При прохождении мастера необходимо выбрать тип установки и тип центра сертификации.

Вариант установки (Enterprise или Standalone) влияет на возможности центра сертификации. Например, Enterprise CA может использовать шаблоны и автоматическую подачу заявок на сертификат. Standalone УЦ, несмотря на название, может быть членом домена. В случае же использования Standalone УЦ, в качестве Offline Root CA, он должен быть членом рабочей группы.

Можно установить два типа УЦ — Root CA и Subordinate CA. Для Root CA создается самоподписанный сертификат, для Subordinate CA необходимо запрашивать сертификат у вышестоящего УЦ. После установки УЦ нельзя менять имя сервера, на котором он установлен, так как сертификат УЦ окажется недействительным.

Удостоверяющие центры можно классифицировать по их предназначению: для хранения политик, выпуска сертификатов для подчиненных УЦ или для выпуска сертификатов для конечных пользователей. Можно создавать несколько центров для выпуска сертификатов, разделяя их по географическому признаку или по типу выдаваемых сертификатов.

Начиная с Windows Server 2008 R2 отпала необходимость ставить отдельный УЦ в каждом лесу организации, так как появилась возможность выдавать сертификаты пользователям не только того леса, в котором установлен УЦ, но и пользователям тех лесов, с которым настроены доверительные отношения.

Для повышения надежности системы и снижения последствий компрометации корневые УЦ, и УЦ, хранящие политики, используются в режиме Offline, чтобы исключить возможность атак по сети. В качестве типа для таких УЦ выбирают Standalone CA.

Где купить ssl-сертификат?

Приобретают сертификаты обычно не напрямую у удостоверяющего центра, а через партнёров. В России продажей сертификатов известных удостоверяющих центров (УЦ), таких как Comodo, Geotrust, GoDaddy, GlobalSign, Symantec и прочих, занимается множество компаний.

Защита для бизнеса и клиентов

Каким же сайтам нужна защита SSL? Да практически всем. Особенно тем, которые в наибольшей степени подвержены атакам: ресурсам финансовых учреждений, крупных брендов, сайтам, работающим с персональными данными и платёжной информацией.

Какие бывают виды code signing сертификатов, и чем отличаются?

Прежде всего рассмотрим сертификаты, по центрам сертификации, которые их выпускают.

Лучше всего различия между сертификатами от разных центров сертификации показывает сводная табличка.В колонках указаны названия центров сертификации, а в в строках тип сертификата или технология/платформа для которой он используется.

стоит уточнить, что не все центры сертификации дают полную информацию о платформах, на которых работают их сертификаты, поэтому плюсом отмечены только те платформы, поддержка которых в явном виде заявлена центром сертификации.

Листинг 1. файл capolicy.inf для корневого уц

[Version]Signature= “$Windows NT$”[Certsrv_Server]RenewalKeyLength=2048RenewalValidityPeriod=YearsRenewalValidityPeriodUnits=20[CRLDistributionPoint][AuthorityInformationAccess]

Листинг 2. настройка частоты публикации crl с помощью certutil

certutil -setreg CACRLPeriodUnits 60certutil -setreg CACRLPeriod “Days”certutil -setreg CACRLOverlapUnits 1certutil -setreg CACRLOverlapPeriod “Weeks”certutil -setreg CACRLDeltaPeriodUnits 0certutil -setreg CACRLDeltaPeriod “Hours”

Листинг 3. настройка частоты публикации crl с помощью фала

CAPolicy.InfCRLPeriodUnits = 60CRLPeriod = DaysCRLOverlapUnits = 1CRLOverlapPeriod = WeeksCRLDeltaPeriodUnits = 0CRLDeltaPeriod = Hours

Мульти-доменный сертификат с поддержкой неограниченного кол-во субдоменов

И вот, медленно, мы подошли к чудо сертификату, которому под силу почти всё. Это смесь сертификата с поддержкой субдоменов и мультидоменного сертификата, так как он способен защищать неограниченное кол-во субдоменов на более чем 100 доменах, совместим с MS Exchange, работает на всех типах платформ и при этом выданный сертификат может одновременно работать как на Linux, так и Windows серверах. Вот что не может данный сертификат, так это обеспечить ресурсы зелёной адресной строкой.

Продукт не из дешёвых, он больше подходит для тех, у кого много своих сайтов или множество сертификатов с поддержкой субдоменов (Wildcard)

Несколько слов про timestamp.

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

Пример:Сертификат действителен с: 01.01. 2008Сертификат действителен до: 31.12.2021Подпись сделана: 04.07.2009Подпись проверена: 30.04.2021

C временной меткой (timestamp) подпись пройдет проверку, поскольку на момент подписи сертификат был действителен. Без такой метки сертификат не пройдет проверку, поскольку на момент проверки у сертификата уже закончился срок.То есть такая метка позволяет использовать подписанный код, даже после срок окончания сертификата.

Несколько советов.

1. Заявку на сертификат желательно оформлять с той же машины, с которой вы потом будете выполнять подпись ПО.
2. Большинство центров сертификации рекомендуют генерировать заявку на сертификат через Internet explorer, хотя при генерации заявок через другие браузеры у нас также не было проблем.

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

UPD: добавил важную информацию про timestamp (временную метку), спасибо TolTol и crea7or

Определения

При общении с администраторами, и уж тем более — с пользователями, часто выясняется, что использовать сертификаты они уже научились, но на вопрос, что это такое, можно часто услышать неуверенный ответ «ну, это… ну, для аутентификации». Поэтому позволю себе начать статью с определений; те, кто с ними знаком, могут сразу переходить к следующему разделу.

Сертификат — это файл или объект, хранящийся в базе данных, который содержит следующие поля: номер, открытый ключ, информацию о владельце ключа и вариантах его использования, информацию об УЦ, выдавшем сертификат, и срок действия. Кроме перечисленных полей сертификат может содержать и другие данные.

Инфраструктура открытых ключей (Public Key Infrastructure (PKI)) — это набор взаимосвязанных программных и аппаратных компонентов, а также административных и организационных мер для работы с криптографическими системами, использующими ассиметричные алгоритмы.

Приложения, относящиеся к PKI, можно разделить на две категории:

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

Кроме технической составляющей важную роль играют и «бюрократические» компоненты PKI, особенно когда существует потребность реализовать юридически значимый электронный документооборот. Политики сертификации (Certificate Policy) и регламент УЦ (Certificate Practice Statements) позволяют определить уровень доверия к издаваемым сертификатам.

Если политики и регламенты, состав и производители пользовательских приложений могут меняться от организации к организации, то наличие центра сертификации, пусть и от разных вендоров, остается неизменным. Удостоверяющий центр — это основа инфраструктуры открытых ключей, которая объединяет программные модули и аппаратные компоненты (например, HSM — Hardware Security Module).

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

Проверка информации о владельце ключа, в зависимости от типа сертификата, варьируется от отправки ссылок на указанный в запросе e-mail, до предъявления паспорта и данных о зарегистрированном домене. Задачи по проверке выполняет центр регистрации, который зачастую является компонентом центра сертификации.

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

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

Для предоставления информации о статусе сертификата используются списки отзыва, которые содержат информацию обо всех отозванных сертификатах, или изменениях по сравнению с предыдущим списком отзыва, или протокол OCPS (Online Certificate Status Protocol).

Списки отзыва генерируются с заданным на УЦ интервалом, в то время как с использованием компонента OCSP responder можно получить информацию о статусе сертификата в реальном времени. В том случае, если закончился срок действия закрытого ключа, то центр сертификации занимается выпуском нового сертификата для нового ключа или для этого же ключа, но с другим сроком действия (использование того же ключа оправдано, например, для сертификатов агентов восстановления ключей, чтобы избежать процедуры экспорта-перешифрования-импорта заархивированных ключей).

Поля сертификатов

Прежде чем устанавливать УЦ, необходимо обдумать, для чего будут использоваться сертификаты. В большинстве случаев добавить новые шаблоны сертификатов на уже работающий УЦ не составит труда, но изменить параметры сертификата самого УЦ будет невозможно. Поэтому ниже перечислены поля сертификатов, значения для которых важно продумать до начала установки УЦ.

Проверка при помощи dns записи (dns cname)

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

Процесс подписи кода.

1. Издатель (разработчик) запрашивает Code Signing сертификат у центра сертификации
2. Используя SIGNCODE.EXE или другую утилиту для подписи кода издатель, cоздает хеш кода, используя алгоритмы MD5 или SHA
3. Кодирует хеш, с помощью приватного ключа
4. Создает пакет, который включает в себя: код, зашифрованный хеш и сертификат издателя

Процесс проверки подписанного кода.

1. Пользователь скачивает или устанавливает подписанное ПО и платформа или система пользователя проверяет сертификат издателя, который подписан корневым приватным ключем центра сертификации
2. Система запускает код, используя тот же самый алгоритм создания хеша, как издатель и создает новый хеш
3. Используя публичный ключ издателя, который содержится в сертификате, система расшифровывает зашифрованный хеш
4. И сравнивает между собой 2 хеша

Симметричные и ассиметричные криптосистемы

Сертификаты используются при работе с ассиметричными криптографическими алгоритмами. Для таких алгоритмов требуется закрытый ключ (обычно — случайное число) и связанный с ним открытый ключ (который является основной частью сертификата). Главное свойство таких систем — невозможность получения закрытого ключа по известному открытому.

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

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

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

Симметричные алгоритмы могут быть использованы и для аутентификации (например, CBC-MAC и HMAC), но так как для проверки используется тот же ключ, что и для аутентификации, такой метод нельзя назвать надежным, поскольку ключ известен как минимум двум сторонам.

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

Срок действия

Срок действия сертификата зависит от его предназначения. Обычно для пользовательских сертификатов выбирают срок 1-2 года, для сертификатов Subordinate Issuing CA — около 5 лет, для сертификатов здоровья NAP — несколько часов, самый длительный срок задается для сертификатов корневых УЦ — до нескольких десятков лет.

Этапы развертывания

После описания возможных вариантов и параметров установки, рассмотрим шаги, которые надо предпринять при развертывании двухуровневой инфраструктуры центров сертификации на базе Windows Server 2008.

Вначале необходимо определить, кто будет использовать сертификаты — только сотрудники компании, клиенты или партнеры. Продумать, для каких целей и в каких приложениях будут использоваться сертификаты, каким образом сертификаты будут запрашиваться и обновляться.

Каким образом будет настраиваться доверие к корневому сертификату для пользователей. Самый простой вариант — использовать групповые политики, но он подходит только для сотрудников компании, при наличии единого леса в организации. Иногда даже приходится доставлять самоподписанный сертификат на материальном носителе во все филиалы компании.

Если в итоге было принято решение о создании иерархии корпоративных ЦС, то переходим к следующим шагам.

Заключение

Поняв, какие возможности есть у технологии PKI, и точно зная, что обозначает тот или иной термин, можно без труда развернуть сложную конфигурацию из большого количества центров сертификации, даже если они установлены на различные ОС.

Подведем итог

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

С расширенной проверкой (extended validation)

Престиж и доверие — вот основа сертификатов с расширенной проверкой. Только EV сертификаты обеспечат Ваш сайт зелёной адресной строкой в браузере, а это пожалуй самый простой способ доказать Вашим посетителям, что вы думаете об их безопасности, шифруете данные, а самое главное, Вам можно доверять. Чаще всего такие сертификаты можно встретить у банков, онлайн систем с большим кол-во посетителей, практически во всех Интернет магазинах и других сайтов через которые проходят потоки важной информации. Получить такой сертификат не просто, процесс трудоёмкий, но результат не заставит себя ждать.