НОУ ИНТУИТ | Лекция | Службы сертификации и их применение

Что происходит по истечении срока действия ssl-сертификата?

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

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

Раньше SSL-сертификаты могли выдаваться на срок до пяти лет, который впоследствии был сокращен до трех лет, а в последнее время до двух лет плюс возможность использовать дополнительные три месяца. В 2020 году Google, Apple и Mozilla объявили, что будут применять годовые SSL-сертификаты, несмотря на то, что это предложение было отклонено Центрами сертификации / Форумом браузеров.

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

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

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

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

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

Если срок действия сертификата истечет, сертификат станет недействительным, и выполнять безопасные транзакции на веб-сайте станет невозможно. Центр сертификации предложит обновить SSL-сертификат до истечения срока его действия.

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

3 Работа с сертификатами КриптоПро — РЕД ОС

ln -s /opt/cprocsp/bin/amd64/certmgr /usr/bin/certmgr
ln -s /opt/cprocsp/bin/amd64/csptest /usr/bin/csptest
ln -s /opt/cprocsp/sbin/amd64/cpconfig /usr/bin/cpconfig

csptest -enum -info

cat /etc/opt/cprocsp/release

cpconfig -license -view

# cpconfig -license -set <серийный_номер>

systemctl status pcscd

systemctl start pcscd
systemctl enable pcscd

pcscd -dffff

csptest -card -enum -v -v
pcsc_scan

csptest -keyset -enum_cont -fqcn -verifyc | iconv -f cp1251

CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.AcquireContext: OK. HCRYPTPROV: 16778675\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4\.FLASHbob\.HDIMAGEbobOK.Total: SYS: 0,010 sec USR: 0,110 sec UTC: 6,240 sec[ErrorCode: 0x00000000]

csptest -keyset -enum_cont -fqcn -verifyc | iconv -f cp1251

csptest -keyset -enum_cont -fqcn -verifyc -uniq

CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.AcquireContext: OK. HCRYPTPROV: 23397811\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4 | \.Aladdin R.D. JaCarta 00 00SCARDJACARTA_6082028344937676CC00E412OK.Total: SYS: 0,000 sec USR: 0,110 sec UTC: 6,230 sec[ErrorCode: 0x00000000]

csptest -keyset -container '\.HDIMAGEbob' -info

csptest -keyset -enum_cont -verifycontext -fqcn

csptest -keyset -enum_cont -verifycontext -fqcn -machinekeys

csptest -keyset -check -cont '\.имя считывателяимя контейнера'

csptest -keyset -check -cont '\.имя считывателяимя контейнера' -machinekeyset

certmgr -inst -file cert_bob.cer

certmgr -inst -file cert_bob.cer -store uMy -cont '\.FLASHbob'

/opt/cprocsp/bin/amd64/certmgr -inst -store uMy -cont '\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4'

/opt/cprocsp/bin/amd64/certmgr -inst -store uMy -cont '\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4' -file /home/bob/cert_bob.cer

certmgr -inst -store uRoot -file <название-файла>.cer

certmgr -inst -store mRoot -file <название-файла>cer

certmgr -inst -crl -file <название-файла>.crl

certmgr -list

certmgr -list -store uMy

$ certmgr -list -store uRoot

certmgr -list -container '\.Aladdin R.D. JaCarta 00 008df47e71-18ae-49c1-8738-9b4b0944dcd4'

certmgr -list -store uca

certmgr -list

certmgr -delete -store uMy

certmgr -delete -store uRoot

certmgr -delete -all -store uRoot

certmgr -delete -store mRoot

cpconfig -hardware reader -add HDIMAGE store
Adding new reader:
Nick name: HDIMAGE
Succeeded, code:0x0

csptest -keyset -enum_cont -fqcn -verifyc

CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 32114099
\.FLASHbob
OK.
Total: SYS: 0,020 sec USR: 0,080 sec UTC: 0,190 sec
[ErrorCode: 0x00000000]

csptest -keyset -enum_cont -fqcn -verifyc

CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 36951475
\.FLASHbob
\.HDIMAGEbob
OK.
Total: SYS: 0,000 sec USR: 0,070 sec UTC: 0,160 sec
[ErrorCode: 0x00000000]

