IBM WebSphere Developer Technical Journal: Улучшения в системе управления сертификатами, ключами и SSL для повышения безопасности работы в WebSphere Application Server V6.1

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Питер Бирк, старший разработчик программного обеспечения, IBM
Кейс Ботзам, старший технический сотрудник, IBM

30.05.2007

В IBM® WebSphere® Application Server V6.1 была существенно изменена инфраструктура управления ключами, сертификатами и SSL. В данной статье рассказывается, как эти изменения повлияют на повышение безопасности, гибкость и упрощение управления, а также описывается поддержка совместимой исполняющей системы SSL, которая тесно интегрирована в новую конфигурацию.

Из IBM WebSphere Developer Technical Journal.

Введение

В предыдущих версиях IBM WebSphere Application Server система управления SSL основывалась на наборе SSL-конфигураций, на которые по имени псевдонима ссылаются оконечные точки по всей секции (cell). Каждый псевдоним начинался с имени узла, отражая место, где был создан. Исполняющая система SSL читает SSL-конфигурацию, на которую ссылается данная оконечная точка, и создает SSL-сокеты, основываясь на этой информации. С каждой инсталляцией поставлялся набор самостоятельно подписанных (self-signed) сертификатов, расположенных в хранилищах ключей DummyServerKeyFile.jks и DummyClientKeyFile.jks. При всей своей простоте этот метод не является безопасным и не должен применяться в реальной работе. Управление сертификатами требует использования внешней инструментальной программы управления ключами, называемой IKeyMan. Поскольку в каждом файле server.xml системы есть ссылки на SSL-конфигурации, реорганизовать SSL-конфигурации при изменениях топологии может быть весьма затруднительно. Приложения не имеют возможности обращаться к этим SSL-конфигурациям.

В WebSphere Application Server V6.1 система управления SSL добавляет совершенно новый уровень простоты, защищенности и гибкости.

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

• К исполняющей системе SSL добавлена дополнительная функция управления доверенными сертификатами и JSSE-ключами, расширяющая выбор специализированных ключей и доверенные решения. Управление SSL-конфигурациями плотно интегрировано в исполняющую систему таким образом, что системные свойства JSSE больше не требуются для фабрик сокетов по умолчанию. Хотя на SSL-конфигурации все еще можно ссылаться по имени псевдонима, они могут также управляться по области действия при помощи механизма наследования для расширения или сужения ассоциации SSL-конфигурации, используемой конкретной оконечной точкой, кластером, сервером, узлом, группой узлов или всей секцией. В результате доверенные зоны SSL могут быть более легко установлены в новых централизованных панелях управления.

Многое еще можно рассказать, так что продолжайте чтение.

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

1. SSL-конфигурация . Предназначается для всех пользователей WebSphere; здесь объясняются функциональные возможности по настройке и использованию SSL в WebSphere Application Server. Знание этой информации исключительно важно для всех администраторов WebSphere.

2. Управление сертификатами . Здесь описываются некоторые из более продвинутых функциональных возможностей WebSphere Application Server и рассматриваются более сложные вопросы, связанные с управлением сертификатами. Большинству администраторов не нужно решать эти вопросы, но они включены по причине их важности.

3. Соглашения по программному использованию SSL . Кратко освещаются некоторые изменения и функциональные возможности, связанные с использованием SSL в коде приложения.

4. Генерирование сертификатов и ключей при создании первоначального профиля . Описывается первоначальное создание сертификатов для профилей.

5. Интегрирование узла и миграция . Обсуждается добавление узлов к существующим секциям и проблемы миграции.

6. Управление жизненным циклом криптографических ключей . Обсуждаются функциональные возможности WebSphere Application Server по управлению изменениями криптографических ключей на протяжении длительного времени.

В данной статье предполагается наличие базовых знаний работы SSL. Общая информация по этим новым функциональным возможностям приведена в статьях на WebSphere Application Server V6.1 Information Center. Кроме того, некоторая используемая в данной статье терминология, определена в разделе "Терминология".

В начало

SSL-конфигурация

Общий обзор новых возможностей консоли администратора по управлению SSL приведен на рисунке 1, на котором изображена главная панель SSL, отображаемая при выборе ссылки SSL certificate and key management в консоли. Важно отметить, что ссылки на конфигурации ниже Related Items будут отображать только те объекты конфигурации, областью действия которых является секция (cell - для WebSphere Application Server Network Deployment) или узел (node - для WebSphere Application Server base). Это означает, что они видимы для каждого процесса в секции или узле соответственно. Вот как это работает: при просмотре чего-либо в секции можно увидеть все, что находится в этой области действия, и использовать данный объект конфигурации; однако, виды (view) с областью действия "секция" не могут увидеть объекты, находящиеся ниже этой области (сделано намеренно для изоляции во время исполнения). Следовательно, данные ссылки предоставляют подмножество конфигураций. Для просмотра объектов конфигурации, находящихся ниже данной области действия, необходимо выбрать ссылку Manage end point security configurations, которая отображает топологию с возможностью просмотра области действия объектов конфигурации. Более подробно это будет рассмотрено позже.

Что такое SSL-конфигурация?

SSL-конфигурация используется для инкапсуляции всего того, что необходимо системе JSSE (SSL-реализации, используемой в WebSphere Application Server) для защищенного подключения к (или из) другой оконечной точке, работающей с SSL. Одна и та же SSL-конфигурация может использоваться как для исходящих (клиентских), так и для входящих (серверных) соединений. На рисунке 2 показана панель SSL-конфигурации. Одной из улучшенных возможностей, отсутствовавших в предыдущих версиях WebSphere Application Server, является способность подключать пользовательские модули управления доверенными сертификатами и ключами. Более подробно об этом мы поговорим позже.

Перед подробным рассмотрением SSL-конфигурации мы кратко обобщим некоторые из наиболее важных концепций и понятий SSL, которые будут использоваться в данной статье:

