6.9.2 Setting up Client Authentication — MySQL Connectors 1.0

6.9.2 Настройка проверки подлинности клиента

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

Для разрешения проверки подлинности клиента соединяющийся с сервером клиент должен иметь собственный набор ключей и сертификат SSL. Сертификат клиента должен быть подписан, чтобы сервер мог его проверить. Хотя вы можете использовать сертификаты клиентов, подписанные официальными центрами сертификации, чаще используется промежуточный, частный сертификат центра сертификации (CA) для подписи сертификатов клиентов. Такой промежуточный сертификат CA может быть самоподписанным или подписанным доверенным корневым центром сертификации. Требование заключается в том, чтобы сервер знал сертификат центра сертификации (CA), способный валидировать сертификат клиента.

Некоторые сборки сервера MySQL могут генерировать ключи SSL и сертификаты для шифрования связи, включая сертификат и закрытый ключ (содержащиеся в файлах client-cert.pem и client-key.pem), которые могут использоваться любым клиентом. Этот сертификат SSL уже подписан самоподписанным сертификатом CA ca.pem, который, возможно, сервер уже настроен использовать.

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

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

Преобразуйте файлы ключа и сертификата клиента в архив PKCS #12:

$> openssl pkcs12 -export -in client-cert.pem -inkey client-key.pem \
  -name "mysqlclient" -passout pass:mypassword -out client-keystore.p12

Импортируйте ключ и сертификат клиента в хранилище ключей Java:
```
$> keytool -importkeystore -srckeystore client-keystore.p12 -srcstoretype pkcs12 \
 -srcstorepass mypassword -destkeystore keystore -deststoretype JKS -deststorepass mypassword 
```
Укажите правильные аргументы для параметров команды. Если файл хранилища ключей еще не существует, будет создан новый; в противном случае сертификат будет добавлен в существующий файл. Вывод keytool выглядит следующим образом:
```
Entry for alias mysqlclient successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled
```
Убедитесь, что вы запомнили выбранный пароль. Также обратите внимание, что пароль должен быть записан в виде обычного текста в вашем файле конфигурации Connector/J или исходном коде приложения.

После этого шага вы можете удалить архив PKCS #12 (client-keystore.p12 в примере).

Следующий шаг — настройка Java или Connector/J для чтения только что созданного или измененного хранилища ключей. Это можно сделать, используя один из следующих трех методов:

Использование аргументов командной строки Java:

-Djavax.net.ssl.keyStore=path_to_keystore_file
-Djavax.net.ssl.keyStorePassword=mypassword

Установка свойств системы непосредственно в коде клиента:

System.setProperty("javax.net.ssl.keyStore","path_to_keystore_file");
System.setProperty("javax.net.ssl.keyStorePassword","mypassword");

Через свойства подключения Connector/J:

clientCertificateKeyStoreUrl=file:path_to_truststore_file
clientCertificateKeyStorePassword=mypassword

Обратите внимание, что при совместном использовании свойства подключения перезаписывают значения, заданные другими двумя методами. Кроме того, любые значения, заданные с помощью свойств подключения, используются только в этом подключении, а значения, установленные с помощью системных значений, используются для всех подключений (если не переопределены свойствами подключения). Установка свойства подключения fallbackToSystemKeyStore в значение false предотвращает возврат Connector/J к системной настройке хранилища ключей, созданной вами с помощью метода (1) или (2), когда метод (3) не используется.

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

Для подключений X-Protocol свойства подключения xdevapi.ssl-keystore, xdevapi.ssl-keystore-type, xdevapi.ssl-keystore-password и xdevapi.ssl-fallbackToSystemKeyStore задают настройки хранилища ключей, точно так же, как trustCertificateKeyStoreUrl, trustCertificateKeyStoreType, trustCertificateKeyStorePassword и fallbackToSystemTKeyStore для подключений MySQL; если не указано явно, xdevapi.ssl-keystore, xdevapi.ssl-keystore-type, xdevapi.ssl-keystore-password и xdevapi.ssl-fallbackToSystemKeyStore принимают значения clientCertificateKeyStoreUrl, clientCertificateKeyStoreType, clientCertificateKeyStorePassword и fallbackToSystemKeyStore соответственно.