IDM и Remote Loader: протух сертификат CA

Обсуждение технических вопросов по продуктам Novell

IDM и Remote Loader: протух сертификат CA

Сообщение Константин Ошмян » 11 янв 2018, 18:36

Добрый день!

Делюсь своим опытом, чтобы другие не наступали на те же грабли.

При использовании связки IDM MetaDirectory server <-> Remote Loader настоятельно рекомендуется трафик между ними шифровать. Для этого используется любой стандартный серверный сертификат (например, "SSL CertificateIP" или "SSL CertificateDNS", хотя можно создать и отдельный), который генерируется и подписывается сертифицирующей организацией дерева eDirectory. В свою очередь, самоподписанный сертификат этого CA экспортируется (в BASE64 - файл *.b64), копируется на компьютер с Remote Loader-ом, а ссылка на него прописывается в настройках инстанса этого Remote Loader-а.

Это удобно, т.к. по умолчанию серверный сертификат выдаётся на 2 года, и по истечении этого срока достаточно пересоздать серверные сертификаты и перезапустить драйверы IDM, которые ими пользуются. На Remote Loader-е ничего менять не надо, т.к. сертификат самого CA-я выдаётся на гораздо более длительный срок (10 лет), и он остаётся действительным.

Однако, рано или поздно, но эти 10 лет тоже истекают, и "протухает" сертификат самого CA-я. Его надо обновить, заново заэкспортировать сертификат с открытым ключом (public key) в *.b64-файл и обновить его на машине с Remote Loader-ом. Это немного неудобно (тем более, что единственный вариант обновления корневого сертификата, описанный официально, это пересоздание всего объекта CA). Тем не менее, не смертельно - расписано по шагам, и раз в 10 лет можно эту процедуру выполнить.

Казалось бы, всё хорошо: перезапускаем Remote Loader-ы с новыми корневыми сертификатами, и всё работает? А вот ни фига. Оказывается, заработает ли - зависит от того, какая именно реализация driver shim-а используется для IDM-овского драйвера на Remote Loader-е. Если native module (в параметрах инстанса, т.е. в его конфиг-файле, присутствует опция "-module" со ссылкой на реализующий её, например, DLL - скажем, драйвер для Active Directory), то всё хорошо. А вот если в параметрах вместо модуля есть ссылка на Java class (опция "-class" - например, драйвер LDAP или Lotus), то вместо ссылки на файл *.b64 (опция "rootfile") будет ссылка на Java-овский keystore (опция "keystore"), в который исходный сертификат ещё надо засунуть отдельным шагом. Это отнюдь неочевидно, поскольку при настройке инстанса манипуляции с keystore-ом производятся неявно где-то в фоне, и админ об этом может даже вообще не знать. Зная же, проблема решается просто, с помощью утилиты keytool (которая находится в папке jre/bin внутри папки с самим Remote Loader-ом).

Например, для 32-битного Remote Loader-а на платформе Windows, для первого истанса драйвера (порт по умолчанию 8000) можно сначала посмотреть содержимое keystore-а командой:
Код: Выделить всё
C:\Novell\RemoteLoader\jre\bin\keytool.exe -list -keystore C:\Novell\RemoteLoader\dirxml8000.keystore -storepass пароль

(конкретные имя файла и пароль можно подглядеть в конфиг-файле инстанса).
Пересоздать же этот кейстор после удаления можно командой:
Код: Выделить всё
C:\Novell\RemoteLoader\jre\bin\keytool.exe -import -alias trustedroot -file путь-к-CA-сертификату.b64 -keystore C:\Novell\RemoteLoader\dirxml8000.keystore -storepass пароль

Да, более новые версии создают не папку C:\Novell, а C:\NetIQ, а на 64-битных платформах ещё будет подпапка "64bit", но суть, я думаю, понятна.
Аватара пользователя
Константин Ошмян
 
Сообщения: 991
Зарегистрирован: 13 авг 2002, 21:36
Откуда: Рига

Вернуться в Novell

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4

cron