• Хранилище ключей содержит персональные сертификаты, которые можно использовать в качестве идентификатора подлинности оконечной точки SSL, обращающейся к хранилищу ключей. Если присутствует более одного сертификата, псевдоним сертификата в SSL-конфигурации указывает на один из персональных сертификатов. При подключении по SSL (либо на стороне сервера, либо на стороне клиента) может происходить обмен сертификатами. Будет использоваться персональный сертификат, хранящийся в хранилище ключей и указываемый в SSL-конфигурации.

• Персональный сертификат представляет собой идентификатор подлинности оконечной точки и содержит открытый и закрытый ключи для подписи/шифрования данных.

• Хранилище доверенных сертификатов (trust store) содержит сертификаты подписчиков (signer certificate), которым доверяет данная оконечная точка при выполнении подключений (из исходящей оконечной точки) или принятии подключений (для входящей оконечной точки).

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

Идеальная установка SSL для секции WebSphere Application Server Network Deployment (здесь и далее - Network Deployment) имеет SSL-конфигурации с областью действия "секция" (то есть, видимые для всех процессов в секции), называемые NodeDefaultSSLSettings, для каждого узла секции. SSL-конфигурации содержат множество ресурсов, которые мы вскоре обсудим, но наиболее важными компонентами являются хранилище ключей и хранилище доверенных сертификатов, которые содержат персональные сертификаты и сертификаты подписи. Для обеспечения возможности взаимодействия всех узлов друг с другом и с менеджером развертывания имеется хранилище доверенных сертификатов уровня секции по умолчанию, которое указывает на все SSL-конфигурации уровня узлов по умолчанию и включает подписчиков для всех персональных сертификатов уровня узла, а также менеджер развертывания. В общем, каждый узел имеет свой собственный персональный сертификат, хранящийся в хранилище ключей уровня узла. Менеджер развертывания также имеет свой собственный персональный сертификат, который хранится в его собственном хранилище ключей. Позднее мы рассмотрим, как новые узлы интегрируются в секцию.

На рисунке 3 показана конфигурация хранилища ключей для области действия "узел":

• Показанный здесь набор хранилищ ключей может использоваться (как хранилища ключей или доверенных сертификатов) оконечными точками в этом узле. Другие узлы могут иметь другие наборы хранилищ ключей.
• Вид topology позволяет просматривать конфигурации для различных областей действия.
• При создании профиля менеджера развертывания присутствуют CellDefaultKeyStore и CellDefaultTrustStore.
• Конфигурации хранилищ ключей NodeDefaultKeyStore и NodeDefaultTrustStore добавляются при интегрировании узла.

На рисунке 4 показан самостоятельно подписанный сертификат по умолчанию, который создается для каждого уникального профиля. Как упоминалось ранее, подписчик для данного сертификата может быть обнаружен в CellDefaultTrustStore после интегрирования в секцию. В ситуациях, когда подписчик отсутствует, вы, возможно, должны добавить подписчика в CellDefaultTrustStore, поскольку большинство SSL-конфигураций по умолчанию использует это хранилище. Обычно хранилище доверенных сертификатов, нуждающееся в недостающем подписчике, указывается в сообщении об ошибке, появляющемся при неудачном установлении соединения по этой причине.

Настройки Quality of Protection

Кроме настройки персонального сертификата и сертификата подписчика есть также другие части SSL-конфигурации, которые нужно рассмотреть.

• SSL handshake protocol (SSL-протокол установления соединения) определяет синтаксис процедуры установления этого соединения. Как правило, чем выше версия протокола, тем выше защита при установлении соединения. TLSv1 является самым защищенным протоколом установления соединения и, следовательно, должен использоваться при любой возможности. Однако TLSv1 не совместим с протоколом SSLv3, который, к сожалению, является наиболее широко распространенным. Для решения этой типичной проблемы провайдер IBMJSSE2 содержит еще один протокол под названием SSL_TLS. Данный протокол выполняет процедуру установления соединения сначала с использованием TLSv1, а если она не срабатывает, используется SSLv3 и т.д. Это - протокол установления SSL-соединения по умолчанию для SSL-конфигураций WebSphere Application Server V6.1, т.к. он способен хорошо взаимодействовать с большинством протоколов на другом конце соединения. По соображениям безопасности WebSphere Application Server не будет использовать SSLv2 по умолчанию, пока это не будет явно указано в настройках.

• cipher suite group - это специфичный для WebSphere атрибут конфигурации, который группирует наборы шифров, основываясь на их силе (strong, medium или weak). По умолчанию используется группа "Strong", для которой выбираются наборы 128-битных шифров. Для группы "Medium" выбираются наборы 40-битных шифров, а для "Weak" обычно выполняется только цифровая подпись (без шифрования данных). На рисунке 5 показаны возможности по выбору качества защиты. Важно понимать, что эти группы шифров являются соответствующими подмножествами доступных наборов шифров. Следовательно, при установке на одном конце соединения типа "Strong", а на другом "Medium" набор шифров не обнаружится и установление соединения закончится неудачно. Если вы хотите использовать конкретную комбинацию шифров, используйте настройки Custom и выберите желаемые шифры. В противном случае для всех оконечных точек рекомендуется использовать тип "Strong".

• Client authentication определяет, требуется ли передавать сертификат на сервер оконечной точке SSL-клиента. Для того чтобы это работало, сервер должен иметь в своем хранилище доверенных сертификатов сертификат подписи, который может проверить подлинность сертификата клиента. В некоторых сценариях более защищенной является аутентификация соединения с использованием сертификатов на обоих концах; однако это затрудняет управление, поэтому аутентификация клиента по умолчанию отключена. При использовании сертификатов, сгенерированных центром сертификации (certificate authority - CA) или подписанных общим сертификатом подписи, настоятельно рекомендуется разрешить SSL-аутентификацию клиента, поскольку доверенные отношения уже установлены на основе корневого сертификата CA. Однако, при использовании самостоятельно подписанных сертификатов, добавление в хранилище доверенных сертификатов большого количества подписчиков может вызвать проблемы масштабируемости, замедляющие процедуру установления соединения при проверке подлинности сертификатов.

