Без какого элемента не работает pki

Журнал ВРМ World

PKI: Как это работает

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

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

IPSec, протокол туннелирования Уровня 3 (сетевого уровня), сегодня обычно используется для шифрования и выделения данных для защищенной передачи по VPN корпоративных сетей. Ряд методов аутентификации, служащих для проверки идентичности допущенных пользователей, может реализовываться через IPSec, включая пароли, известные серверу и клиенту, доступ с передачей маркера и цифровые сертификаты. Для широкой реализации в экстранет самым простым методом является Инфраструктура Открытых Ключей (Public Key Infrastructure, PKI), использующая технологию цифровых сертификатов. Эта статья расскажет о том, как PKI работает в среде VPN.

Определение PKI

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

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

Простая PKI начинается с Certificate Authority (CA), программного пакета, используемого в защищенном режиме доверенной третьей стороной для выпуска цифровых сертификатов X.509v3. Цифровой сертификат представляет собой структуру электронных данных, связывающую значения открытого ключа с идентифицирующей информацией о конкретном предмете. Цифровой сертификат подписывается цифровым методом (авторизуется) с помощью выпуска Certificate Authority. Цифровой сертификат гарантирует любой сертифицированной организации, использующей открытый ключ, что соответствующий закрытый ключ хранится соответствующим удаленным предметом. Разъяснение полей информации в сертификате можно найти в RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL profile), опубликованном в Январе 1999 года. В сильнозащищенной области Certificate Authority также имеется как минимум X.509v3-совместимая база данных. CA-оператор выпускает цифровой сертификат к End Entity (конечной сущности; в данном случае — конечным точкам EE-IPSec) и сохраняет копию сертификата в базе данных для последующего обращения. Языком, используемым для любых запросов к базе данных X.509v3, является Lightweight Data Access Protocol v3 (LDAP v3).

Обслуживание недействительных сертификатов

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

В этом случае CA-оператор может пойти двумя путями. Сертификат может быть внесен в Certificate Revocation List (CRL-X.509v2) и выпущен на определенный срок. CRL остается в v2, так как было оговорено, что при переходе других компонентов на v3 в него не было внесено никаких изменений. Либо аннулирование сертификата осуществляется с помощью Online Certificate Status Protocol (OCSP) на онлайновом сервере, представляющим собой, например, сервер базы данных X.509 v3, обеспечивающий сервис такого рода.

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

Как работает сложная PKI

Сложная PKI может использовать множество различных CA с Root CA (корневыми CA). Root CA хранит «собственноручно» подписанный сертификат и выпускает сертификаты для подчиненных CA (т.е. относящихся к более низкому уровню), которые, в свою очередь, могут выпускать сертификаты для различных RA (Registration Authorities) или LRA (Local Registry Authorities). В процессе работы RA или LRA получает исходный запрос на сертификат от запрашивающей стороны и передает аутентифицированный запрос своему CA, выпускающему этот сертификат. Иерархия различных CA напоминает дерево, именно поэтому исходный CA назван Root CA (см. Рис. 1).

К этому моменту между всеми EE (в данном случае — конечными точками IPSec) всех подчиненных СА устанавливается «цепь взаимного доверия» (chain of trust). Однако как EE-1, Relying Party (полагающаяся на сертификат сторона, RP), чей сертификат выпущен CA-1, узнает, что сертификат EE-5, выпущенный CA-2, заслуживает доверия? Это происходит следующим образом:

1. Сначала EE-1 проверяет либо все CRL либо использует OCSP, чтобы определить допустимость сертификата EE-5.
2. Затем EE-1 проверяет, кто подписал сертификат EE-5, и обнаруживает, что авторизующей стороной является CA-2.
3. Теперь EE-1 необходимо узнать, кто такой CA-2, поэтому она проверяет, кто подписал сертификат CA-2.
4. EE-1 обнаруживает, что это был CA-0, корневой сертификат, подписавший и сертификат CA-1.
5. CA-1 выпускает и подписывает сертификат EE-1.

Эта информация обеспечивает проверку допустимости EE — 5, так как они находятся в рамках одной PKI. Такая процедура называется «проход по цепи доверия» или просто «проход по цепи». Это основные элементы работы отдельной PKI. Далее в этой статье будут рассмотрены множественные реализации PKI. Сертификационная политика (Certificate Policy) устанавливает основные правила. Независимо от того, сама ли компания, реализующая PKI, использует CA, или поручает это делать кому-то еще, она все равно должна определить для себя Сертификационную политику (Certificate Policy, CP). CP очерчивает требования, необходимые в процессе аутентификации для получения сертификата от CA, а также может определять уровень полномочий (например, «этот сертификат имеет право подписи информации по сделкам, не превышающим один миллион долларов «).

