Транспорт HTTPS-NIO также представляет собой модуль Apache Synapse. Класс получателя имеет следующее название:
org.apache.synapse.transport.nhttp.HttpCoreNIOSSLListener
Класс отправителя называется так:
org.apache.synapse.transport.nhttp.HttpCoreNIOSSLSender
Они доступны в пакете synapse-nhttp-transport.jar. Эти классы просто расширяют реализацию HTTP-NIO, добавляя в нее поддержку SSL. Таким образом они поддерживают все параметры конфигурации, поддерживаемые получателем и отправителем HTTP-NIO, а кроме того – параметры из приведенной ниже таблицы. Отправитель таже может выполнять проверку валидности сертификатов. Общая информация о транспортах размещена в разделе Работа с транспортами.
Параметры транспорта (общие для отправителя и получателя):
| Имя параметра | Описание | Является ли обязательным | Возможные значения |
| keystore | Здесь указывается используемое получателем или отправителем хранилище ключей по умолчанию, а также соответствующие параметры в виде XML-фрагмента. В XML должны быть указаны путь к файлу хранилища ключей, его тип и пароли для доступа к хранилищу. Хранилище ключей будет использоваться транспортом для инициализации набора менеджеров ключей. | Да |
<parameter name="keystore"> <KeyStore> <Location>lib/identity.jks</Location> <Type>JKS</Type> <Password>password</Password> <KeyPassword>password</KeyPassword> </KeyStore> </parameter> |
| truststore | Здесь должно быть указано хранилище доверия (truststore) по умолчанию, используемое получателем или отправителем, вместе с соответствующими параметрами в виде XML-фрагмента. В XML должны быть указаны местоположение файла хранилища доверия, его тип и пароль. Хранилище доверия используется транспортом для инициализации набора менеджеров доверия. | Да |
<parameter name="truststore"> <TrustStore> <Location>lib/identity.jks</Location> <Type>JKS</Type> <Password>password</Password> </TrustStore> </parameter> |
| customSSLProfiles | Транспорт HTTPS NIO поддерживает концепцию пользовательских SSL-профилей. SSL-профиль представляет собой определяему пользователем пару «хранилище ключей - хранилище доверия». Такой SSL-профиль может быть связан с одним или несколькими целевыми серверами. Например, когда HTTPS-отправитель подключается к целевому серверу, он использует SSL-профиль, связанный с этим сервером. Если для целевого сервера не настроены пользовательские SSL-профили, будет использоваться пара «хранилище ключей - хранилище доверия» по умолчанию. С помощью этой функции HTTPS-отправитель NIO может подключаться к различным целевым серверам, используя разные сертификаты и идентификационные данные. Приведенный пример содержит только один SSL-профиль, но может быть создано столько профилей, сколько потребуется. Каждый профиль должен быть связан как минимум с одним целевым сервером. Если профиль должен быть связан с несколькими серверами, их перечень нужно указать через запятую. Целевой сервер идентифицируется парой «хост-порт». | Нет |
<parameter name="customSSLProfiles> <profile> <servers>www.test.org:80, www.test2.com:9763</servers> <KeyStore> <Location>/path/to/identity/store</Location> <Type>JKS</Type> <Password>password</Password> <KeyPassword>password</KeyPassword> </KeyStore> <TrustStore> <Location>path/to/trust/store</Location> <Type>JKS</Type> <Password>password</Password> </TrustStore> </profile> </parameter> |
Проверка валидности сертификатов
Отправитель транспорта HTTPS-NIO может выполнить проверку в Удостоверяющем центре сертификации (УЦ), является ли сертификат по-прежнему доверенным. Если УЦ аннулировал сертификат, то соединение установлено не будет. Чтобы включить такую проверку, добавьте параметр CertificateRevocationVerifier в конфигурацию отправителя следующим образом:
<transportSender name="https" class="org.apache.synapse.transport.nhttp.HttpCoreNIOSSLSender"> ... <parameter name="CertificateRevocationVerifier">true</parameter> </transportSender>
Когда параметр CertificateRevocationVerifier установлен в значение true, INPOLUS ESB в фазе «рукопожатия» SSL-протокола задействует Online Certificate Status Protocol (OCSP) для выполнения проверки в УЦ. Если OCSP не поддерживается Центром сертификации, то INPOLUS ESB будет использовать вместо этого протокола Certified Revocation Lists (CRL). В процессе проверки проверяется каждый сертификат из цепочки сертификатов.
Ответ от УЦ будет содержать результат проверки валидности сертификата на данный момент, а также период, в течение которого сертификат будет оставаться валидным. Для предотвращения каких-либо потерь производительности HTTP-вызовов, данный ответ кэшируется на весь указанный в отчете УЦ срок действия сертификата. Таким образом, вызывать функцию проверки в дальнейшем больше не потребуется – до окончания периода валидности сертификата. Для OCSP и CRL поддерживается два in-memory кэша типа Least Recently Used (LRU), которые автоматически управляются выделенными под каждый из кэшей потоками CacheManager. Данные CacheManager’ы обновляют истекшие записи в кэше и поддерживают политики замены LRU-кэшей.