Возможности централизованного управления выбором SSL-конфигурации

Централизованное управление SSL-конфигурациями - это новая функциональность, предоставляющая возможность управлять использованием SSL-конфигураций во время исполнения на основе топологии. Для этого используется панель Topology, отображающая все управляемые области действия всей секции. Эти определения управляют действующей SSL-конфигурацией, используемой для любой входящей или исходящей оконечной точки. Действующая SSL-конфигурация основывается на минимальной области действия, определенной для конкретной оконечной точки, по всему пути вверх по иерархии на основе правил приоритета или наследования. Централизованное управление SSL-конфигурациями желательно по следующим причинам:

• Легче учитывать соответствующие требования по доверию для всех оконечных точек среды.
• Легче гарантировать указание одинакового протокола установления соединения и требований к шифрам.
• Дает возможность нести ответственность за все изменения в SSL более опытному администратору системы безопасности.
• Можно поддерживать меньшее число SSL-конфигураций с большей гибкостью, благодаря правилам наследования, определенным с использованием возможностей централизованного управления.
• Намного проще выполнять изменения в SSL на основе изменений в топологии.
• Централизованное управление можно использовать для быстрой настройки доверенных зон (trust zones).

На рисунке 6 показано, как SSL-конфигурация по умолчанию отображается в панели централизованного управления топологией. Здесь можно увидеть все указанные переопределения правил наследования. Чтобы просмотреть действующую SSL-конфигурацию, основанную на этих переопределениях, можно нажать на ссылку на любой процесс или оконечную точку и увидеть действующую SSL-конфигурацию для данного объекта. Однако, для того чтобы централизовано управляемые конфигурации были действующими, в конфигурации оконечной точки не должны присутствовать какие-либо прямые ссылки на псевдоним. Например, если SSLChannel имеет прямую ссылку на SSL-конфигурацию, она переопределит централизовано управляемые назначения. Можно сделать оконечную точку централизовано управляемой, указав это в ее конфигурации (рисунок 9).

На рисунке 7 показано, как можно определить текущую наследованную SSL-конфигурацию для выбранной области действия и как переопределить наследуемую SSL-конфигурацию, указывая другую конфигурацию непосредственно в просматриваемой области действия. Опять же, обратите внимание на ссылку Related Items справа; при переходе по этим ссылкам и создании любых новых объектов конфигурации они будут создаваться в текущей области действия. Это означает, что данные элементы конфигурации видимы и выбираемы только в текущей области действия и ниже. Если вы вернетесь к ссылке на область действия "секция", то не увидите эти новые элементы конфигурации, поскольку они определены на более "узкой" области действия. Для просмотра всех элементов конфигурации, применимых в конкретной иерархии наследования, используется ссылка Related Items в панели оконечной точки (рисунок 7).

Возможности динамического выбора SSL-конфигурации для исходящих соединений

Существуют ситуации, когда статической SSL-конфигурации для данной оконечной точки оказывается недостаточно для того, чтобы соответствовать требованиям конкретного соединения. Например, может существовать статическая SSL-конфигурация IIOP для всех внутренних взаимодействий в WebSphere Application Server, но в данной среде может также иметься приложение, которому необходимо подключиться к стороннему IIOP-серверу. Хотя в WebSphere существует возможность изменить статическую конфигурацию, используемую для взаимодействий сервер-сервер, предпочтительнее было бы удовлетворить требования стороннего сервера по использованию отдельной SSL-конфигурации без изменения поведения оригинальной статической SSL-конфигурации.

На рисунке 8 показан процесс создания динамической SSL-конфигурации исходящей оконечной точки. Этот объект конфигурации позволяет указать один или более критериев выбора для обращения к конкретной SSL-конфигурации и псевдониму сертификата. Когда выбор SSL-конфигурации выполняется для конкретного исходящего соединения с использованием JSSEHelper API, передаваемая в API информация о соединении используется для проверки критериев выбора и определения соответствия им. Если соответствие найдено, используется динамическая SSL-конфигурация, а поиск вариантов прекращается. Удачные и неудачные варианты динамического выбора кэшируются для повышения производительности.

Дополнительная информация о возможностях динамического выбора при исходящих соединениях предоставлена в разделе "Динамический выбор SSL-конфигураций при исходящих соединениях" в Information Center.

SSL-конфигурация прямого выбора

Если вы решили управлять SSL-конфигурациями напрямую, на рисунке 9 показано, как это может быть сделано. Пример демонстрирует выбор LDAP-реестра, но аналогичная концепция применима для всех оконечных точек SSL. Эта функция работает точно так же, как и в предыдущих версиях, с учетом правил выбора SSL-конфигурации, которые мы вскоре рассмотрим.

Возможности программного выбора SSL-конфигурации

Хотя данная тема не является предметом рассмотрения этой статьи, выбором SSL-конфигурации можно управлять программно. Во-первых, прикладные программы могут явно использовать JSSEHelper API, предоставляемый IBM для доступа к SSL-конфигурациям, а также получать SSLSocketFactories, используя эти конфигурации. SSL-конфигурации могут также быть указаны в потоке (thread) при помощи JSSEHelper API до начала исходящего соединения. Это полезно при использовании существующего кода, который работает с JSSE-провайдером по умолчанию. Мы обсудим это более подробно позднее.

Правила приоритета SSL-конфигураций

К этому моменту уже должно быть понятно, что существует несколько способов управления тем, какая SSL-конфигурация используется. Конечно, есть вероятность того, что для конкретного случая использования SSL может подойди более одной конфигурации. Для разрешения этой неопределенности исполняющая система WebSphere Application Server использует правила приоритета при выборе SSL-конфигурации. Они пригодны при использовании SSL в WebSphere Application Server, SSL в коде приложения с JSSE-провайдером по умолчанию и при прямом использовании JSSEHelper API в коде приложения. Правила приоритета таковы (по старшинству в порядке убывания):

