Защищённый web-сервер и синхронизация CRL'ов
Дано: защищённый web-сервер (в данном конкретном случае Apache 2.2.11), с строгой проверкой клиентских сертификатов
SSLVerifyClient require SSLVerifyDepth 10
Задача правильного построения защищённого сервера строго требует указания в конфиге Apache как синимум сертификата Центра Авторизации (традиционно именуемого ca.crt) и, по-хорошему, списка отозванных сертификатов ($SSL_INDEX.crl).
Ситуация потребовала развернуть второй аналогичный сервер (в смысле использующий ту же базу сертификатов доступа).
Проблема заключается в том, что CRL периодически обновляется. И для корректного решения задачи необходимо синхронизировать СОС'ы на обоих серверах.
Городить огород из скриптов вокруг ssh не хотелось бы.
Данная функциональность вроде бы должна быть реализована в рамках web-сервера. Однако ничего кроме mod_revocator образца 2006-го года (разработка в рамках Федориного Горя) я ничего не нашёл.
Странно. Задача-то вроде бы типовая... Должно быть решение.
Или никто так глубоко не зекапывался, или я что-то упустил.
- Для комментирования войдите или зарегистрируйтесь
Речь идёт о синхронизации
Речь идёт о синхронизации определённых файлов между двумя серверами?
/ Enchant /
"Никакую проблему нельзя решить на том же уровне, на котором она возникла"
/
Если не заморачиваться с инфраструктурой и логикой SSL (+ Центров Авторизации), а также здравым смыслом, то задачу можно привести к такому виду.
Собственно, после подобного исправления формулировки, задача достаточно просто решается сочинением скрипта использщующего стандартную функциональность SSH.
Но данное решение я считаю неспортивным. Впрочем,
mod_revocatorс точки зрения идеологии и здравого смысла тоже не безупречен...:wq
--
Live free or die
Я думаю такое решение можно
Я думаю такое решение можно превратить в спортивное :-)
Например, использовать app-misc/fsniper или sys-process/incron для отслеживания модификаций над файлами по событиям inotify в ядре и дальше передача изменений либо напрямую через ssh на другой сервер либо через sys-cluster/csync2.
__
Я, конечно, не очень в курсе как устроена инфраструктура SSL с центром авторизации, но есть еще мысль: если поддерживается хранение SSL-сертификатов в openldap, а не файлами, то можно сделать master-master кластер openldap и всё очень красиво решается.
/ Enchant /
"Никакую проблему нельзя решить на том же уровне, на котором она возникла"
Нельзя :)
Просто по определению. В силу направления поиска решения :)))
Про
sys-cluster/csync2я конечно почитаю... :)Но сделал проще и вернее: на сервере, который держит основную базу сертификатов расширил процедуру отзыва сертификата. Теперь она помимо прочего посредством ssh копирует СОС на ведомый сервер и перезапускает там Apache (ну а при ошибке копирования матерно ругается по электронной почте).
Каким макаром сюда можно приплести ядро не понял.
Мысль про перевод базы сертификатов из файлов в OpenLDAP мне нравится. Настолько, что я лениво размышляю над ней.
Но в рамках данной задачи есть проблема с механизмом извелечения СОС'а из LDAP'а. В
mod_revocatorтакая функциональность заявлена, альтернативных способов я не знаю.В действительности, насколько мне известно, Центры Авторизации с клиентскими сертификатами особо не работают.
ЗЫ: В рамках данной темы стоит обратить внимание, что при использовании строгой проверки клиентских сертификатов необходимо включить в рассмотрение такой параметр как срок действия СОС'а (по умолчанию в OpenSSL --- 30 дней).
По факту истечения срока действия СОС'а доступ к защищённому web-сайту блокируется.
:wq
--
Live free or die