В случае конечной точки IPSec CP определяет, какая информация должна быть предъявлена CA для аутентификации до выпуска сертификата для этой конечной точки. Он также определяет, какую информацию будет содержать индивидуальный сертификат и как он будет выглядеть. CP определяет обновление CRL или требования размещения уведомления об аннулированном сертификате на сервере OCSP. Кроме того, CP может также определять требования физической безопасности, которым должен соответствовать CA.

Присвоение и регистрация Объектного Идентификатора (Object Identifier)

Когда CP уже сформулирована, ее следует разместить на сайте компании. Компания, составляющая CP, должна быть зарегистрирована через IANA (Internet Assigned Numbers Association), чтобы ее CP был присвоен Объектный идентификатор (Object Identifier, OID). OID представляет собой представление компании в численной форме. Этот OID следует поместить в сертификат, чтобы RP (лицо, получающее данный сертификат) могло найти и ознакомиться с CP сертификата на сайте идентифицируемой компании. Прочитав CP, RP самостоятельно решает, заслуживает ли данный сертификат доверия.

Написание Положения об использовании сертификата (Certificate Practice Statement)

Для успешной реализации CA, в зависимости от уровня необходимой авторизации, оператор CA должен либо написать специальное Положение об использовании сертификата (Certificate Practice Statement, CPS) либо составить общее CPS. CPS представляет собой документ, описывающий подробности реализации CP и объясняющий порядок соотнесения CA с требованиями CP. По правилам American Bar Association, идентификатор CPS (OID) также должен включаться в сертификат. Эта информация в дальнейшем позволит RP проверять квалификацию Certificate Authority.

Создание собственного CA

Если компания реализует собственный CA, она должна создать также и CP и CPS. Лучшим справочным материалом при написании CP и CPS является RFC 2527 (Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework), увидевшая свет в марте 1999 года. Прежде, чем публиковать CP и CPS, необходимо также проконсультироваться с юристами компании. Тем не менее, не следует ждать от них особой помощи ни в вопросе создания CP, ни CPS — к сожалению, очень немногие корпоративные юристы способны разбираться в таких вещах.

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

Взаимная сертификация означает, что сертификат, выпущенный одной PKI, становится применим в другой PKI. И CP и CPS каждой из PKI будет проверен другой PKI с целью убедиться, что их сертификаты можно рассматривать как равнозначные относительно важных для них аспектов (не совсем верно было бы называть их полностью «равнозначными», так как юридически это означало бы и словесное совпадение). Взаимная сертификация представляет собой простое физическое действие: каждый CA выпускает для другого сертификат, содержащий Policy Mappings Extension (Расширенное отображение политики), закрепляющий вышеуказанное соглашение. Сложность состоит в согласовании соглашений CP и CPS между двумя PKI.

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

Отдельный Bridge CA обменивается взаимными сертификатами со всеми Root CA имеющихся PKI. Это уменьшает длину цепочки, которую необходимо пройти EE, чтобы провести аутентификацию сертификата, предъявленного ей извне ее PKI. Это основная причина реализации Bridged PKI, однако такая технология выгодна потому, что она упрощает аннулирование взаимной сертификации. Вместо размещения 12 сертификатов необходимо будет разместить только один — тот, что выпущен Bridge CA для взаимной сертификации. Итак, мы разобрались с основными понятиями технологии PKI. А теперь самое сложное… Реализация PKI: заказывать или делать самим?

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

Источник

Инфраструктура Открытых Ключей (PKI)

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

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

Терминология PKI