1. thread-based selection (выбор на основе потока). Свойства указаны в потоке программным способом приложением, которое напрямую использует IBM JSSEHelper API. Последующее неявное использование JSSE (то есть, открытие HTTPS-соединения с провайдером URL) использует настройки потока, установленные JSSEHelper API.

2. dynamic outbound selection (выбор динамического исходящего соединения). Ищется конфигурация динамического исходящего соединения, соответствующая информации данного исходящего соединения. Это относится как к прикладному коду, так и к WebSphere Application Server.

3. direct selection (прямой выбор). SSL-конфигурация WebSphere Application Server непосредственно указывается для данной оконечной точки. Это может быть сделано административным способом для WebSphere Application Server SSL. Прикладные программы могут также обратиться к SSL-конфигурации напрямую при помощи JSSEHelper API.

4. scoped selection (выбор по области действия). Ни одно из вышеперечисленных правил не применилось, поэтому используется SSL-конфигурация на основе топологии.

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

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

В начало

Управление сертификатами

Конфигурация сертификата по умолчанию

В предыдущих версиях WebSphere Application Server хранил сертификаты по умолчанию в хранилищах ключей под названием DummyServerTrustFile.jks и DummyServerKeyFile.jks, расположенных в каталоге /etc профиля, которые содержали фиктивный сертификат (с открытым и закрытым ключом). Эти файлы все еще поставляются с WebSphere Application Server V6.1 для обратной совместимости с приложениями, которые обращаются к ним; однако они больше не используются.

При создании профиля для него генерируется уникальный самостоятельно подписанный сертификат, который размещается в хранилище ключей key.p12. Сертификат подписчика извлекается из этого персонального сертификата и добавляется в хранилище trust.p12. Эти хранилища ключей создаются в каталоге, указанном в репозитории конфигурации (либо в каталогах cell, либо в node), что позволяет управлять ими из консоли администратора или wsadmin, и синхронизируются с соответствующими узлами. Типичная конфигурация по умолчанию WebSphere Application Server будет содержать следующие хранилища ключей и доверенных сертификатов:

• Хранилища ключей и доверенных сертификатов области действия "секция":
  • C:\WebSphere\AppServer\profiles\Dmgr01\config\cells\Machine40Cell01\key.p12
  • C:\WebSphere\AppServer\profiles\Dmgr01\config\cells\Machine40Cell01\trust.p12
• Хранилища ключей и доверенных сертификатов области действия "узел":
  • C:\WebSphere\AppServer\profiles\Dmgr01\config\cells\Machine40Cell01\nodes\Machine40Node01\key.p12
  • C:\WebSphere\AppServer\profiles\Dmgr01\config\cells\Machine40Cell01\nodes\Machine40Node01\trust.p12

Это хранилища ключей по умолчанию, созданные во время создания профиля для секции. Вы можете указать для хранилищ ключей любое месторасположение и любой тип, который поддерживается в панелях настройки хранилищ ключей. Типы поддерживаемых хранилищ ключей зависят от используемой платформы.

Поскольку хранилища ключей теперь отлично управляются при помощи консоли администратора WebSphere Application Server, существует много возможностей, которыми вы можете воспользоваться. Мы рассмотрим наиболее интересные из них.

Базовое управление сертификатами

Управлять сертификатами и хранилищами ключей можно из консоли администратора. Программы управления ключами в WebSphere Application Server V6.1 базируются на функциональности IKeyMan из предыдущих версий. Используется та же терминология, и отображаются аналогичные виды. К фундаментальным возможностям по управлению сертификатами относятся создание самостоятельно подписанных сертификатов, запросы на подпись сертификатов, управление сертификатами подписчиков и т.д. Информация по возможностям системы управления сертификатами приведена в разделе "Управление сертификатами" в Information Center.

Получение сертификата подписчика из удаленного порта

Обычно для настройки исполняющей системы WebSphere Application Server на использование SSL для работы с другим сервером необходимо вручную получить сертификат подписи этого сервера и импортировать его в соответствующее хранилище доверенных сертификатов. Однако теперь в WebSphere Application Server имеется функция, облегчающая это действие. Администратор WebSphere Application Server может получить сертификат подписи непосредственно с сервера, используя параметр retrieve from port (SSL-соединение установлено для получения этого сертификата). Администратор получает запрос на проверку подлинности этого сертификата с использованием SHA-дайджеста, а затем может записать его в локальное хранилище доверенных сертификатов. Это очень упрощает процесс обмена подписями для установления SSL-соединения с внешними серверами, например, с LDAP. На рисунке 10 показана настройка информации об удаленном хосте и SSL-порте, к которым будет подключаться WebSphere Application Server для получения сертификата подписчика. Как видно на рисунке, администратор должен ввести имя хоста и номер порта, а затем нажать кнопку Retrieve signer information.

Если сертификат подписчика был успешно получен, этот факт подтверждается отображением информация о сертификате, включая SHA-дайджест сертификата, использующийся для проверки отсутствия изменений во время передачи. На рисунке 11 показана панель, позволяющая администратору принять полученный сертификат подписчика для добавления его в хранилище доверенных сертификатов, в данном случае NodeDefaultTrustStore.

Управление сертификатами подключаемых модулей Web-сервера

Не путайте управление файлом хранилища ключей, расположенным в конфигурационном репозитории WebSphere Application Server, с управлением файлом хранилища ключей подключаемого модуля реального Web-сервера. Здесь мы рассматриваем управление WebSphere-копией файла хранилища ключей подключаемых модулей. Вы все еще несете ответственность за копирование обновленного файла хранилища ключей после изменений на Web-сервере. Это действие обычно выполняется вручную, хотя можно также использовать функцию управления Web-сервером в WebSphere Application Server, но по соображениям безопасности она используется редко.