certmgr -inst -file cert-bob.cer -cont '\.HDIMAGEbob'

Внешние носители закрытых ключей

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

Для усиления безопасности закрытых ключей пользователя и обеспечения его мобильности широко используются внешние отчуждаемые носители. Следует отметить, что использование внешних носителей для сохранения программного хранилища (в качестве носителя может выступать, например, USB-диск, дискета, CD-диск) обеспечивает мобильность, однако не существенно повышает безопасность.

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

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

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

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

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

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

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

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

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

Аппаратные устройства с криптографическими возможностями

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

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

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

Злонамеренное программное обеспечение (malicious software). Предположим, что пользователь подключает аппаратное устройство с криптографическими возможностями на инфицированную вирусом машину и вводит пароль для авторизации в появившемся на экране монитора окне.

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

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

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

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

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

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

Смарт-карты и USB-ключи

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

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

Мобильность смарт-карт и USB-ключей позволяет пользователю безопасно работать в «недоверенной среде», так как ключи шифрования и ЭЦП генерируются аппаратно микросхемой смарт-карты, никогда не покидают её и не могут быть извлечены или перехвачены.

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

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

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

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

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

Также важно отметить, что существуют международные стандарты безопасности, разработанные специально для смарт-карт и USB-ключей, среди которых наиболее широко применимыми являются стандарт CWA 14169 (стандарт для изделий, реализующих электронную подпись — безопасные устройства создания подписи secure signature-creation devices, SSCD) и профиль защиты для смарт-карт «Smart Card Protection Profile (SCSUG-SCPP)».

Особенности использования национальной криптографии

Для обеспечения возможности использования российских криптографические алгоритмов и сертификатов открытых ключей X.509 в ИТ-системах, построенных на базе общего или прикладного программного обеспечения западного производства, в данных системах должны быть дополнительно реализованы соответствующие этим алгоритмам механизмы распределения открытых ключей и сертификатов, как это, в частности, описано в международных документах [1].

Упомянутый выше функционал взаимодействует с программным обеспечением через стандартные интерфейсы типа CryptoAPI 2.0, CAPICOM. По интерфейсам типа Microsoft CSP, PKCS#11 доступен лишь ограниченный набор низкоуровневых функций, который позволяет использовать только основные криптографические процедуры (шифрование/расшифрование, проверка подписи, хеширование) на уровне ядра операционной системы, т.е. в приложениях типа шифраторов IP протокола, жесткого диска и т.д.

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

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

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

Во время специализированной конференции «Актуальные проблемы создания системы удостоверяющих центров России. Аспекты международного сотрудничества в области ЭЦП», проходившей в ноябре 2005г. в Санкт-Петербурге, более 40 компаний заявили о себе как о публичных (конечно, условно в свете действующего ФЗ-1) Удостоверяющих центрах.

Число пользователей ЭЦП в России исчисляется сегодня сотнями тысяч. Гигантскими темпами стали развиваться отдельные сегменты электронного бизнеса В2В; например, как было отмечено на 10-оминтернет-форуме, рост рынка В2В за 2005 г.

на 294 % во многом обусловлен интенсивным ростом объема электронной торговли электроэнергией, организованной с применением технологий строгой аутентификации участников торговли и использованием ЭЦП. Интенсивными темпами «догоняет» действительность законодательство:

если в 2002 г. был принят только один закон — ФЗ-1 «Об электронной цифровой подписи», в 2004г.- закон «О коммерческой тайне», то в текущем году уже принято 2 закона в части информационной безопасности — «Закон о персональных данных» и новая редакция закона «Об информации, информационных технологиях и о защите информации».

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

Алексей Сабанов, Антон Крячков, Константин Демченко, Сергей Белов

Обязательные атрибуты квалифицированных сертификатов

Состав квалифицированного сертификата регулируется Федеральным законом “Об электронной подписи” от 06.04.2021 N 63-ФЗ и Приказом ФСБ РФ от 27 декабря 2021 г. N 795 “Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи”.

Несколько раз встречались квалифицированные сертификаты проверки подписи юридических лиц, выпущенные аккредитованным УЦ, в которых в поле Subject – субъект сертификации отсутствовал атрибут L – Местоположение.

