Многие технологии защиты данных сегодня базируются на использовании цифровых сертификатов. Внедрение своего PKI позволяет гибко управлять сертификатами.
Появление систем шифрования с открытым ключом в свое время произвело буквально переворот в подходе к защите информации. Участникам теперь не нужно было беспокоиться о необходимости безопасной доставки секретного ключа своему корреспонденту, как это требуются в системах использующих закрытый ключ. Открытый ключ (сертификат) доступен всем, его знание ни как не влияет на возможность расшифровки сообщения им закрытого. В итоге подобные системы получили широкое распространение в электронном мире и сегодня используются повсеместно для шифрования электронной почты, трафика веб-сайтов, данных на компьютере пользователя, VPN, цифровой подписи, аутентификации и так далее. Но, решив одну проблему, получили другую. Если в случае с закрытыми ключами было все ясно, корреспондент сам передавал ключи, то теперь нужно быть уверенным, что открытый ключ принадлежит именно тому человеку или сервису который его сгенерировал. Разные реализации предлагают свой вариант выхода из ситуации. Так стандарт OpenPGP выбрал путь формирования сети доверия (Web of Trust), когда пользователи сами подписывают сертификаты другу друга. Такой децентрализованный вариант, требующий минимального управления, изначально больше подходит для личной переписки.
Почему? Причина проста. Доверие в Web of Trust понятие относительное и сугубо добровольное. Ведь подписав сертификат пользователя А, это не значит что я автоматически доверяю и пользователю Б, которому подписал сертификат А. Но именно простота организации и доступность инструментов привела к тому, что OpenPGP нашел свое применение и в корпоративной среде. В инфраструктуре открытых ключей PKI (Public Key Infrastructure) выбран другой подход. Здесь формируется древовидная система доверия, в которой ключевые данные обязательно подтверждаются удостоверяющим центром (УЦ, центр сертификации, Certification authority, CA). Если пользователь доверяет УЦ, он автоматически доверяет и всем ключам, которые он подписал. Этот подход более надежен, чем Web of Trust поэтому в корпоративной среде именно он завоевал больше сторонников. Справедливости хочется сказать, что в PGP это понимают и в последней редакции OpenPGP уже предусмотрено возможность создания иерархической системы доверия, как это принято в PKI.
В организациях уже среднего размера в которых используются различные приложения опирающиеся на PKI имеет смысл развернуть собственный УЦ. Это позволит выдавать сертификаты и управлять ими в течение всего срока действия. Сегодня предлагается несколько решения позволяющих создать УЦ — OpenCA, герой сегодняшней статьи EJBCA и другие.
Возможности EJBCA
EJBCA (Enterprise Java Beans Certificate Authority) – инструмент для создания инфраструктуры PKI класса enterprise. Распространяется по лицензии GNU GPL. Это гибкий инструмент, имеющий модульную структуру, который может использоваться как независимо, так и в комплексе с другими приложениями. Один экземпляр позволяет развернуть несколько уровней УЦ — Root CA и SubCA, с возможностью создания перекрестных сертификатов. Написан на Java и может быть установлен в принципе на любую платформу в которой имеются необходимые компоненты. Полный список возможностей можно найти на сайте проекта, он занимает несколько десятков строк. Вот только основные:
- поддержка сертификатов — X509 (в форматах PKCS12, JKS, PEM), CVC (Card Verifiable certificates), смарт-карт, Qualified Certificate Statement (RFC3739);
- поддержка SCEP (Simple Certificate Enrollment Protocol [3]) и OCSP (Online Certificate
Status Protocol, RFC2560); - поддержка алгоритмов — RSA (до 4096), DSA (до 1024), алгоритм ECDSA и implicitlyCA (RFC), также сигнатур MD5, SHA-1, SHA-256;
- хранение сертификатов в SQL базе данных LDAP, поддержка Active Direcory;
— простой и удобный веб-интерфейс управления переведенный на несколько языков (к сожалению русского пока нет); - управление с консоли, для запуска команд и скриптов;
- интерфейс API к некоторым HMS (Hardware Security Module), встроенная поддержка — nCipher, PrimeCardHSM, SafeNet и других HSM совместимы с PKCS#11;
- поддержка нескольких серверов приложений – Jboss (по умолчанию), Weblogic, Glassfish, OC4J, Websphere;
- совместимость с несколькими СУБД – Hypersoniq (по умолчанию), MySQL, PostgreSQL, Oracle, DB2, MS-SQL, Derby, Sybase, Informix.
И много других возможностей, обеспечивающих работу EJBCA в кластере, удобство мониторинга и так далее. Сертификаты могут создаваться для различных целей – VPN, веб-сервис, электронная почта и другие, для удобства EJBCA оперирует профилями. Профиль определяет набор атрибутов используемых сертификатами – период действия, возможность публикации, использование ключа и так далее. Поддерживается три набора профилей — Certificate Profile, End Entity Profile и Publisher.
Общедоступная часть веб-интерфейса позволяет производить поиск и загрузку сертификата, закрытая предназначена для управления EJBCA. Интерфейс позволяет делегировать часть прав другим пользователям.
Кроме стандартных средств защиты, которые обеспечивает сервер приложения, в состав JBoss входит брандмауэр, который разрешает только подключение к веб-интерфейсу (порты 8080, 8443), плюс SSL сертификат администратора.
Установка EJBCA в CentOS
EJBCA распространяется в виде исходных текстов, в репозитариях дистрибутивов нужного пакета нет. В документации проекта установка названа простой, возможно, так и есть, но только для пользователя, который уже имел дело с развертыванием Java приложений. Инструкция содержит лишь общие указания, поэтому нужный алгоритм приходится подбирать самостоятельно. Разработчики также предлагают LiveCD построенный на Xubuntu, который может быть использован в ознакомительных целях и для развертывания сервера. Обратите внимание, что LiveCD потребует наличие не менее 1.5 Гб ОЗУ, иначе EJBCA не запускается. Актуальной на момент написания статьи является EJBCA 3.10.0. Для сборки EJBCA необходимы:
- JDK — официально JDK 1.5.x, или 1.6.x, в LiveCD использован OpenJDK, проверка показала, что с ним EJBCA прекрасно работает;
- Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy для JDK;
- Сервер приложений – рекомендуется JBoss >=4.2.x, сегодня доступна уже версия 6.0, но разработчики утверждают, что с некоторыми версиями ветки 5 EJBCA несовместим, лучше выбрать 4.2.x;
- инструмент сборки – Apache Ant.
Кроме этого понадобится СУБД, например MySQL и опционально LDAP сервер. Процесс установки будем производить на CentOS 5.4, для других *nix систем процесс будет аналогичен и отличаться спецификой пакетной системы.
Устанавливаем нужные пакеты:
# yum install java mysql mysql-server mysql-connector-odbc
В CentOS, как и во многих современных дистрибутивах Linux в качестве Java среды устанавливается OpenJDK, если выбрана JDK от Sun то ее следует установить самостоятельно скачав установочный пакет. Проверяем работу Java:
# java --version
Устанавливаем сервер приложений:
# wget -c http://freefr.dl.sourceforge.net/project/jboss/JBoss/JBoss-4.2.3.GA/jboss-4.2.3.GA-jdk6.zip
# unzip jboss-4.2.3.GA-jdk6.zip –d /usr
И для удобства создадим символическую ссылку:
# ln -s /usr/jboss-4.2.3.GA /usr/jboss
В конфигурационном файле /usr/jboss-4.2.3.GA/bin/run.conf изменяем параметры запуска Java:
JAVA_OPTS="-server -Xms128m -Xmx512m"
Система сборки Apache Ant устанавливаемся аналогичным образом:
# wget –с http://apache.vc.ukrtel.net/ant/ivy/2.1.0/apache-ivy-2.1.0-bin.tar.gz
# tar zxvf apache-ivy-2.1.0-bin.tar.gz -C /usr
# ln -s /usr/apache-ivy-2.1.0 /usr/apache-ivy
Теперь нужно установить системные переменные в файле в /etc/profile или /etc/bashrc.
# если установка производилась при помощи пакета
# JAVA_HOME будет установлена автоматически
# export JAVA_HOME=/usr/lib/java
export JBOSS_HOME=/usr/jboss
export ANT_HOME=/usr/apache-ivy
export PATH=$PATH: $JBOSS_HOME/bin:$ANT_HOME/bin
ANT_OPTS=-Xmx512m
Скачиваем JCE и распаковываем в каталог с библиотеками JDK.
# unzip jce_policy-6.zip -d /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib
Запускаем MySQL и проверяем слушается ли порт 3306:
# /etc/init.d/mysqld start
# netstat -ant | grep 3306
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
Создаем учетную запись и базу данных:
# mysql -u root -p
mysql> CREATE DATABASE `ejbca`;
mysql> CREATE USER 'ejbca'@'localhost' IDENTIFIED BY 'ejbca';
mysql> GRANT ALL PRIVILEGES ON ejbca.* TO 'ejbca'@'%' WITH GRANT OPTION;
mysql> flush privileges;
mysql> exit
В примере в качестве логина, пароля и имени базы данных использованы данные по-умолчанию. В реальной системе их нужно изменить, подправив данные в конфигурационном файле EJBCA.
Устанавливаем EJBCA:
# wget -c http://downloads.sourceforge.net/project/ejbca/ejbca3/ejbca_3_10_1/ejbca_3_10_1.zip
# unzip ejbca_3_10_1.zip –d /usr
В каталоге /usr/ejbca_3_10_1/conf находится ряд шаблонов конфигурационных файлов, отдельный файл отвечает за свой участок настройки. Чтобы файл (и соответственно заложенная возможность) стали доступны для работы, следует переименовать убрав суффикс .sample.
Базовая функциональность описывается в четырех файлах — ejbca.properties (собственно настройки EJBCA), database.properties (подключение к СУБД), web.properties (веб-интерфейс), logging.log4j.config (журналирование). Для использования с установка по-умолчанию, файлы достаточно переименовать. Чтобы подключить MySQL, копируем шаблон и указываем настройки:
# cp conf/database.properties.sample conf/database.properties
# nano conf/database.properties
database.name=mysql
datasource.mapping=mySQL
database.url=jdbc:mysql://127.0.0.1:3306/ejbca
database.driver=com.mysql.jdbc.Driver
database.username=ejbca
database.password=ejbca
Создаем таблицы MySQL:
# mysql -u ejbca -p ejbca < doc/howto/create-tables-ejbca3-mysql.sql
Теперь собираем EJBCA.
# ant bootstrap
# ant install
На этом этапе будут сгенерированы сертификаты сервера и администратора, которые сохраняются в подкаталоге p12. В файле p12/superadmin.p12 будет сохранен сертификат администратора, его затем необходимо импортировать в браузер (в Firefox Правка-Настройки-Дополнительно-Шифрование-Просмотр сертификатов-Ваши сертификаты-Импортировать), пароль по умолчанию ejbca.
# ant deploy
Запускаем JBoss:
# run.sh -b 0.0.0.0
Проверяем слушаются ли 8080 и 8443 порт, если да, заходим веб-браузером по адресу
https://localhost:8443/ejbca/ (администрирование) или http://localhost:8080/Набор профилей (доступ к сертификатам).
Далее создаем сертификаты, здесь уже ничего сложного нет.
***
В каталоге архива doc/howto находится ряд скриптов и пошаговых инструкций по использованию EJBCA в различных ситуациях. Дальнейшая настройка обычно не вызывает проблем.