Как реализовать Mutual TLS?

Question

[Александр Маджугин]

Требуется выполнять запросы к платежной системе защищённые с помощью двухстороннего TLS.
К сожалению документация партнёра ограничена двумя предложениями:

Сертификат, приватный ключ и пароль приватного ключа партнер использует для запросов к API.
Безопасность соединения между партнером и платежной системой обеспечивается с помощью
механизма двустороннего TLS (Mutual TLS, TLS v1.2).

Сам никогда не сталкивался с таким способом аутентификации. Гугл приводит на документации о том, как настроить серверы на прием клиентских сертификатов в лучшем случае, а в большинстве на рассказы о том что это такое.
Да и в целом не оч. ясно что гуглить.

Как это реализовать в общем случае на PHP ?

Сейчас я устанавливаю такие опции для curl:

$options[CURLOPT_SSL_VERIFYHOST] = true;
                $options[CURLOPT_SSL_VERIFYPEER] = true;
                $options[CURLOPT_CAINFO] = $this->certdir->getPath().'/public.cer';
$options[CURLOPT_CAPATH] = $this->certdir->getPath().'/public.cer';

Но очевидно просто пути к сертификату не достаточно. В инструкции указано что я как-то должен задействовать еще и приватный ключ и его пароль.

Вообще говоря у меня есть следующий набор файлов:
certfile.pfx
kbs_ca.crt
kbs_root_ca.crt
private.key
public.cer

+ пароль приватного ключа

Answer 1

[shurshur]

Сначала немного теории.

CA - Certificate Authority - доверенный удостоверящий центр, который подписывает сертификаты.
У каждой стороны есть секретный ключ, который она никому не показывает, и публичный ключ, он же сертификат. Чтобы подтвердить, что сертификат принадлежит обеим сторонам, эти сертификаты должны иметь подпись доверенного лица, в данном случае CA.

Обычно мы привыкли, что в SSL только серверная сторона доказывает свою подлинность. Идея mTLS в том, что обе стороны должны предоставить свой публичный сертификат, подписанный CA. Тогда если сервер доверяет CA, он будет доверять и клиентскому сертификату.

Но публичный ключ не имеет смысла без приватного. А в куске кода в вопросе он вообще не встречается.

Итак, что нам нужно для установления сессии?

1. Сертификат CA - kbs_ca.crt (скорее всего, можно склеить оба CA - промежуточный и корневой - в один файл);
2. Приватный ключ клиента, который он будет использовать для шифрования - private.key;
3. Соответствующий приватному публичный ключ-сертификат, который клиент будет сообщать серверу - public.cer.

Я ввёл в гугл "php curl mtls" и в первой же ссылке есть пример кода: https://smallstep.com/hello-mtls/doc/client/php

В примере, конечно, нет пароля от ключа, но справка подсказывает, что это опция CURLOPT_SSLKEYPASSWD.

Comments

[Александр Маджугин]

Выглядит обосновано. Но не работает. Ни с kbs_ca.crt в CURLOPT_SSLCERT, ни со склейкой с корневым в любых последовательностях.
Написал в поддержку сервиса - может что-то подскажут.

[shurshur]

Александр Маджугин, я бы ещё проверил, может там сертификат серверной стороны подписан другим корневым, тогда надо тот CA тоже добавить. И с CURLOPT_VERBOSE тоже попробовать.

Ну и конечно попробовать обычным curl из командной строки поотлаживать тоже.

[Александр Маджугин]

CURLOPT_VERBOSE какого-то черта не работает (в комменте к другому ответу писал).
Пока жду ответ от саппорта сервиса...

[Александр Маджугин]

shurshur, разобарлся почему CURLOPT_VERBOSE не работал. Вот выхлоп:

* About to connect() to xxxxxxxxxx.xxxx.xx port 8545 (#13)
*   Trying 194.187.xxx.xx...
* Connected to xxxxxxxxxx.xxxx.xx (194.187.xxx.xx) port 8545 (#13)
* failed to load '/home/bitrix/www/local/modules/module/cert/private.key' from CURLOPT_CAPATH
* failed to load '/home/bitrix/www/local/modules/module/cert/certfile.pfx' from CURLOPT_CAPATH
* failed to load '/home/bitrix/www/local/modules/module/cert/kbs_root_ca.crt' from CURLOPT_CAPATH
* failed to load '/home/bitrix/www/local/modules/module/cert/ca.crt' from CURLOPT_CAPATH
* failed to load '/home/bitrix/www/local/modules/module/cert/kbs_ca.crt' from CURLOPT_CAPATH
*   CAfile: /home/bitrix/www/local/modules/module/cert/public.cer
  CApath: /home/bitrix/www/local/modules/module/cert
* unable to load client cert: -8018 (SEC_ERROR_UNKNOWN_PKCS11_ERROR)
* NSS error -8018 (SEC_ERROR_UNKNOWN_PKCS11_ERROR)
* Unknown PKCS #11 error.
* Closing connection 13

[shurshur]

Александр Маджугин, ну вот судя по всему из CAPATH загрузился только public.cer. Там вообще файлы в каком формате? Наверное, лучше в PEM, чем DER.

[Александр Маджугин]

shurshur, он загрузился потому что указана в CURLOPT_CAINFO. Из CURLOPT_CAPATH ничего не грузится. Файлы там такие:
certfile.pfx
kbs_ca.crt
kbs_root_ca.crt
private.key
public.cer

еще если указать просто папку с файлами в CURLOPT_SSLCERT (увидел такое в одном из примеров) то пишет такое:

* About to connect() to xxxxxxxx.xxxx.xx port 8545 (#1166)
*   Trying 194.187.xxx.xx...
* Connected to xxxxxxxx.xxxx.xx (194.187.xxx.xx) port 8545 (#1166)
*   CAfile: /home/bitrix/www/local/modules/module/cert/public.cer
  CApath: none
* Server certificate:
* 	subject: CN=xxxxxxxx.xxxx.xx,O=KBS,L=Almaty,C=KZ
* 	start date: Jul 09 10:19:02 2021 GMT
* 	expire date: Jul 09 10:29:02 2026 GMT
* 	common name: xxxxxxxx.xxxx.xx
* 	issuer: CN=KBS-CA
* NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)
* Peer's certificate issuer has been marked as not trusted by the user.
* Closing connection 1166

[shurshur]

Александр Маджугин, клиент не доверяет CN=xxxxxxxx.xxxx.xx,O=KBS,L=Almaty,C=KZ, сравнивая с CA public.cer. Что логично, ведь public.cer это не сертификат подписанта xxxxxxxx.xxxx.xx, а собственный сертификат пользователя. В приниципе, CURLOPT_SSL_VERIFYPEER в значении false должен отключать эту проверку...

[Александр Маджугин]

Ответ сапорта:

Kbs ca это промежуточные
Запросы должны ходить через public

Вот не контактные люди...

В логе:

* warning: ignoring value of ssl.verifyhost
* unable to load client key: -8178 (SEC_ERROR_BAD_KEY)
* NSS error -8178 (SEC_ERROR_BAD_KEY)
* Peer's public key is invalid.

Вроде так бывает когда пароль не подходит к ключу.
Но может есть еще какие-то варианты?

[shurshur]

Александр Маджугин, public.cer это не CA, это клиентский сертификат.

Предлагаю попробовать поупражняться с curl --cert.

curl -k --cert my_cert.pem:my_password https://....

Опция -k нужна чтобы не проверять сертификат другой стороны. Для первого теста подойдёт.

В my_cert.pem надо положить по порядку ключ и клиентский сертификат в формате PEM.

Я сражался с подобным полгода назад, правда, мне надо было просто сделать тестовый стенд для разработчика, а не подключиться к какому-то живому сервису.

[Александр Маджугин]

shurshur, короче оказалось что клиентский сертификат и ключ к нему надо было извлечь из файла certfile.pfx и использовать их.
После чего всё заработало. Фактически проблема была в неверной информации предоставленной партнером. Спасибо за помощь.

Answer 2

[Dimonchik]

тут что не так?

Comments

[Александр Маджугин]

Кроме того что не работает?
1 Не очень понятно зачем эта генерация pem на PHP. Почему бы его на этапе генерации сертификата не сгенерировать из всего этого набора что у меня есть и просто подставлять в CURLOPT_SSLCERT?
2 Зачем вообще столько файлов, если оказывается нужен всего один?

Но это конечно вопросы общего плана. По реализации - не работает.

Кстати почему-то не пишется лог curl (((
CURLOPT_VERBOSE и CURLOPT_STDERR установлены

[Dimonchik]

да, загадочка, а можешь пригласить эксперта? Ипатьев очень толковый в этих вопросах, давай пару дней подождем, и если не помогут - разберемся

ты пока разгадай загадку с CURLOPT_VERBOSE 1

[Александр Маджугин]

Dimonchik, короче оказалось что клиентский сертификат и ключ к нему надо было извлечь из файла certfile.pfx и использовать их.
После чего всё заработало. Фактически проблема была в неверной информации предоставленной партнером. Спасибо за помощь.