Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта
(Окончание. Начало в ╚КИ╩
╧ 13/2001, стр. 17)
Cтроить многоуровневую иерархию в рамках эксперимента не предполагалось, поэтому CA1 был сконфигурирован как Stand-alone root CA, CA2 ≈ как Enterprise root CA. Отличие первого режима от второго заключается в том, что центр сертификации предприятия интегрируется со службой Active Directory, тогда как отдельно стоящий ЦС ≈ нет. Соответственно, получение сертификатов с CA2 делалось с помощью оснастки MMC, называемой Certificates, а с CA1 ≈ через Web-сервер после заполнения соответствующих форм.
Есть еще одно интересное различие режимов работы ЦС. При настройках по умолчанию Stand-alone CA лишь заносит полученные запросы на выдачу сертификатов в список запрошенных сертификатов; только когда администратор даст разрешение, сертификат будет выпущен. Хотя можно установить и режим немедленной выдачи сертификатов. В режиме Enterprise возможна только немедленная выдача (по крайней мере, второй режим в настройках неактивен).
Другое заметное отличие заключается в том, что данные о пользователе Enterprise CA берет из службы каталогов, тогда как для Stand-alone CA эти данные вводятся в формы на Web-страничках. Это отличие стало причиной обнаружения одной ошибки в работе Outlook Express═5.0 c цифровыми сертификатами.
А было вот что: после установки центров сертификации пользователям CA1_user1 и CA2_user1 были сгенерированы ключи и выданы сертификаты. Теперь нужно было указать Outlook Express, какие сертификаты использовать (делается это в свойствах почтовой записи). Даже, если быть точнее, не сертификаты, а DigitalID (в разных источниках приводятся разные названия и трактовки этого термина; в данном контексте ≈ это совокупность пары ╚открытый ключ/секретный ключ╩ асимметричного шифрования и цифрового сертификата для открытого ключа, хотя иногда этим же термином обозначают и просто сертификат).
Для CA1_user1 при вводе данных через форму на Web-сервер имя было набрано в нижнем регистре. Поэтому, после получения сертификата, сопоставить DigitalID почтовой записи удалось без труда. Каково же было удивление, когда, получив с помощью оснастки Certificates сертификат для CA2_user1, в соответствующем окне почтового клиента список сертификатов оказался пустым. После продолжительного поиска причины на компьютер CA2.test2.ru был установлен ╚большой╩ Outlook из MS Office 2000, и он ╚увидел╩ нужный сертификат. Видимо, это была просто ошибка Outlook Express, связанная, например, с регистром, в котором набрано имя (ведь при генерации сертификата для CA2_user1 оно бралось из службы каталогов; соответственно, часть букв ≈ в верхнем регистре). Хотя это только предположение.
Итак, почтовые записи заведены, и им сопоставлены DigitalID. Отправляем первое письмо с электронной подписью. Как и ожидалось, получаем предупреждение от почтового клиента, встретившего электронную подпись и неизвестный ранее сертификат. Если бы центр сертификации был доступен в режиме on-line, то можно было бы проверить подлинность представленного сертификата, запросив сертификат самого ЦС и т.═д. по всей цепочке. Но в рамках эксперимента предполагалось, что такой возможности нет.
Чтобы была возможность проверить сертификат пользователя CA1_user1, экспортируем в файл сертификат его ЦС ≈ CA1.test1.ru. Имея этот файл в качестве помощи уже упоминавшейся оснастки Certificates, можно указать, что мы верим сертификатам, выданным этим ЦС. Но, таким образом, можно установить ╚доверие╩ для конкретного пользователя или конкретного компьютера (в зависимости от режима, выбранного при добавлении оснастки). Если же нужно установить доверие для всей организации, то эффективнее будет использовать механизм политик безопасности домена. Там можно добавить сертификат нужного ЦС в список доверяемых.
Хуже обстоит дело со списками отозванных сертификатов. Получив файл с CRL, указать в доменных политиках безопасности, что данные сертификаты недействительны, не удалось. Хотя локально это делается без проблем.
Подводя итог эксперимента, можно сказать, что задача организации защищенного обмена почтой может быть достаточно эффективно решена с использованием внутренних корпоративных ЦС на базе серверных платформ семейства Windows 2000.
Некоторое неудобство может вызвать только работа с отозванными сертификатами. Но выпуск таких списков в случае внутренних ЦС предприятия ≈ это не самое частое событие. Так что серьезной проблемой это, по-видимому, не является.
Анкета || Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка
Главная страница
Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл ╧ 77-4461 от 2 апреля 2021 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.
Телефон редакции (812) 118-6666, 118-6555.
Адрес: 196084, СПб, ул. Коли Томчака, д. 9
e-mail:
Для пресс-релизов и новостей