Закрытый Ключ (Private Key) Блок данных (большое двоичное число), созданное с использованием алгоритмов PKI. Каждый из сторон, осуществляющих передачу информации безопасным образом, должна хранить свой Закрытый Ключ так, чтобы исключить к нему доступ посторонних. Этот ключ никогда не должен передаваться между сторонами, осуществляющими обмен информацией. Открытый Ключ (Public Key) Блок данных (большое двоичное число), созданный вместе с Закрытым Ключом. Каждая сторона, осуществляющая безопасные коммуникации, может и должна публично распространять свой Открытый Ключ. Изначально предполагается, что Открытый Ключ известен всем, в том числе и злоумышленникам. Открытые Ключи обычно распространяются в виде Сертификатов. Дайджест Данных (Data Digest) Относительно небольшой блок данных, вычисленный с применением к оригинальному блоку данных (обычно большего размера) специальных дайджест-функций (хэш-функций). Подпись Данных (Data Signature) Дайджест блока Данных, зашифрованный с использованием Закрытого Ключа Подписывающего. Подписанные Данные (Signed Data) Блок Данных, к которому прилагается Подпись этого блока. Сторона, получающая Подписанные Данные, используя Открытый Ключ Подписывающего может расшифровать Подпись и, сравнив получившийся Дайджест Данных с Дайджестом Данных, вычисленным самостоятельно, может убедиться, что блок данных не был изменён в процессе передачи. Сертификат (Certificate) Блок данных, содержащий имя владельца Сертификата (называемом так же Темой Сертификата), Открытый Ключ владельца, имя Издателя Сертификата, Серийный Номер Сертификата и некоторые дополнительные элементы данных. Такой блок данных подписывается Издателем Сертификата.
Сертификаты играют роль Цифровых идентификационных карт (удостоверений). Издатель (Issuer) Сторона, которая выпускает сертификаты для третьих лиц, подписывая их своим Закрытым Ключом Издателя. Издатели так же называются Центрами Сертификации (Удостоверяющими Центрами). Каждый сертификат, созданный определённым Издателем, имеет уникальный серийный номер. Доверенные Центры Сертификации (Trusted Authorities) Список, индивидуально ведущийся стороной, обменивающейся информацией. Каждый элемент списка содержит имя «доверенного центра сертификации» и его Открытый Ключ.
Когда сторона получает любой Сертификат, она может проверить, включён ли Издатель в список «доверенных центров сертификации» и с помощью Открытого Ключа этого «доверенного центра сертификации» проверить Подпись Сертификата.
Современные операционные системы позволяют пользователям безопасно вести базу данных Доверенных Центров Сертификации. Корневые Центры Сертификации (Root Authorities) Повсеместно признаваемые Центры Сертификации. Большинство современных операционных систем по умолчанию содержат несколько Корневых Центров Сертификации в базе данных Доверенных Центров Сертификации, что делает эти Корневые Центры Сертификации доверенными для всех пользователей этого компьютера, работающих в этой операционной системе. Цепочка Сертификаций (Authority Chain) Набор Издателей Сертификата для определённого Сертификата.
Некоторый Центр X может не быть широко распространён как «доверенный», но его собственный Сертификат может быть выпущен более широко признаваемым Центром Y. В этом случае, Сертификаты, выпущенные X, не будут признаваться, но если эти Сертификаты посланы вместе с собственным Сертификатом Центра X, выпущенным Центром Y, то эти Сертификаты могут быть признаны всем сторонами, которые доверяют Центру Y. Само-Подписанный Сертификат (Self-Signed Certificate) Сертификат, выпущенный стороной самой для себя. Тема и Издатель такого Сертификата совпадают. Само-Подписанный Сертификат содержит Открытый Ключ стороны и подписан Закрытым Ключом этой же стороны.
Само-Подписанные Сертификаты могут быть доверенными только если другие стороны явно включили их в свои списки «доверенных центров Сертификации». Многостороннее Шифрование (Multiparty Encryption) Метод шифрования, используемый для отправки данных нескольким сторонам с известными Сертификатами. Зашифрованные один раз сообщения могут быть независимо от других сторон расшифрованы любой стороной, которая обладает Закрытым Ключом, соответствующий одному из Сертификатов, используемых при шифровании.

Установки PKI Домена

Для изменения Установок PKI для какого-либо Домена, откройте через Веб Интерфейс Администратора страницу Установки Домена и нажмите на ссылку Безопасность. Появится страница с настройками PKI:

Эта опция позволяет вам выбрать режим PKI для этого Домена:

Выключено Если указана эта опция, то функции PKI для этого Домена выключены. Если указана эта опция, то все другие Установки PKI Домена игнорируются. Test Если указана эта опция, то для этого Домена будут использоваться Общий для Сервера Тестовый Закрытый Ключ и Тестовый Сертификат. Если эта опция указана, то вы не должны указывать другие Установки PKI Домена. Используйте этот режим только для тестовых целей.
Общий для Сервера Тестовый Сертификат содержит в поле Тема имя Главного Домена и AO StalkerSoft в поле Издатель. Этот Сертификат действителен в течение 30 дней с момента последнего перезапуска Сервера. Включено Если эта опция выбрана, активируются все другие Установки PKI Домена.

Назначение Закрытого Ключа