WebSphere Application Server предоставляет для управления также файл ключей подключаемого модуля Web-сервера. При создании определения Web-сервера создается конфигурация CMSKeyStore, которая ссылается на хранилище ключей CMS (известное также под названием KDB-файл) и скрытый файл CMS-паролей (известный также под названием STH-файл), расположенные в каталоге config/cells/${CELL_NAME}/nodes/${NODE_NAME}/servers/${WEB_SERVER_NAME}. По умолчанию, эти файлы называются соответственно plugin-key.kdb и plugin-key.sth. При создании хранилище ключей содержит персональный сертификат узла и всех подписчиков, существующих в данный момент времени в общем хранилище доверенных сертификатов секции (файл trust.p12 в каталоге cell). Это позволяет подключаемому модулю Web-сервера без настройки инициировать SSL-соединения со всеми внутренними HTTPS-портами, открытыми на сервере приложений в текущей секции. При интегрировании нового узла после создания определения Web-сервера подписчик для нового узла должен быть добавлен в существующее хранилище ключей подключаемого модуля. В WebSphere Application Server V6.1.0.4 этот файл обновляется автоматически как часть процесса интегрирования; раньше это выполнялось вручную, поэтому мы настоятельно рекомендуем установить данную версию.

Если по каким-либо причинам вы хотите управлять хранилищем ключей подключаемого модуля вручную, это можно сделать при помощи аналогичных возможностей по управлению сертификатами, имеющихся для любого другого хранилища ключей. Панели настройки подключаемого модуля Web-сервера ссылаются на панели управления сертификатами, находящимися в системе управления ключами и сертификатами для SSL. На рисунке 12 показана панель Plug-in properties Web-сервера, которая позволяет изменить настройки хранилища ключей подключаемого модуля.

Замена сертификатов и подписчиков

В любой среде, использующей сертификаты, необходимо время от времени обновлять персональные сертификаты и соответствующих подписчиков (для самостоятельно подписанных сертификатов). Это, конечно, можно сделать вручную, просмотрев каждое хранилище доверенных сертификатов в секции для обнаружения соответствующего подписчика. Вместо этого WebSphere Application Server предоставляет функцию для упрощения данной задачи.

На рисунке 13 показана панель Replace, отображаемая после нажатия кнопки Replace, с одним самостоятельно подписанным сертификатом, выбранным в виде Personal certificates collection. В этой панели вы можете указать другой сертификат из того же хранилища ключей, который должен заменить выбранный персональный сертификат. Старый сертификат будет удален и все существующие SSL-конфигурации, обращающиеся к этому сертификату (через псевдоним), будут обновлены для использования псевдонима нового сертификата. Также будут обновлены все хранилища доверенных сертификатов, которые содержали старого подписчика. WebSphere Application Server ищет старого подписчика по совпадению SHA-сигнатуры и просматривает все хранилища доверенных сертификатов в секции. Наконец, процесс может при необходимости удалить информацию о старом подписчике и старый персональный сертификат. Как правило, это не плохая мысль - оставить старого подписчика в хранилище доверенных сертификатов до тех пор, пока вы не будете уверены, что удалены все соответствующие персональные сертификаты.

При замене сертификатов могут возникнуть временные SSL-проблемы из-за несовместимости ключей. Для минимизации проблем, если разрешены динамические обновления SSL, SSL-аутентификация на сервере временно отключается на 90 секунд, для того чтобы дать время на завершение синхронизации хранилищ ключей и на загрузку обновленной информации каждым выполняющимся процессом. Следовательно, желательно выполнять обновления SSL-конфигураций в периоды небольшой нагрузки в сети. Если узел не обновился за время, необходимое для завершения синхронизации, или синхронизация не запустилась после изменения, остановите узел и выполните вручную syncNode для синхронизации изменений для узла. Если динамические SSL-обновления не разрешены, серверы зафиксируют изменения после перезагрузки.

Монитор истечения срока действия сертификатов и динамические обновления исполняющей системы

Описываемое здесь поведение будет реализовано в WebSphere Application Server в обновлении APAR PK34093 (вероятно, в версии V6.1.0.6). Настоятельно рекомендуем выполнить обновление до этого уровня, когда оно будет доступно.

Не является новостью, что срок действия сертификатов рано или поздно кончается. Когда это происходит, SSL-взаимодействие, использующее такой сертификат, будет невозможным, что почти всегда приводит к простою системы. WebSphere Application Server выполняет большую работу для предотвращения таких простоев, а в тех случаях, когда подобной ситуации избежать нельзя, он пытается, по крайней мере, предупредить об этом заранее. Задание (task) мониторинга истечения срока действия сертификатов запускается по настраиваемому графику - по умолчанию каждые 14 дней. В конфигурации монитора имеется поле Next start date (следующая дата запуска), которое меняется на новую дату при каждом запуске монитора. Он будет выполняться в процессе менеджера развертывания в среде Network Deployment или (в автономном режиме) в основном процессе WebSphere Application Server.

В процессе выполнения монитор истечения срока действия сертификатов будет просматривать все объекты KeyStore, настроенные в секции, выполняя поиск всех персональных сертификатов, срок действия которых истекает не позднее, чем через определенный промежуток времени (90 суток по умолчанию; этот параметр можно настроить на любое значение). Если такой сертификат найден, выдается предупреждение о предстоящем истечении срока действия. Эти уведомления всегда передаются в важный поток событий всем зарегистрированным прослушивателям (listeners). По умолчанию это консоль администратора и SystemOut.log. Уведомления также могут быть переданы по электронной почте через SMTP-сервер.

Помимо уведомлений WebSphere Application Server попытается заменить самостоятельно подписанные сертификаты до завершения срока их действия. По умолчанию, монитор будет выполнять задание замены сертификатов (упомянутое в предыдущем разделе) для всех самостоятельно подписанных сертификатов за 15 дней до истечения срока их действия (можно настроить другое значение). Задание создает новый сертификат, используя информацию из старого сертификата, и обновляет все хранилища доверенных сертификатов в секции, содержащие старого подписчика, новым сертификатом подписчика. По умолчанию старый сертификат удаляется.