Контроль квалифицированных сертификатов нашей системы отвергал данный сертификат и документы с ЭП партнера.

Удостоверяющий центр данную ситуацию комментировал так:

атрибут L для юридических лиц, зарегистрированных в г. Москве, не проставляется согласно 63-ФЗ и Приказа №795

На конкретный пункты Закона и Приказа в УЦ не ссылались.

Собственный повторный анализ юридических аспектов показал:

63-ФЗ от 06.04.2021 “Об электронной подписи”

Статья 14. Сертификат ключа проверки электронной подписи

2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:

2) фамилия, имя и отчество (если имеется) – для физических лиц, наименование и место нахождения – для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;

Статья 17. Квалифицированный сертификат

2. Квалифицированный сертификат должен содержать следующую информацию:

2) фамилия, имя, отчество (если имеется) владельца квалифицированного сертификата – для физического лица, не являющегося индивидуальным предпринимателем, либо фамилия, имя, отчество (если имеется) и основной государственный регистрационный номер индивидуального предпринимателя – владельца квалифицированного сертификата – для физического лица, являющегося индивидуальным предпринимателем, либо наименование, место нахождения и основной государственный регистрационный номер владельца квалифицированного сертификата – для российского юридического лица, либо наименование, место нахождения владельца квалифицированного сертификата, а также идентификационный номер налогоплательщика (при наличии) – для иностранной организации (в том числе филиалов, представительств и иных обособленных подразделений иностранной организации);

Приказ ФСБ РФ от 27 декабря 2021 г. № 795

III. Требования к порядку расположения полей квалифицированного сертификата

5) stateOrProvinceName (наименование штата или области).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации. Объектный идентификатор типа атрибута stateOrProvinceName имеет вид 2.5.4.8;

6) localityName (наименование населенного пункта).

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

7) streetAddress (название улицы, номер дома).

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

В сертификате партнера в имени субъекта сертификации были указаны: stateOrProvinceName (наименование штата или области), streetAddress (название улицы, номер дома).

И не указано localityName (наименование населенного пункта).

locality – Местонахождение

В Законе 63-ФЗ и Приказе №795 нет информации, что для города Москва не нужно заполнять атрибут locality – Местонахождение.

Наоборот в обоих документах на русском языке применяется термин место нахождения, чему соответствует атрибут localityName ( 2.5.4.7)

После данного разбора удалось найти документ ФСБ РФ «ИЗВЕЩЕНИЕ ОБ ИСПОЛЬЗОВАНИИ АТРИБУТА ИМЕНИ «LOCALITYNAME» ПОЛЯ «SUBJECT» В СТРУКТУРЕ КВАЛИФИЦИРОВАННОГО СЕРТИФИКАТА КЛЮЧА ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ»

Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя ‑ юридического лица.

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

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

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

Прошу использовать данную информацию в работе.

Желаю всем участникам PKI удачи и успехов!

Планирование имён цс

Имя ЦС – это имя, которое будет отображено в поле

Subject

конкретного ЦС. Не путать с именем хоста, на котором работает служба сертификатов. Полное имя ЦС будет состоять из двух компонентов, самого имени (атрибут CN или Common Name) и опционального суффикса в формате X.500. По умолчанию ADCS назначает имя в следующем формате:

Для Standalone CA: <ComputerName>-CA

Для Enterprise CA: <DomainShortName>-<ComputerName>-CA, <X500DomainSuffix>

Хорошо это или плохо? Технически, вы можете выбрать любое имя, функционально оно ни на что влиять не будет. Есть мнение, что имя вашего ЦС является в некотором роде визитной карточкой вашей PKI, отражая ваше отношение к деталям, которые не имеют непосредственного отношения к функциональности, но обеспечивают достаточный уровень информативности и открытости. Поэтому при выборе полного имени сертификата следует руководствоваться несколькими рекомендациями:

Предположим, что вы подбираете имя для корневого ЦС компании Contoso Pharmaceuticals Ltd., которая находите в городе Рига, Латвия и управление обеспечивается отделом информационных технологий. В этом случае имя ЦС может иметь следующий вид:

CN=Contoso Pharm Root Certification Authority, OU=Division Of IT (DoIT), O=Contoso Pharmaceuticals Ltd., L=Riga, C=LV

Следует помнить, что атрибут Country поддерживает только двухбуквенный индекс страны. Например, LV, GB, RU, US и т.д. В качестве дополнительных примеров, можете обратиться к сертификатам ЦС коммерческих провайдеров, как VeriSign/Symantec, DigiCert и т.д.

Для подчинённого ЦС это имя будет похожим, за исключением того, что слово Root в имени будет заменено на Subordinate или Issuing. В случае трёхуровневой иерархии, где явно выделяется ЦС политик, слово Root будет заменено на Policy. Как я выше отмечал, в вашей компании могут применяться другие правила, и вы можете их внедрить в имена ЦС, на функциональность это влиять не будет. При этом следует избегать:

• Чрезмерно длинных имён в атрибуте CN (не более 50 символов). При длине атрибута CN свыше 51 символа, оно будет укорочено с пристыковкой хэша отброшенного фрагмента имени в конец имени. Это называется процессом «санитизации» имени, который описан в §3.1.1.4.1.1 протокола [MS-WCCE]. Т.е. может случиться так, что при слишком длинном имени слово оборвётся на середине и будет иметь неприглядный вид.
• Использовать буквы, которые не входят в состав латинского алфавита, т.е. никакой криллицы или диактрических букв (например, ā, ž, Ü, ẞ). ADCS поддерживает только однобайтовые кодировки для атрибута CN и для ограниченного набора символов. Неподдерживаемые символы будут преобразованы в другую кодировку и станут нечитаемыми. Полный список запрещённых символов представлен в §3.1.1.4.1.1.2 протокола [MS-WCCE]. Здесь работает принцип «лучшее – враг хорошему», поэтому имена должны быть достаточно лаконичными и информативными.

Рукопожатие ssl

Рис. 6.21 отображает упрощенную версию процесса рукопожатия SSL. Вот что происходит на этом этапе:

1. Клиент запрашивает сервер о начале сеанса. Это выполняется с помощью сообщения ClientHello с целью увидеть, сконфигурирован ли на сервере протокол SSL. Вместе с сообщением ClientHello клиент также передает список поддерживаемых клиентом опций шифрования и случайное число, которое будет использовано позднее.
2. Если протокол SSL сконфигурирован, сервер отвечает сообщением ServerHello и отправляет список поддерживаемых сервером опций шифрования. На этой стадии клиент и сервер узнают, какой из видов шифрования является для них общим (выбирается самое криптостойкое шифрование из всех возможных).
3. После этого сервер отправляет клиенту свой сертификат X.509, который содержит открытый ключ сервера.

   Если требуется произвести аутентификацию клиента, которая предполагает использование сертификатов клиента, после завершения первых трех шагов происходит следующее:

4. Сервер выдает запрос на сертификат клиента.
5. Для завершения процесса аутентификации клиента последний отправляет серверу свой сертификат.

По существу, два “hello” сообщения используются, во-первых, для того, чтобы удостовериться в возможности проведения SSL сеанса, а если это возможно, то сервер предоставляет сертификат открытого ключа ( public key certificate ).

Если требуется, клиент также предоставит сертификат открытого ключа ( public key certificate ). Это метод, с помощью которого SSL проверяет идентичность ( identity ) и подлинность ( authenticity ) сторон. На рис. 6.21 показаны как шаги по аутентификации сервера, так и шаги по аутентификации клиента.

Так как имеет место аутентификация, то может быть и процесс передачи сеансового ключа SSL. Этот процесс проиллюстрирован на рис. 6.22.

На этой стадии “рукопожатия” ( handshake ) партнеры устанавливают сессионный ключ, который используется для шифровки и расшифровки всех передаваемых данных в течение данного сеанса. Как и в случае процесса аутентификации, передача ключа сеанса SSL также прозрачна для пользователя. Вот что происходит на этой стадии:

1. Клиент отправляет серверу сообщение ClientHello с перечнем возможных шифров (или алгоритмов шифрования) для использования в процессе шифрования.
2. Сервер выбирает сильнейший шифр, который они могут совместно использовать, и отвечает сообщением ServerHello, содержащим выбранный шифр.
3. Так как сеанс еще не является безопасным, сервер отправляет клиенту свои сертификаты для обеспечения безопасности сеансового ключа. Если требуется проведение аутентификации клиента, сервер также запрашивает сертификат клиента и клиент отправляет его (это не показано на рис. 6.22).
4. Клиент генерирует секрет [называемый предосновным (pre-master) секретом], созданный с помощью генератора случайных чисел, и отправляет его серверу, шифруя с помощью открытого ключа сервера (который был получен из сертификата сервера). Этот секрет является начальным значением, которое будет использоваться для генерирования сеансового ключа.
5. Как сервер, так и клиент применяют выбранный алгоритм (из шага 2) и сгенерированный случайным образом секрет (из шага 4) для генерирования одинакового одноразового ключа сеанса. Это симметричный ключ шифрования, потому что он будет использоваться как для шифрования, так и для расшифровки всего трафика на протяжении данного сеанса SSL.
6. Сервер и клиент обмениваются сообщениями (называемыми сообщениями ChangeCipherSpec ) для подтверждения того, что они готовы взаимодействовать безопасным образом.
7. Сервер и клиент шифруют весь трафик данного сеанса с помощью полученного ключа сеанса.

Шифрование для обеспечения секретности сообщения

В целях обеспечения секретности сообщений, или конфиденциальности, S/MIME использует асимметричные ключи (открытый и секретный ключи) для шифрования сообщений. По существу, это тот же метод, который используется в Notes и разъяснен в разделе о Notes PKI.

Для отправки зашифрованного S/MIME-сообщения необходимо получить открытый ключ получателя сообщения и зашифровать сообщение с его использованием. Так как единственным человеком, который имеет связанный с этим ключом секретный ключ, является получатель, сообщение может быть безопасно отправлено с уверенностью в том, что только его получатель будет способен расшифровать это сообщение. Данный метод полностью подобен методу, используемому в Notes, и представлен на рис. 6.16 и 6.26.

Это практическое применение гибридного решения, которое мы рассматривали в лекции об основах безопасности. Пронумерованные на рис. 6.26 шаги описаны далее.

1. Алиса решает отправить зашифрованное S/MIME-сообщение Бобу. Клиент обмена сообщениями, видя, что сообщения нуждаются в шифровании, генерирует случайный ключ шифрования (секретный ключ, который обычно упоминается как ключ сеанса; впоследствии новый случайный ключ генерируется каждый раз, когда отправляется зашифрованное S/MIME-сообщение) и зашифровывает с его помощью сообщение.
2. Ключ шифрования сеанса шифруется (с применением либо Triple-DES, либо RC2) с помощью открытого ключа получателя и прикрепляется к сообщению, а это означает, что расшифровать его будет способен только открытый⁸ RSA-ключ Боба.
3. Зашифрованный текст и зашифрованный ключ отправляются Бобу посредством SMTP.
4. Клиент обмена сообщениями Боба использует секретный RSA-ключ Боба для расшифровки зашифрованного ключа (снова с применением RC2) и получает расшифрованный ключ сеанса. Здесь гарантируется секретность, потому что для расшифровки ключа сеанса, необходимого для расшифровки сообщения, может быть использован только секретный ключ Боба.
5. Клиент обмена сообщениями Боба использует расшифрованный ключ сеанса для расшифровки почтового сообщения (с применением либо Triple-DES, либо RC2, в зависимости от того, с использованием какого алгоритма было зашифровано сообщение), результатом чего является расшифрованное исходное сообщение, которое было отправлено Алисой.

Если клиент обмена сообщениями Боба не способен расшифровать отправленную Алисой электронную почту, причиной этого возможно будет то, что Боб получил новый сертификат X.509 и открытый ключ в каталоге, к которому осуществляет доступ Алиса, является старым ключом.

Рассматривая показанный на рис. 6.26 процесс, мы увидим, что на самом деле этот метод в S/MIME часто упоминают как “цифровой конверт” (digital envelope), в силу чего сообщение фактически шифруется с использованием более короткого симметричного шифра, после чего симметричный шифр шифруется с использованием более длинного асимметричного ключа и отправляется вместе с зашифрованным сообщением.

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