Первоначально Домены CommuniGate Pro не имеют Закрытых Ключей. Вы должны ввести размер ключа и нажать на кнопку Сгенерировать Ключ для создания случайного Закрытого Ключа и назначения его этому Домену.

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

Только после назначения Закрытого Ключа на странице Безопасность появятся поля, связанные с Сертификатами.

Для того, чтобы создать Закрытый Ключ, вы можете использовать программы сторонних производителей (такие, как OpenSSL). Вы должны указать такой программе вывести Закрытый Ключ в PEM формате (как показано ниже).
Выберите пункт Импортировать в меню Размер Ключа и нажмите на кнопку Сгенерировать Ключ. Появится текстовое поле. Скопируйте Закрытый Ключ в PEM-формате (или в формате RSA или PKCS#8) в это текстовое поле, и нажмите на кнопку Сгенерировать Ключ:

Обратите внимание: Убедитесь, что импортируемый ключ не зашифрован паролем. Текст, первые строки в котором имеют примерно такой вид:

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

Если Закрытый Ключ установлен корректно, и этот Ключ может использоваться для асимметричной криптографии, вы увидите следующую панель:

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

Используйте кнопку Удалить Ключи и Сертификат, чтобы удалить введённый Закрытый Ключ Домена. Так как Сертификат Домена может использоваться совместно с одним и только одним Закрытым Ключом, то он станет бесполезным, когда вы удалите Закрытый Ключ; таким образом существующий Сертификат Домена также будет удалён.

Назначение Сертификата

Для поддержи функций Инфраструктуры Открытых Ключей, Домен должен иметь Сертификат.

Имя Сертификата Домена (часть Имени-Идентификатора поля Тема Сертификата) должно соответствовать имени домена, используемого клиентскими приложениями.
Если Домен CommuniGate Pro имеет Псевдонимы Домена, попытки соединения с Сервером с использованием Псевдонима Домена приведут к появлению предупреждения на компьютере клиента, уведомляющего пользователя о несоответствии в именах. Так как Сертификат может содержать только одно имя, выбирайте имя (реальное имя Домена или один из Псевдонимов Домена), которое будут использовать ваши пользователи в своих клиентских приложениях. Если имя вашего Домена CommuniGate Pro company.dom, и это имя домена не имеет A-записи в DNS, но Домен имеет псевдоним mail.company.dom, который, в свою очередь, имеет A-запись в DNS, указывающую на Сервер CommuniGate Pro, то ваши пользователи будут использовать имя mail.company.dom в настройках своих клиентских приложений и в URL Веб Интерфейса Пользователя, так что Сертификат Домена должен быть выпущен на имя mail.company.dom, а не на company.dom.

Вы так же можете использовать «шаблон подстановки» имён домена для ваших сертификатов. Если имя Домена имеет минимум 2 компоненты, то меню Имя-Идентификатор будет содержать «шаблон подстановки» имени Домена: первая компонента имени Домена будет заменена символом звёздочка (*). Если имя Домена состоит из только двух компонент, то компонент звёздочка будет добавлен для формирования трехкомпонентного имени.

Для создания Сертификата, заполните все поля в таблице Атрибутов Сертификата:

Имя-Идентификатор Когда Сертификат посылается клиентскому приложению, приложение проверяет соответствие Имени-Идентификатора Сертификата с именем, указанным пользователем в URL и/или в настройках почтовой программы. Контакт Это поле должно содержать корректный адрес электронной почты; этот адрес не обязательно должен быть в Домене CommuniGate Pro.

Все другие поля являются необязательными для заполнения.

Для того, чтобы получить Сертификат из внешнего источника, (из «доверенного центра сертификации»), нажмите кнопку «Создать Запрос на Подписание». Появится текстовое поле, содержащее CSR (Запрос на Подписание Сертификата) в PEM-формате:

Скопируйте текст CSR и передайте его в выбранный вами Центр Сертификации (CA). Вы можете передать его по электронной почте или через специальную Веб форму на сайте CA. Центр Сертификации должен вернуть вам подписанный Сертификат в PEM-формате. Введите Сертификат в поле внизу и нажмите кнопку Установить Сертификат.

Если Сертификат принимается, то отображается информация о нём:

Панель с информацией о Сертификате показывает имя Издателя Сертификата (Центра Сертификации), Тему Сертификата (данные, которые вы ввели и имя домена), серийный номер Сертификата и срок его действия.

Обратите внимание: введённый Закрытый Ключ будет использоваться для безопасного обмена информацией ТОЛЬКО при условии, что опция Услуги PKI Криптографии имеет значение Включено.

Обратите внимание: в Сертификате в данных «Темы» содержится имя Домена или Псевдонима Домена.
Когда вы переименовываете Домен в CommuniGate Pro, имя домена в Сертификате Домена не изменяется, и клиентские приложения могут начать предупреждать пользователей о несоответствии в имени.

Для того, чтобы удалить Сертификат Домена, нажмите на кнопку Удалить Сертификат.

Назначение Цепочки Сертификации

Если Издатель Сертификата известен программному обеспечению пользователя (почтовым программам и браузерам), то, когда клиент получает от Сервера Сертификат, предупреждающее сообщение на экране пользователя не появляется. Во многих случаях, «Доверенный Центр Сертификации» не выпускает сертификаты самостоятельно. Вместо этого, он делегирует право выпускать сертификату какому-нибудь третьему Центру Сертификации (Удостоверяющему Центру). Когда ваш Сервер использует Сертификат, выданный таким Центром Сертификации, Сервер так же должен предоставлять Сертификат этого Центра Сертификации, выданный «Доверенным Центром Сертификации». Программное обеспечение клиента проверит сначала ваш Сертификат, обнаружит, что эмитент вашего Сертификата не является «Доверенным Центром Сертификации», и затем проверит дополнительный Сертификат(ы), которые предоставил Сервер. Если такой дополнительный Сертификат выпущен «Доверенным Центром Сертификации», и он подтверждает эмитента вашего Сертификата Домена, то ваш Сертификат принимается без предупреждений.

Когда вы получаете Сертификат из Центра Сертификации, который не указан в списке «Доверенных Центров Сертификации» в клиентском программном обеспечении, то этот промежуточный Центр Сертификации так же должен предоставить вам свой собственный Сертификат, подписанный «Доверенным Центром Сертификации». Этот Сертификат должен быть в таком же PEM-формате, как и ваш Сертификат Домена:

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

Если ваша Цепочка Центров Сертификации содержит несколько отдельных Сертификатов в PEM-формате, введите их всех в поле Цепочка Сертификации (Необязательно). Сертификат, выданный Корневым Центром Сертификации, должен быть последним в списке.

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

Обратите внимание: CommuniGate Pro проверяет только формат каждого Сертификата в цепочке. Он не проверяет, например, что каждый Сертификат действительно удостоверяет эмитента предыдущего Сертификата, или что последний Сертификат выдан Корневым Центром Сертификации.

После того, как Цепочка Сертификации установлена, она отправляется клиентам вместе с Сертификатом Домена.

Нажмите на кнопку Удалить Цепочку для удаления Цепочки Сертификации из Установок Безопасности Домена.

Использование Само-Подписанных Сертификатов

Если вы не хотите использовать внешний Центр Сертификации, то вы можете создать Само-Подписанный Сертификат.
Нажмите на кнопку Создать Само-Подписанный и Сервер CommuniGate Pro создаст для вас Само-Подписанный Сертификат: издателем будет то лицо, которое вы указали, и Сертификат будет подписан Закрытым Ключом Домена. Если Домен имеет Само-Подписанный Сертификат, клиентские приложения будут предупреждать пользователя, что используемый сервер представил сертификат, «выпущенный неизвестным центром». Пользователи могут «установить» самоподписанные сертификаты, чтобы избежать появления этих предупреждений.

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

Ваши пользователи могут «установить» ваш Сертификат Домена в свои списки Доверенных Центров Сертификации. После установки, Сертификат становится «доверенным». Для некоторых программ (такие, как Mac-версии Microsoft Outlook и Outlook Express), установка «недоверенного» Сертификата является единственным способом использования этого Сертификата для безопасного обмена информацией.

Для установки Сертификата Домена, пользователь должен использовать браузер и открыть через Веб Интерфейс Пользователя для требуемого Домена страницу входа. Если в Домене включены Сертификаты, то появится ссылка на Сертификат Безопасности. Пользователь должен перейти по этой ссылке для загрузки Сертификата Домена и «открыть» его. Браузер должен позволить пользователю проверить Сертификат и установить его в список Доверенных Центров Сертификации.

Если в Домене есть Само-Подписанный Сертификат, то на странице Веб Администрирования появляется кнопка «Обновить Само-Подписанный». Нажмите на эту кнопку что создать новый Само-Подписанный Сертификат с тем же самым серийным номером, но с новым сроком действия.

Доверенные Корневые Сертификаты

Сертификат считается действительным, если:

• он совпадает с одним из Доверенных Сертификатов, или
• он выдан одним из обладателей Доверенных Сертификатов.

Есть несколько наборов Доверенных Сертификатов:

• Встроенные доверенные Сертификаты: эти сертификаты устанавливаются вместе с Сервером CommuniGate Pro, и обновляются вместе с обновлением Сервера.
• Общесерверные и общекластерные Доверенные Сертификаты.
• Общие для Домена Доверенные Сертификаты.

Когда выполняется любая PKI-операция для какого-нибудь Домена (или для определённого Пользователя в этом Домене), проверяются следующие Доверенные Сертификаты:

• Доверенные Сертификаты Домена
• Общекластерные Доверенные Сертификаты, если Домен обслуживается в Кластере и общесерверные Доверенные Сертификаты, если Домен не обслуживается в Кластере
• встроенные Доверенные Сертификаты

Когда PKI-операция выполняется для нужд самой Системы (например, при установке исходящего TLS-соединения), проверяются следующие Доверенные Сертификаты:

• Общесерверные Доверенные Сертификаты
• Общекластерные Доверенные Сертификаты
• встроенные Доверенные Сертификаты

Используйте Веб Интерфейс Администратора для обновления Общсерверных и Общекластерных Доверенных Сертификатов. Откройте страницу Безопасность в разделе Пользователи. Откроется страница Доверенные Сертификаты:

Включённые в показываемый список Доверенные Сертификаты имеют слева кнопку-флажок. Для удаление выбранных Сертификатов, отметьте флажок и нажмите кнопку Удалить Помеченные.

В дополнение к показанным Сертификатам, Общие для Домена страницы показывают встроенные Доверенные Сертификаты и Общесерверные Доверенные Сертификаты (или Общекластерные для Распределенных Доменов).
Общесерверные и Общекластерные страницы с Доверенными Сертификатами показывают встроенные Доверенные Сертификаты.
Рядом с этими дополнительными сертификатами нет кнопки-флажка.

Для того, чтобы добавить Сертификат, введите данные Сертификата в PEM-формате в текстовое поле и нажмите кнопку Установить Сертификат. В показываемом списке должен появиться новый Сертификат.

Безопасные Соединения SSL/TLS

Сервер CommuniGate Pro поддерживает SSL/TLS соединения для всех сервисов и модулей, использующих TCP. Безопасные соединения могут устанавливаться двумя способами:

• Клиентское приложение использует специальный порт для соединения с Сервером и начинает устанавливать TLS (зашифрованное) соединение сразу после установления TCP-соединения на этот порт. Этот метод используется всеми браузерами, при задании URL вида https://.
  Этот метод используется также, когда в SIP-клиенте активирована опция «TLS-транспорт».
  Некоторые почтовые клиенты используют её для POP, IMAP, LDAP и (редко) SMTP соединений.
  Для поддержки таких клиентов, настройте Приёмники для HTTP, SIP, POP, IMAP, SMTP и LDAP модулей: Приёмники должны принимать TCP-соединения на специальные порты (смотрите правильные Безопасные Номера Портов в описаниях модулей) и опция Начальный SSL/TLS должна быть включена для этих портов.
• Клиентское приложение использует стандартный порт для связи с Сервером, и затем передаёт специальную команду (обычно называемую STARTTLS или STLS) через установленное незащищенное TCP-соединение. Когда Сервер получает такую команду он начинает устанавливать безопасное соединение. Для поддержки таких клиентов вы не должны настраивать дополнительные порты в модуле Приёмники.

Обычно Сертификаты для SSL/TLS коммуникаций могут быть назначены только для таких Доменов CommuniGate Pro, которые имеют минимум один назначенный сетевой (IP) адрес. Это ограничение происходит из-за дизайна TLS-протокола, используемого сегодня: когда клиентское приложение хочет инициировать безопасное соединение, у Сервера нет информации о Домене, с которым хочет соединиться клиент. Сервер знает только, на какой местный IP-адрес обратился клиент, и поэтому он открывает тот Домен, которому назначен этот IP-адрес, и использует PKI Установки именно этого Домена.

Исключением из этого правила является XMPP протокол. До того, как XMPP клиент посылает команду starttls, он явно указывает имя требуемого домена в данных , и таким образом, Сервер может инициировать TLS-сессию с Доменом, который не имеет назначенного сетевого адреса.

Чтобы настроить Общесерверные параметры работы с SSL/TLS, используйте Веб Интерфейс Администратора. Откройте в области Установки страницу Общее, затем откройте страницу Прочее:

Уровень Журнала Используйте эту настройку для того, чтобы указать какую информацию модуль TLS должен сохранять в Журнале работы Сервера. Записи, помещённые модулем TLS в Журнал работы Сервера, имеют пометку TLS. Время жизни Эта настройка указывает время кэширования TLS-сессий. Когда все соединения, использующие TLS-сессию, закрываются, Сервер будет ждать указанное время до удаления параметров TLS-сессии. Эта возможность позволяет клиентам устанавливать новые соединения, возобновляя старые TLS-сессии. Это уменьшает время создания соединений и снижает загрузку Сервером центрального процессора. Эта возможность особенно важна для HTTP-клиентов, открывающих и закрывающих соединения очень часто. Mинимальная Версия Эта установка задаёт самую старую допустимую версию протокола SSL/TLS. Если удалённая сторона указывает поддержку версии SSL/TLS старее, чем указано в этой установке, то попытка создания безопасного соединения отвергается.
Этот параметр действует только на входящие соединения. Обрабатывать Имя адресуемого Домена Если эта установка включена, сервер поддерживает расширение протокола TLS, которое позволяет клиентам указываеть имя Домена Сервера, к которому они подсоединяются. Это свойство позволяет обслуживать несколько доменов с использованием TLS, используя единственный сетевой адрес IP. CBC Шифрования для старых TLS Выберите эту настройку, если вы хотите поддерживать методы шифрования CBC с SSL 3.0 и TLS 1.0. Методы шифрования CBC всегда поддерживаются для пакетных протоколов (DTLS). Слабые Шифрования Выберите эту настройку, если вы хотите поддерживать слабую (менее чем 128-битную) безопасность (методы кодирования). Также должна быть включена установка поддержки Методов шифрования CBC . Принимать SSLv2 'hello' Если включена эта установка, Сервер принимает начальные запросы в стиле протокола SSL 2.0, используемые многими старыми клиентами.
Обратите внимание: даже когда эта установка включена, для самого соединения используется протокол SSL 3.0 или TLS, протокол SSL 2.0 для соединения не используется. Нет разумной причины выключать эту настройку — разве только для прохождения «тестов на безопасность». Отсоединяться получив неверный Сертификат Если Сервер потребовал от клиента предоставления Сертификата, то клиент может отправить некорректный сертификат: просроченный, выданный другому пользователю и т.д.
Если включена это опция, то процесс установления TLS соединения будет прерываться. Если эта опция выключена, то некорректные сертификаты игнорируются.

Сертификаты Клиентов

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

Через Веб Интерфейс Администратора откройте страницу Установки Домена для этого Домена и нажмите на ссылку Безопасность. Появится страница с настройками PKI:

Кем Выдан Выберите один из Доверенных Сертификатов, указанных для этого Домена.
Когда Доверенный Сертификат выбран, то от TLS-клиента, устанавливающего соединение с этим Доменом, будет потребовано предоставление действительного сертификата, выпущенного владельцем выбранного Доверенного Сертификата. Эти сертификаты могут использоваться для Аутентификации По Сертификату. Обязателен Если указана эта опция, то TLS соединения с Доменом смогут устанавливать только клиенты, предоставляющие действительные Сертификаты.

Сервер CommuniGate Pro обрабатывает запросы на клиентские сертификаты при установлении соединений TLS с внешними серверами (по протоколам SMTP, XMPP, SIP, POP и другим). В качестве клиентского при этом отправляется Сертификат TLS, установленный в Главном Домене.

Функциональность S/MIME

Для того, чтобы конечные пользователи могли использовать S/MIME безопасность, все они должны обладать своими собственными PKI-ключами. Каждый пользователь должен иметь Закрытый Ключ, безопасно хранящийся в месте, доступном только для этого пользователя, и соответствующий ему Открытый Ключ, встроенный в Сертификат. Этот Сертификат должен быть выдан Центром Сертификации (Удостоверяющим Центром), которому доверяют другие пользователи.

Веб Интерфейс Пользователя и XIMSS Интерфейс CommuniGate Pro поддерживают функциональность S/MIME. Сервер обеспечивает безопасное хранение Закрытых Ключей пользователей. Эти ключи могут быть разблокированы и использованы исключительно самими пользователями через указанные Интерфейсы.

Чтобы использовать обычное клиентское приложение на компьютере пользователя (POP, IMAP, или MAPI клиент), Закрытый Ключ пользователя должен храниться в специальном PKI-хранилище операционной системы компьютера.
Веб Интерфейс Пользователя и XIMSS Интерфейс могут экспортировать и импортировать Закрытые Ключи, так что пользователи могут использовать один и тот же Закрытый Ключ как для приложений, запущенных на своём компьютере, так и при работе через Интерфейсы. Дополнительную информацию смотрите в разделе Безопасная почта.

Установки S/MIME Домена

В Сервере CommuniGate Pro используется Сертификат Сервера, выдающий Сертификаты пользователям.

Домен CommuniGate Pro может выступать как Центр Сертификации (Удостоверяющий Центр) для всех его Пользователей, если:

• Опция Услуги PKI Криптографии Включена.
• Домен имеет действительный Закрытый Ключ.
• Домен имеет действительный специальные S/MIME Сертификат.

Чтобы задать S/MIME Установки Домена, используйте Веб Интерфейс Администратора и откройте страницы Установки Домена. Откройте страницу Безопасность и нажмите на ссылку S/MIME. Если Домен имеет действительный Закрытый Ключ, то показывается страница, подобная той, что показывается при работе с обычным Доменным Сертификатом. Эти поля используются для ввода специального S/MIME сертификата Домена. Этот Сертификат используется как Издатель (Центр Сертификации) для всех S/MIME Сертификатов, запрашиваемых пользователями в этом Домене.

Автоматическое Шифрование S/MIME

Возможности S/MIME могут быть использованы для безопасного хранения сообщений. CommuniGate Pro может зашифровывать все или только определённые сообщения до сохранения их в папках пользователей.

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

Сообщения шифруются S/MIME Сертификатом владельца папки. Если действие Записать Зашифровано в, заданное в Правилах, используется в Правиле уровня Пользователя (то есть Правила, заданного Пользователем или Правила, Общего для Домена), и указанная папка не принадлежит Пользователю, сообщение шифруется при помощи Сертификата владельца папки и текущего Пользователя.

Пример: Пользователь под именем john имеет Правило, которое выполняет следующее действие:
Записать Зашифровано в

jim/INBOX
Когда выполняется это действие, сообщение сохраняется зашифрованным с использованием обоих Сертификатов john и jim в Папке INBOX Пользователя jim. И john, и jim смогут расшифровать и прочитать это сообщение.

Шифрование Хранимых Сообщений

После того, как пользователь CommuniGate Pro получил некие незашифрованные сообщения, он может предпочесть хранить их в Папках на Сервере зашифрованными. MAPI и XIMSS клиенты, а также Веб Интерфейс Пользователя обеспечивают функции Зашифровать и Расшифровать, которые позволяют пользователям зашифровывать и расшифровывать отдельные сообщения в своих Папках.

Добавление DKIM-Подписи

DKIM (DomainKeys Identified Mail) это метод аутентификации E-mail сообщений, основанный на добавлении к письму особого заголовка с цифровой Подписью. Подпись создаётся методом шифрования на основе Закрытого и Открытого Ключей. Принимающий сервер может использовать Открытый Ключ, чтобы проверить, что Подпись соответствует Закрытому Ключу, и что тело письма и наиболее важные заголовки не были изменены в процессе пересылки.

Чтобы задать DKIM Установки Домена, используйте Веб Интерфейс Администратора и откройте страницы Установки Домена. Откройте страницу Безопасность и нажмите на ссылку DKIM.

Чтобы включить добавление Подписей к исходящим сообщениям, нужно выполнить следующие шаги:

Создать (или импортировать созданный внешней утилитой) Закрытый Ключ, подобно назначению Закрытого Ключа для Домена.
После того, как Закрытый Ключ будет назначен, соответствующий Открытый Ключ будет показан.

Закрытый Ключ
Размер:	1024 bit
Тест Ключа:	Verification String is OK

Открытый Ключ

Параметры DKIM-Подписи
Домен:	mail.dept1.company.com
Селектор:	mail

Подписывать исходящие Сообщения

Включено:

Рекомендуется регулярно (приблизительно раз в 3 месяца) производить ротацию Ключей, путём генерации нового Закрытого Ключа и создания новой DNS-Записи с новым Селектором.

Обратите внимание: DKIM Подписи составляются компонентой Enqueuer при постановке сообщения в Очередь, но физически добавляются, когда сообщение сохраняется или отправляется.

Обратите внимание: В процессе составления DKIM Подписей принадлежность сообщения к Домену определяется адресом в заголовке From: сообщения. Пользователь из другого Домена может изменить адрес в From: так, что его письма будут подписываться согласно настройкам текущего Домена. Также, сообщения, пересылаемые через CommuniGate сервер из внешних источников, могут быть подписаны текущим Доменом, если их адреса в From: совпадают с именами объектов в текущем Домене.

Источник