Монитор истечения срока действия сертификатов помечает каждую SSL-конфигурацию как "измененную" при выполнении изменений в хранилище ключей или хранилище доверенных сертификатов, на которые имеется ссылка в данной конфигурации. После завершения задания обновления срока действия изменения конфигурации сохраняются, вызывая дополнительную активность в исполняющей системе. Сначала временно запрещается SSL-аутентификация сервера (на 90 секунд), давая возможность зафиксировать эти изменения без необходимости перезапуска сервера. Если вы не хотите этого, запретите параметр Dynamically update the run time when SSL configuration changes occur (динамически обновлять исполняющую систему при изменении SSL-конфигурации), находящийся в нижней части панели управления ключами и SSL-сертификатами в консоли администратора.

К сожалению, автоматическая замена сертификатов - это не панацея. Сервер WebSphere Application Server не может обновить сертификаты в хранилищах ключей, которыми он не управляет. В частности, это означает, что подключаемый модуль Web-сервера, использующий предыдущий сертификат с истекающим сроком действия, прекратит работу после замены соответствующего персонального сертификата. Это также означает, что если WebSphere Application Server использовал персональный сертификат для аутентификации в какой-нибудь другой системе, замена сертификата вызовет простой системы. Помните о том, что такой простой возник бы все равно (только на 15 суток позже) и после передачи сервером WebSphere Application Server нескольких уведомлений об этом. WebSphere Application Server просто старается сделать как лучше.

Для уменьшения риска возникновения простоя для создаваемых WebSphere сертификатов по умолчанию указывается срок 15 лет. Конечно же, длительный цикл жизни сертификата несет с собой некоторые риски, поэтому тем пользователям, которых это беспокоит, рекомендуем вручную заменять созданные по умолчанию сертификаты чаще.

Очевидно, что предоставление возможности серверу WebSphere Application Server автоматически менять просроченные сертификаты в реальной жизни связано с рисками, поскольку потенциально может вызвать кратковременные или долговременные простои. Вместо этого вы должны менять сертификаты вручную после получения уведомления об истечении срока их действия. Автоматическая замена в основном применяется для упрощения управления менее сложными системами и для систем разработки, в которых краткие простои приемлемы. Для большинства производственных систем мы рекомендуем вам выполнять эту работу вместо монитора и запретить автоматическую замену самостоятельно подписанных сертификатов. На рисунке 14 показана панель настройки монитора истечения срока действия сертификатов.

Дополнительная информация приведена в разделе "Монитор истечения срока действия сертификатов" в Information Center.

Устранение проблем, связанных с SSL

Устранить проблемы SSL-соединения может быть не так уж и просто. К счастью, были затрачены значительные усилия для повышения в WebSphere Application Server V6.1 качества сообщений об ошибках, облегчающих диагностирование (и, в конечном итоге, решение) связанных с SSL проблем. В листинге 1 приведен пример одной из самых частых ошибок, возникающих при попытке установить SSL-соединение клиента с сервером. В данном случае сервер послал сертификат, не распознанный клиентом, т.е. хранилище доверенных сертификатов на клиенте не имеет информации о соответствующем подписчике. Сообщение об ошибке содержит подробную информацию об этой ошибке, которая должна облегчить ее устранение. Обратите внимание на то, что указаны хост:порт, отсутствующий подписчик, SSL-конфигурация и даже используемое хранилище доверенных сертификатов. Сообщение точно указывает администратору, что необходимо сделать: в данном случае необходимо получить информацию об отсутствующем подписчике и добавить ее в указанное хранилище trust.p12.

                
CWPKI0022E: SSL HANDSHAKE FAILURE:  A signer with SubjectDN
"CN=192.168.1.204, O=IBM, C=US" was sent from target host:port
"192.168.1.12:9403".  The signer may need to be added to local trust store
"c:/WebSphere/AppServer/profiles/Dmgr01/etc/trust.p12" located in SSL 
configuration alias "DefaultSSLSettings" loaded from SSL configuration file 
file:c:\WASX_a0633.07\AppServer\profiles\Dmgr01/properties/ssl.client.props".  The
extended error message from the SSL handshake exception is: "No trusted certificate
found".

Мы рассмотрели обычные вопросы управления хранилищами ключей/сертификатов, с которыми сталкивается большинство администраторов WebSphere Application Server. Сейчас мы обратим наше внимание на продвинутые вопросы, связанные с управлением сертификатами. Поскольку это более сложные темы, мы только кратко затронем их. Ссылки на дополнительную информацию приведены в разделе "Ресурсы".

Сложные проблемы управления ключами и сертификатами

Усовершенствования менеджера доверенных сертификатов

При использовании сертификатов за выполнение проверки их подлинности для определения возможности их подтверждения и соответствия всем выдвигаемым требованиям несет ответственность менеджер доверенных сертификатов (trust manager). WebSphere Application Server предоставляет два менеджера доверенных сертификатов:

• Менеджер доверенных сертификатов по умолчанию, IbmX509, выполняет базовую проверку подлинности сертификатов, включая проверку сигнатуры сертификата (того, что она не изменилась) и проверку на истечение срока действия. Этот менеджер доверенных сертификатов не выполняет по умолчанию проверку имени хоста, хотя можно разрешить эту функцию только для URL-соединений путем установки свойства com.ibm.ssl.performURLHostNameVerification=true в панели security custom properties. Если это сделать, менеджер доверенных сертификатов будет проверять для URL-соединений, что указанное имя хоста соответствует SubjectDN в сертификате, возвращенном сервером (как это делают Web-браузеры).

