![]() |
|
![]() |
|
127018, Москва, ул.Сущевский Вал д.16 стр.5 Тел./факс: +7 (495) 780 4820 +7 (495) 660 2330 сайт: http://www.cryptopro.ru e-mail: info@cryptopro.ru |
![]() |
![]() |
|
![]() |
|
![]() |
Описание основной функциональности криптопровайдера КриптоПро JCP Руководство программиста. Модули шифрования Описание основной функциональности криптопровайдера КриптоПро JCP (модули шифрования) Связь с разработчиком. |
КриптоПро JTLS является программным комплексом защиты информации, разработанным на основе КриптоПро JCP 1.0 и реализующим протоколы SSL и TLS в соответствии с российскими криптографическими алгоритмами.
Основные функции, реализуемые КриптоПро JTLS:
Предварительно установить КриптоПро JCP (включая модули шифрования). Далее установку можно выполнить двумя путями:
"<JRE>/bin/java -jar cpSSL.jar"
и затем ввести серийный номер через контрольную панель<JRE>/bin/java -cp cpSSL.jar ru.CryptoPro.ssl.JTLSInstall -install -verbose -sslserial XXXXX-XXXXX-XXXXX-XXXXX-XXXXX -sslcompany "My Company"
Для использования КриптоПро JTLS на Java более ранней версии, чем 1.5.0_12 и преодоления экспортных ограничений на стойкую криптографию см. Особенности подключения КриптоПро JTLS.
ПКЗИ КриптоПро JTLS реализует стандартный интерфейс Java Secure Socket Extension (JSSE) v.1.4 и обеспечивает выполнение защищенной передачи данных по протоколам SSL и TLS в соответствии с российскими криптографическими алгоритмами через стандартный интерфейс JSSE.
Из-за того, что обычно в JSSE, помимо самого интерфейса, включаются и некоторые его реализации
(примером такой реализации на SUNовской виртуальной машине является провайдер
com.sun.net.ssl.internal.ssl.Provider
), существуют некоторые особенности использования
ПКЗИ КриптоПро JTLS.
Для использования КриптоПро JTLS на Java более ранней версии, чем 1.5.0_12, необходимо выполнить дополнительные действия:
xjsse4.jar
в директорию
<JRE>/lib/ext/
;xjsse4.jar
при помощи опции -Xbootclasspath/p:<JRE>/jre/lib/ext/xjsse4.jar;
Возможна ситуация, когда установленная JRE имеет экспортные ограничения.
США запрещает экспорт "сильной" криптографии и JCP с длиной ключа
256 бит попадает под это ограничение.
Ограничения устанавливаются файлами local_policy.jar
и US_export_policy.jar
в каталоге <JRE>/jre/lib/security
.
Для снятия экспортных ограничений
необходимо скачать файл jce_policy-6.zip
с политиками со страницы
http://java.sun.com/javase/downloads/index.jsp
, выбирая "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6".
Для отладки же можно просто скопировать US_export_policy.jar
в local_policy.jar
(оба файла должны присутствовать).
После того, как КриптоПро JTLS подключен, дальнейшая работа с протоколами SSL и TLS
в соответствии с российскими криптографическими алгоритмами осуществляется через стандартный интерфейс
JSSE, например, при помощи метода getDefault()
классов
SSLServerSocketFactory и
SSLSocketFactory.
// порт, по которому данный сервер устанавливает соединение int port; SSLServerSocketFactory sslSrvFact = (SSLServerSocketFactory) SSLServerSocketFactory .getDefault(); SSLServerSocket ss = (SSLServerSocket)sslSrvFact.createServerSocket(port);Защищенное соединение в общем случае может быть осуществлено и при помощи класса ServerSocket (объекты именно этого класса возвращаются методом createServerSocket(port)). Однако, такой класс имеет меньшую функциональность, чем его расширение - класс SSLServerSocket. Выбор того, каким классом пользоваться, базируется на необходимости установления тех или иных атрибутов процесса обмена.
// порт сервера, по которому устанавливается соединение int port; // имя хоста сервера, по которому устанавливается соединение String host; SSLSocketFactory sslFact = (SSLSocketFactory) SSLSocketFactory.getDefault(); SSLSocket soc = (SSLSocket)sslFact.createSocket(host, port);Защищенное соединение в общем случае может быть осуществлено и при помощи класса Socket (объекты именно этого класса возвращаются методом createSocket(host, port)). Однако, такой класс имеет меньшую функциональность, чем его расширение - класс SSLSocket. Выбор того, каким классом пользоваться, базируется на необходимости установления тех или иных атрибутов процесса обмена.
Примеры создания защищенного соединения между клиентом и сервером по протоколу TLS приводятся в Samples/JTLS_samples, входящих в пакет поставки КриптоПро JCP. Пакет ComLine модуля Samples содержит примеры сервера и клиента, запускаемые из командной строки.
В ПКЗИ КриптоПро JTLS в процессе установления защищенного соединения по протоколам SSL и TLS используются следующие три типа объектов:
В зависимости от роли данной стороны (клиент или сервер), а также от типа аутентификации (односторонняя или двусторонняя) существуют особенности использования данных объектов.
В ПКЗИ КриптоПро JTLS аутентификация может быть односторонней или двусторонней (т.е. сервер ВСЕГДА отправляет свой сертификат аутентификации клиенту). Поэтому, если данная сторона является сервером, то необходимо, чтобы у нее существовали закрытый ключ и соответствующий ему сертификат (цепочка сертификатов) аутентификации, в соответствии с которыми и будет устанавливаться защищенное соединение. Причем, допустимы к использованию только следующие пары (закрытый ключ обмена и соответствующий ему сертификат аутентификации):
Таким образом, перед началом осуществления соединения с клиентом, такие закрытый ключ и соответствующий ему сертификат (цепочка сертфикат) необходимо создать и затем положить в ключевое хранилище, из которого они и будут прочитаны в процессе обмена. Методы выполнения этих операций подробно описаны в руководстве программиста КриптоПро JCP, а также в руководство программиста (модули шифрования). Ниже приводятся примеры таких методов.
Создание закрытого ключа обмена и соответствующего ему открытого ключа осуществляется при помощи
методов стандартного класса KeyPairGenerator
, проинициализированного именем "GOST3410DH"
(это имя соответствует алгоритмам обмена Диффи-Хэллмана и подписи ГОСТ 34.10-2001):
KeyPairGenerator kg = KeyPairGenerator.getInstance("GOST3410DH"); KeyPair pair = kg.generateKeyPair(); // закрытый ключ обмена PrivateKey privKey = pair.getPrivate(); // соответствующий ему открытый ключ PublicKey pubKey = pair.getPublic();
Создание сертификата аутентификации при помощи методов класса GostCertificateRequest
,
представляющего собой дополнительную возможность работы с сертификатами, реализованную на базе СКЗИ КриптоПро JCP
(подробное описание смотри в соответствующем разделе):
String keyAlg = "GOST3410DH"; String certName = "CN=newCert, O=CryptoPro, C=RU"; String httpAddress = "http://www.cryptopro.ru/certsrv/"; // создание запроса на сертификат аутентификации сервера GostCertificateRequest request = new GostCertificateRequest(); request.setKeyUsage(GostCertificateRequest.CRYPT_DEFAULT); request.addExtKeyUsage(GostCertificateRequest.INTS_PKIX_CLIENT_AUTH); request.addExtKeyUsage(GostCertificateRequest.INTS_PKIX_SERVER_AUTH); request.setPublicKeyInfo(pubKey); request.setSubjectInfo(certName); request.encodeAndSign(privKey); // отправка запроса центру сертификации и получение от центра // сертификата в DER-кодировке byte[] encoded = request.getEncodedCert(httpAddress); // генерация X509-сертификата из закодированного представления сертификата CertificateFactory cf = CertificateFactory.getInstance("X509"); java.security.cert.Certificate cert = cf.generateCertificate(new ByteArrayInputStream(encoded));
Запись созданного закрытого ключа и цепочки сертификатов, состоящей из сертификата аутентификации и корневого сертификата центра сертификации, на жесткий диск (более подробно о типах ключевых хранилищ, реализованных в КриптоПро JCP, и особенностях их использования, читай в соответствующем разделе ):
String password = "password"; String alias = "newKey"; String certPath = "C:\\certificate.cer"; // файл, в который был предварительно // сохранен корневой сертификат центра CertificateFactory cf = CertificateFactory.getInstance("X509"); FileInputStream fis = new FileInputStream(certPath); java.security.cert.Certificate certRoot = cf.generateCertificate(new BufferedInputStream(fis)); java.security.cert.Certificate[] certs = new java.security.cert.Certificate[2]; certs[0] = certRoot; certs[1] = cert; KeyStore hdImageStore = KeyStore.getInstance("HDImageStore"); hdImageStore.load(null, null); hdImageStore.setKeyEntry(alias, privKey, password.toCharArray(), certs); hdImageStore.store(null, null);
В данных примерах приводилось использование тестового центра сертификации КриптоПро. Получение корневого сертификата этого центра может быть осуществлено по следующей ссылке. Для рабочих целей (при обращении к центру сертификации КриптоПро УЦ) получение корневого сертификата осуществляется по следующей ссылке.
Также можно воспользоваться готовыми классами пакета ComLine из модуля Samples, входящего в состав КриптоПро JCP. Запустите ComLine с вызовом нужного класса либо сам класс, используя следующие параметры командной строки:
java ComLine NameofClass args
или java NameofClass args
например:
java ComLine KeyPairGen -alias name_of_key -dname CN=autor,OU=Security,O=CryptoPro,C=RU -reqCertpath C:/req.txt
или
java KeyPairGen -alias name_of_key -dname CN=autor,OU=Security,O=CryptoPro,C=RU -reqCertpath C:/req.txt
Получение сертификата из запроса, представленного в DER-кодировке и запись его в хранилище и в файл.
Построение цепочки сертификатов.
Сам процесс обмена начинается с того, что определяется, какая именно пара (закрытый ключ обмена - сертификат аутентификации сервера) будет использован. Для этого пользователю, выполняющему роль сервера, необходимо указать, из какого ключевого хранилища будет прочитана требуемая пара. Указывается это при помощи системных настроек следующим образом:
System.setProperty("javax.net.ssl.keyStoreType","HDImageStore"); System.setProperty("javax.net.ssl.keyStorePassword","password");
Настройка "javax.net.ssl.keyStoreType"
задает тип ключевого носителя, с которого будет прочитан
закрытый ключ и соответствующий ему сертификат аутентификации (цепочка сертификатов). Таким образом, в качестве
типа носителя нужно указывать тот носитель, на который предварительно была записана требуемая пара.
Если такую настройку не производить, то по умолчанию в качестве носителя будет использован жесткий диск
("HDImageStore"
).
Настройка "javax.net.ssl.keyStorePassword"
определяет пароль на закрытый ключ обмена. Таким образом,
в качестве пароля нужно указывать тот пароль, с которым на носитель была записана требуемая ключевая пара.
Если такую настройку не производить, то по умолчанию будет использоваться нулевой пароль.
Таким образом, с заданного носителя "javax.net.ssl.keyStoreType"
будут прочитаны все хранящиеся на нем
закрытые ключи и сертификаты (цепочки сертификатов), удовлетворяющие паролю "javax.net.ssl.keyStorePassword"
и требованиям:
В качестве рабочей пары будет выбрана первая.
В случае двусторонней аутентификации, клиент присылает серверу свой сертификат аутентификации. Сервер при этом должен проверить, что сертификату клиента можно доверять. Для этих целей в ПКЗИ КриптоПро JTLS используется так называемое множество доверенных сертификатов, которое определяется при помощи следующих системных настроек:
System.setProperty("javax.net.ssl.trustStoreType","HDImageStore"); System.setProperty("javax.net.ssl.trustStore","C:\\Java\\jcp\\trust"); System.setProperty("javax.net.ssl.trustStorePassword","password");
Настройка "javax.net.ssl.trustStoreType"
определяет тип хранилища сертификатов. Как
описано в соответствующем разделе, в КриптоПро JCP хранилище
сертификатов, как правило, ассоциируется с некоторым ключевым носителем (при этом тип хранилища сертификатов
совпадает с типом ключевого носителя). Таким образом, если в данной
настройке в качестве типа хранилища указывает тип ключевого носителя, то с указанного носителя
будут прочитаны все корневые сертификаты цепочек и эти сертификаты будут добавлены во множество доверенных сертификатов
(если цепочка состоит из одного сертификата, то этот сертификат
также будет считаться доверенным). Если такую настройку не производить, то по умолчанию в качестве
типа хранилища сертификатов будет использован жесткий диск ("HDImageStore"
)
Настройка "javax.net.ssl.trustStore"
задает путь к хранилищу сертификатов, соответствующему
типу "javax.net.ssl.trustStoreType"
. Такое хранилище используется в том случае, когда сертификат клиента
подписан некоторым центром сертификации, корневой сертификат которого не участвует ни в одной цепочке,
прочитанной с носителя "javax.net.ssl.trustStoreType"
, однако серверу известно, что такому центру
сертификации можно доверять. Для этого, серверу предварительно необходимо положить корневой сертификат этого центра
в хранилище сертификатов "javax.net.ssl.trustStore"
следующим образом:
String certPath = "C:\\certificate.cer"; // файл, в который был предварительно // сохранен корневой сертификат центра KeyStore ks = KeyStore.getInstance("HDImageStore"); ks.load(null, null); CertificateFactory cf = CertificateFactory.getInstance("X509"); FileInputStream fis = new FileInputStream(certPath); java.security.cert.Certificate cert = cf.generateCertificate(new BufferedInputStream(fis)); ks.setCertificateEntry("certificate", cert); FileOutputStream fos = null; fos = new FileOutputStream("C:\\Java\\jcp\\trust"); ks.store(fos, "password".toCharArray()); fos.close();
Из указанного хранилища сертификатов будут прочитаны все сертификаты, и они также будут добавлены во множество
доверенных сертификатов. Если данную настройку не производить, то по умолчанию хранилище сертификатов
использоваться не будет (в качестве доверенных будут использоваться только корневые сертификаты цепочек, прочитанных
с носителя"javax.net.ssl.trustStoreType"
).
Настройка "javax.net.ssl.trustStorePassword"
определяет пароль на доступ к хранилищу сертификатов
(пароль, с которым это хранилище было сохранено). Если такую настройку не производить, то пароль считается нулевым.
Повторим, что определенное таким образом множество доверенных сертификатов сервером используется только в случае двусторонней аутентификации (т.е. в этом случае оно не должно быть пустым). В случае двусторонней аутентификации сервер отравляет клиенту список имен издателей, которым он доверяет. Этот список формируется из имен субъектов всех доверенных сертификатов.
При получении сертификата аутентификации (цепочки сертификатов) от клиента, он считается успешно проверенным в одном из четырех случаев:
С точки зрения роли клиента основное различие в управлении ключами проводится для эфемерального и неэфемерального обмена. Неэфемеральный обмен в ПКЗИ КриптоПро JTLS допустим только для ключей обмена, соответствующих алгоритмам обмена Диффи-Хэллмана и подписи ГОСТ 34.10-2001. Для эфемерального обмена допустима генерация эфемеральной ключевой пары в соответствии с алгоритмом ГОСТ 34.10-94 но только в том случае, когда открытый ключ переданного сервером сертификата соответствует алгоритму ГОСТ 34.10-94. Такое допущение выполнено исключительно для поддержки серверов с ключами 94-го года и не рекомендуется к использованию. Во всех остальных случаях, эфемеральный обмен производится на ключах, соответствующих алгоритму ГОСТ 34.10-2001.
Напомним, что эфемеральный обмен осуществляется в двух случаях:
Как следует из описанного выше, в случае двусторонней аутентификации, если данная сторона является клиентом, необходимо чтобы у нее существовали закрытый ключ и соответствующий ему сертификат (цепочка сертификатов) аутентификации. Причем, допустимы к использованию только следующие пары (закрытый ключ обмена и соответствующий ему сертификат аутентификации):
Таким образом, перед началом осуществления соединения с сервером в случае двусторонней аутентификации, такие закрытый ключ и соответствующий ему сертификат (цепочку сертификатов) необходимо создать и затем положить в ключевое хранилище, из которого они и будут прочитаны в процессе обмена. Осуществление таких действий производится аналогично описанию для сервера. Единственная разница состоит в том, что создаваемый сертификат аутентификации имеет расширения сертификата аутентификации клиента. Создание таких сертификатов производится по следующей схеме:
String keyAlg = "GOST3410DH"; String certName = "CN=newCert, O=CryptoPro, C=RU"; String httpAddress = "http://www.cryptopro.ru/certsrv/"; // создание запроса на сертификат аутентификации сервера GostCertificateRequest request = new GostCertificateRequest(); request.setKeyUsage(GostCertificateRequest.CRYPT_DEFAULT); request.addExtKeyUsage(GostCertificateRequest.INTS_PKIX_CLIENT_AUTH); request.setPublicKeyInfo(pubKey); request.encodeAndSign(privKey); // отправка запроса центру сертификации и получение от центра // сертификата в DER-кодировке byte[] encoded = request.getEncodedCert(httpAddress); // генерация X509-сертификата из закодированного представления сертификата CertificateFactory cf = CertificateFactory.getInstance("X509"); java.security.cert.Certificate cert = cf.generateCertificate(new ByteArrayInputStream(encoded));
Эта работа осуществляет только в случае двусторонней аутентификации и аналогична описанию для сервера. Единственная разница состоит в выборе пары (закрытый ключ обмена - сертификат аутентификации). Если в случае сервера, в качестве рабочей пары выбирается первая подходящая пара, прочитанная с ключевого носителя, то в данном случае возможны два варианта:
Поскольку считается, что сервер ВСЕГДА присылает свой сертификат клиенту, то проверка сертификата клиентом осуществляется всегда. Она основывается на множестве доверенных сертификатов клиента, формируемого и используемого аналогично описанию сервера. Очевидно, что это множество должно быть не пустым.
ПКЗИ КриптоПро JTLS реализует четыре варианта шифр-сюит. В реализованных шифр-сюитах используются следующие алгоритмы:
Ниже приводится таблица с кратким описанием реализуемых КриптоПро JTLS шифр-сюит:
Имя шифр-сюиты | Идентификатор шифр-сюиты | Алгоритм ключей обмена | Режим шифрования данных по алгоритму ГОСТ Р 28147-89 |
TLS_CIPHER_2001 | 0x81 | ГОСТ 34.10-2001 | Гаммирование |
TLS_CIPHER_94 | 0x80 | ГОСТ 34.10-94 | Гаммирование |
SSL3_CK_GVO_KB2 | 0x32 | ГОСТ 34.10-94 или ГОСТ 34.10-2001 | Гаммирование с обратной связью |
SSL3_CK_GVO | 0x31 | ГОСТ 34.10-94 или ГОСТ 34.10-2001 | Гаммирование с обратной связью |
В данной таблице шифр-сюиты перечислены в порядке уменьшения приоритета. Соответственно, при получении от клиента списка шифр-сюит, сервер выбирает подходящую шифр-сюиту с наибольшим приоритетом.
При инициализации процесса обмена, текущая сторона формирует список поддерживаемых шифр-сюит. Этот список будет различаться в зависимости от того, является текущая сторона клиентом или сервером. Поддерживаемые шифр-сюиты заносятся в список в соответствии с порядком их приоритета (первой заносится шифр-сюита с наибольшим приоритетом). Дальнейший процесс обмена текущей стороной будет осуществляться в соответствии с сформированным списком. Отправка клиентом списка серверу осуществляется именно в таком виде, в каком он был сформирован (в порядке уменьшения приоритета). Разбор полученного от клиента списка сервером также осуществляется в порядке уменьшения приоритета.
System.setProperty("javax.net.ssl.supportGVO","true")
. Такое подключение
не рекомендуется к использованию. После того, как шифр-сюита подключена, она будет занесена в список поддерживаемых
клиентом шифр-сюит последней.
Таким образом, формируются следующие списки поддерживаемых шифр-сюит:
Клиент | Сервер |
TLS_CIPHER_2001 | TLS_CIPHER_2001 |
TLS_CIPHER_94 | |
SSL3_CK_GVO_KB2 | SSL3_CK_GVO_KB2 |
SSL3_CK_GVO (опционально) | SSL3_CK_GVO |
Ниже приводится таблица, в которой описывается, какая именно шифр-сюита будет выбрана сервером при условии при осуществлении процесса обмена с различными версиями КриптоПро JTLS.
Клиент | Сервер | Выбираемая сервером шифр-сюита |
JTLS 1.0 | JTLS 1.0 | TLS_CIPHER_2001 |
JTLS 1.0 | CSP 2.0 | SSL3_CK_GVO_KB2 |
JTLS 1.0 | CSP 3.0 | TLS_CIPHER_94 или TLS_CIPHER_2001 |
CSP 2.0 | JTLS 1.0 | SSL3_CK_GVO |
CSP 3.0 | JTLS 1.0 | TLS_CIPHER_2001 |
Основной набор закладок контрольной панели КриптоПро JCP описан в Руководстве администратора. После установки модуля КриптоПро JTLS на контрольной панели появятся соответствующие закладки.
Данная панель содержит информацию о серверной лицензии КриптоПро JTLS. Работа с данной панелью аналогична работе с закладкой "Общие" (панель "Лицензия").
Данная панель содержит настройки сервера:
Основы использования SSL/TLS в читайте в Apache Tomcat SSL Configuration HOW-TO.
Apache Tomcat имеет собственный интерфейс для встраивания SSL/TLS протоколов. Для поддержки существующих интерфейсов и реализаций SSL/TLS, таких как PureTLS и JSSE, в нём используются наборы классов-переходников. Для встраивания КриптоПро JTLS в Apache Tomcat можно воспользоваться
Переходник КриптоПро TomCatSSL использует Sun JSSE, но позволяет применять стойкие криптографические алгоритмы (с ключами большой длины). Встроенный переходник не позволяет делать этого напрямую, если в реализации JSSE заложены экспортные ограничения, как, например, это сделано в Sun JSSE.
Настройка Apache Tomcat проводится в следующем порядке:
Сертификат выпускается, как указано выше или в руководстве программиста. Его общее имя (common name) должно совпадать с DNS-именем (или IP - при обращении клиентов только по IP) сервера Apache Tomcat. Apache Tomcat перебирает все сертификаты пользователя, под учетной записью которого он работает, пока не найдет подходящий (по назначению и паролю), поэтому необходимо обеспечить его уникальность именно в этом смысле.
По умолчанию (в Windows) Apache Tomcat ищет контейнер с сертификатом под учетной записью системы (даже если в настройках Apache Tomcat указать свойство LogOn под пользовательской учетной записью, поиск подходящего контейнера он все равно ведет в этой папке) поэтому следует либо создать его под учетной записью системы, либо вручную переложить созданный под своей учетной записью контейнер из
%USERPROFILE%\Local Settings\Application Data\Crypto Pro\
в
%USERPROFILE%\..\Default User\Local Settings\Application Data\Crypto Pro\
,
либо настроить Apache Tomcat под свою учетную запись следующим образом:
Панель управления -> Администрирование -> Службы и приложения -> Службы -> Apache Tomcat свойства -> вход в систему: с учетной записью (указать имя и пароль).
Для настройки коннектора Apache Tomcat необходимо добавить в файл
<CATALINA_HOME>/conf/server.xml
строки по следующему образцу:
<Connector port="8443" maxHttpHeaderSize="8192" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="GostTLS" algorithm="GostX509" keystoreProvider="JCP" keystoreFile="<USER_HOME>/.keystore" keystorePass="11111111" keystoreType="HDImageStore" keyalg="GOST3410" sigalg="GOST3411withGOST3410EL" />
Описание основных параметров смотрите в
документации на Apache Tomcat. В keystoreFile
указывается путь к соответствующему файлу. В keystorePass
- пароль на контейнер.
При указанном выше описании используется встроенный переходник для JSSE.
Tomcat может использовать библиотеки Apache Portable Runtime (APR) для повышения производительности.
APR использует платформо-зависимую реализацию SSL, которая не может работать с российскими ГОСТ алгоритмами и
Java настройками типа keystoreFile
и выдаст ошибку.
Для предотвращения автоконфигурации через APR и задания Java коннектора,
независимо от того загружены ARP библиотеки или нет, необходимо
в описании коннектора явно задать имя класса реализации в атрибуте протокола
protocol="org.apache.coyote.http11.Http11Protocol"
.
При аутентификации клиента (clientAuth="true"
) следует также указать путь к хранилищу сертификатов
(truststoreFile="<USER_HOME>/.keystore"
) и пароль (truststorePass="1111111".
)
Если используется переходник КриптоПро TomCatSSL, то необходимо скопировать TomCatSSL.jar
в <CATALINA_HOME>/server/lib/
(или <CATALINA_HOME>/lib/
) и добавить в описание коннектора
строку:
"SSLImplementation="ru.CryptoPro.TomCatSSL.JSSEImplementation"
Для настройки журналирования действий КриптоПро JTLS в файле <CATALINA_HOME>/conf/logging.properties
необходимо:
handlers = ...
Cоответсвующие изменения помечены жирным шрифтом:
handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler, 5host-manager.org.apache.juli.FileHandler, 6jtls.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler .handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################ 1catalina.org.apache.juli.FileHandler.level = FINE 1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs 1catalina.org.apache.juli.FileHandler.prefix = catalina. 2localhost.org.apache.juli.FileHandler.level = FINE 2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs 2localhost.org.apache.juli.FileHandler.prefix = localhost. 3manager.org.apache.juli.FileHandler.level = FINE 3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs 3manager.org.apache.juli.FileHandler.prefix = manager. 4admin.org.apache.juli.FileHandler.level = FINE 4admin.org.apache.juli.FileHandler.directory = ${catalina.base}/logs 4admin.org.apache.juli.FileHandler.prefix = admin. 5host-manager.org.apache.juli.FileHandler.level = FINE 5host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs 5host-manager.org.apache.juli.FileHandler.prefix = host-manager. 6jtls.org.apache.juli.FileHandler.level = FINE 6jtls.org.apache.juli.FileHandler.directory = ${catalina.base}/logs 6jtls.org.apache.juli.FileHandler.prefix = jtls. java.util.logging.ConsoleHandler.level = FINE java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter ############################################################ # Facility specific properties. # Provides extra control for each logger. ############################################################ org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers = 3manager.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].handlers = 4admin.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers = 5host-manager.org.apache.juli.FileHandler SSLLogger.level = FINE SSLLogger = 6jtls.org.apache.juli.FileHandler # For example, set the com.xyz.foo logger to only log SEVERE # messages: #org.apache.catalina.startup.ContextConfig.level = FINE #org.apache.catalina.startup.HostConfig.level = FINE #org.apache.catalina.session.ManagerBase.level = FINE
Для отладки ssl соединения можно воспользоваться встроенным логгером.
Для этого установите уровень FINE в jre/lib/logging.properties:
.level = FINE ... java.util.logging.ConsoleHandler.level = FINE
SSLLogger является расширением стандартного класса Logger (см. документацию java).