• Другим доступным JSSE-менеджером доверенных сертификатов является IbmPKIX. Кроме выполнения по умолчанию перечисленных выше функций (за исключением того, что проверку имени хоста все равно нужно разрешать явно для HTTPS URL-соединений), этот менеджер выполняет расширенную проверку списка отозванных сертификатов (certificate revocation list - CRL), используя либо расширения точек распространения CRL (distribution point - DP), поддерживаемые большинством CA, либо системные свойства интерактивного протокола состояния сертификатов (online certificate status protocol - OCSP). Если менеджер IbmPKIX выбран в качестве используемого по умолчанию, работа CRL DP разрешается автоматически. Будет выполняться проверка CRL для всех сертификатов, содержащих точки распространения CRL. Если проверка CRL должна проводиться более часто, можно установить системные свойства в конфигурации процесса для разрешения OCSP. Описание свойств, необходимых для разрешения работы OCSP, приведено в "Руководстве программиста по Java Certification Path API". (Хотя эта информация касается IBM JDK, она применима для любых установок сервера WebSphere Application Server, поскольку IBM добавляет функциональность криптографической защиты, включая PKIX, в любой JDK, поставляемый с WebSphere Application Server.)

Если для вашей среды нужна более специализированная проверка сертификатов, можно даже написать свой собственный менеджер доверенных сертификатов. Вы можете подключить любое количество пользовательских менеджеров для выполнения после менеджеров доверенных сертификатов, поставляемых IBM. При реализации пользовательских менеджеров доверенных сертификатов вы должны продумать два интерфейса:

• Традиционным интерфейсом JSSE-менеджера доверенных сертификатов является javax.net.ssl.X509TrustManager, который обеспечивает базовые методы, вызываемые исполняющей системой JSSE во время установления SSL-соединения. Дополнительная информация приведена в разделе "Управление менеджером доверенных сертификатов принятием решений о доверии сертификатам X.509" в Information Center.

• Для получения дополнительной информации о SSL-контексте можно, при желании, реализовать интерфейс com.ibm.wsspi.ssl.TrustManagerExtendedInfo. Дополнительная информация приведена в разделе "TrustManagerExtendedInfo JavaDoc" в Information Center.

Расширенное управление обменом подписчиками для клиентов с использованием инфраструктуры менеджера доверенных сертификатов

По умолчанию используемое клиентами хранилище доверенных сертификатов содержит сертификат доверенного подписчика для локального профиля. Если клиенту нужно взаимодействовать с другими серверами WebSphere, отсутствующими в первоначальном базовом профиле WebSphere Application Server, для установления доверенных отношений необходимо выполнить определенные дополнительные действия. При принятии решения о том, как установить доверенные отношения между клиентами и серверами V6.1, рассмотрите следующие возможности в порядке повышения уровня сложности:

1. Разрешите запрос на обмен подписчиками, установив свойство com.ibm.ssl.enableSignerExchangePrompt в значение true в файле ssl.client.props, расположенном в каталоге /properties профиля. Это свойство разрешено по умолчанию. После установления нового соединения при отсутствии подписчика в локальном хранилище доверенных сертификатов у клиента, пользователю отобразится запрос (если разрешено) на подтверждение работы с подписчиком. Предоставляется информация о сертификате, включая SHA-дайджест сертификата. Концепция аналогична используемой в web-браузерах для доверенных сертификатов. Дополнительная информация приведена в разделе "Установка защиты для получения информации о подписчике" в Information Center.

2. Загрузите всех подписчиков из общего хранилища доверенных сертификатов и затем обновите клиентские хранилища доверенных сертификатов. Это выполняется при помощи сценария retrieveSigners.bat (или .sh). Дополнительная информация приведена в разделе "Команда retrieveSigners" в Information Center.

3. Извлеките сертификат подписчика с сервера вручную и выполните импорт его в клиентское хранилище доверенных сертификатов.

4. Используйте программные API в клиентском приложении для программной установки доверенных отношений для конкретных соединений, либо постоянно для всех соединений (сохраняя подписчика в хранилище доверенных сертификатов). Это устранит ручное вмешательство, которое, по существу, требуется при запросе обмена подписчиками и в сценарии retrieveSigners. Эта возможность предназначена для автоматизированных сред тестирования или для любой достаточно надежной среды, чтобы разрешить отсрочку SSL-аутентификации сервера. Этот подход не должен использоваться в промышленной эксплуатации. Дополнительная информация приведена в разделе "com.ibm.wsspi.ssl.RetrieveSignersHelper SPI" в Information Center.

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

1. Программный вызов функции retrieveSigner для пакетной загрузки всех сертификатов секции.
2. Временный прием следующего сертификата сервера.
3. Прием следующего сертификата сервера и сохранение его для дальнейшего использования.

                
import com.ibm.wsspi.ssl.RetrieveSignersHelper;

A)/*** Получить экземпляр вспомогательного класса. ***/

RetrieveSignersHelper rsHelper = RetrieveSignersHelper.getInstance();

/*** Программно извлечь всех подписчиков уровня секции, передавая каждому 
те же самые параметры, которые вы передали бы в командной строке. Эти 
аргументы загрузят всех подписчиков из "CellDefaultTrustStore" в 
"ClientDefaultTrustStore". Параметр -autoAcceptBootstrapSigner
нужен, чтобы указать принятие подписчика для начала соединения. ***/


String[] args = new String[] {"CellDefaultTrustStore", 
"ClientDefaultTrustStore", "-autoAcceptBootstrapSigner"};

rsHelper.callRetrieveSigners (args);


B) /*** Альтернатива вызову функциональности retrieveSigners, которая 
позволяет разрешить доверенные отношения для конкретных соединений,
либо функциональности для загрузки и возможного сохранения подписчика
для конкретного соединения. Здесь мы временно принимаем сертификат
сервера, представляемый при следующем SSL-взаимодействии в данном
потоке. */
rsHelper.autoAcceptSignerForThisConnectionOnly();

/*** ИЛИ **
Аналогично предыдущему, но подписчик сохраняется в хранилище доверенных
 сертификатов. Он будет использоваться при всех последующих запросах. ***/

rsHelper.autoAcceptSignerAndStoreInTrustStore();

/*** Обратите внимание на то, что два эти вызова применяются только к
следующему SSL-взаимодействию. Если нужно подтвердить работу с несколькими
серверами, эти API необходимо вызвать перед каждым взаимодействием. ***/

Специализированные менеджеры ключей

В WebSphere Application Server V6.1 можно настроить менеджеры ключей для JSSE. Разрешена работа только одного менеджера ключей, поэтому им будет либо менеджер ключей по умолчанию IbmX509 (который знает, как выбрать сертификат из хранилищ ключей, настроенных в WebSphere), либо настроенный вами специализированный менеджер ключей. На клиентах или серверах можно использовать подключаемый менеджер ключей.

Желательно определить специализированный менеджер ключей, если вы хотите переопределить способ поиска сертификатов исполняющей системой. Наиболее вероятный сценарий - на стороне клиента (возможно, существует потребность поддерживать смарт-карты или нужно разрешить пользователю выбор сертификата для конкретного соединения). Дополнительная информация приведена в разделе "Управление в менеджере ключей идентичностью сертификатов X.509" в Information Center.

Использование сценария RetrieveSigners для обновления хранилищ доверенных сертификатов в серверной среде

Мы рассмотрели использование сценария RetrieveSigners для загрузки подписчиков с сервера на клиент. Сценарий RetrieveSigners определяет, какое хранилище доверенных сертификатов обновлять, читая конфигурационную информацию в файле ssl.client.props. Хотя этот сценарий предназначен для обновления хранилищ доверенных сертификатов на стороне клиента, есть некоторые ситуации, когда вам может понадобиться загрузить подписчиков из хранилища доверенных сертификатов одного сервера (или секции) в хранилище другого сервера (или секции). Это может понадобиться, например, если вы пробуете настроить взаимодействие между секциями.

Естественно, вы можете вручную экспортировать подписчиков из одной секции и импортировать их на другой. Но можно также "обмануть" сценарий RetrieveSigners, чтобы он сделал это вместо вас.

Для загрузки подписчиков в хранилище доверенных сертификатов на сервере вы можете изменить свойство ssl.client.props trustStoreName так, что бы оно временно указывало на соответствующее хранилище (вероятнее всего, это общее хранилище trust.p12, расположенное в каталоге cel). В листинге 3 приведен пример обновления ssl.client.props так, чтобы происходило обращение к хранилищу доверенных сертификатов уровня секции. Конечно же, этот пример должен запускаться на узле DeploymentManager, для того чтобы оригинальная копия файла хранилища доверенных сертификатов секции действительно обновилась.

                
/*** Измените файл properties/ssl.client.props перед запуском RetrieveSigners.  

Измените с:

# Информация TrustStore 
com.ibm.ssl.trustStoreName=ClientDefaultTrustStore
com.ibm.ssl.trustStore=${user.root}/etc/trust.p12

На: 

# Информация TrustStore 
com.ibm.ssl.trustStoreName=ClientDefaultTrustStore
#com.ibm.ssl.trustStore=${user.root}/etc/trust.p12
com.ibm.ssl.trustStore=${user.root}/config/cells/Machine40Cell01/trust.p12

Теперь выполните сценарий RetrieveSigners, указывая другие Cell или Server,
содержащие другой trust.p12.

***/

C:\WebSphere\AppServer\profiles\Dmgr01\bin> retrieveSigners.bat 
CellDefaultTrustStore ClientDefaultTrustStore –autoAcceptBootstrapSigner 
–host otherdmgr.raleigh.ibm.com –port 8879 –user myadmin –password myadminpwd

CWPKI0308I: Adding signer alias "CN=machine40.austin.ibm.com, O=IBM, 
C=US" to local keystore "ClientDefaultTrustStore" 
with the following SHA digest:
           A7:87:EA:E0:FA:26:38:F6:00:F7:CD:0C:88:6A:85:62:BC:D7:17:3D
CWPKI0308I: Adding signer alias "dummyclientsigner" to local keystore
           "ClientDefaultTrustStore" with the following SHA digest:
           0B:3F:C9:E0:70:54:58:F7:FD:81:80:70:83:A6:D0:92:38:7A:54:CD
CWPKI0308I: Adding signer alias "agentcert" to local keystore
           "ClientDefaultTrustStore" with the following SHA digest:
           88:12:C9:6D:3F:0E:9A:72:25:87:35:4F:BB:42:6D:A5:A8:62:89:D5
CWPKI0308I: Adding signer alias "dmgrcert" to local keystore
           "ClientDefaultTrustStore" with the following SHA digest:
           98:B3:A1:9C:16:DF:F8:A9:C2:31:12:A8:29:CC:D5:82:EE:F2:3A:F2
CWPKI0308I: Adding signer alias "dummyserversigner" to local keystore
           "ClientDefaultTrustStore" with the following SHA digest:
           FB:38:FE:E6:CF:89:BA:01:67:8F:C2:30:74:84:E2:40:2C:B4:B5:65

После завершения загрузки требуемых подписчиков вы, естественно, захотите отменить изменения в файле ssl.client.props. Также не забудьте выполнить синхронизацию узлов для репликации обновленного файла хранилища на другие узлы ячейки.

Изоляция конфигурации хранилища ключей для конкретного узла

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

На рисунке 15 показано создание конфигурации хранилища ключей с областью видимости "узел", управляемого удаленно. Причина удаленного управления заключается в том, что хранилище не сохраняется в конфигурационном репозитории WebSphere, что делает невозможным непосредственное манипулирование менеджером развертывания хранилищем ключей. Вместо этого, менеджер развертывания использует удаленные JMX-вызовы, чтобы передавать запросы агенту узла на целевом узле для управления хранилищем ключей.

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

1. Используйте вид topology после нажатия на ссылку Manage end point security configurations (управление конфигурациями защиты оконечной точки).
2. Выберите соответствующую область видимости для узла, затем нажмите кнопку New.
3. Из панели, показанной на рисунке 15, вы можете создать новое хранилище ключей для данного узла. Поскольку путь к хранилищу ключей в примере равен c:\temp, оно не будет располагаться в конфигурационном репозитории и, таким образом, не будет реплицироваться менеджером развертывания. Для того чтобы менеджер развертывания вообще мог управлять этим хранилищем ключей, оно должно быть способно управляться