Многие разработчики, сталкивающиеся с необходимостью настройки mTLS (взаимной аутентификации по сертификатам) при обмене данными с банками, рано или поздно сталкиваются с трудностями при работе с устаревшими компонентами Windows. Одной из самых частых и болезненных проблем является ошибка: «В сертификате клиента отсутствовали учетные данные». Давайте разберем, почему она возникает и как ее исправить.
Когда вы используете WinHttp.WinHttpRequest для отправки запросов, система Windows пытается выполнить аутентификацию, используя сертификат, установленный в хранилище. Однако сам по себе файл сертификата (в формате .crt или .cer) содержит только открытую часть и информацию о владельце. Для того чтобы банк «узнал» вас, необходимо подтвердить владение закрытым ключом.
Ошибка, с которой вы столкнулись, напрямую указывает на то, что объект WinHttp видит сертификат, но не может найти или связать с ним соответствующий закрытый ключ. Часто это происходит из-за того, что при установке в хранилище был импортирован только публичный сертификат, а закрытый ключ остался в отдельном файле.
Для того чтобы WinHttp мог успешно использовать сертификат для подписи запроса, необходимо сформировать единый контейнер в формате PKCS#12. Чаще всего это файлы с расширением .pfx или .p12. Для этой задачи мы воспользуемся утилитой openssl.
Certificate.crt), присланный банком, и файл вашего закрытого ключа (например, CertificateClient.key).openssl для «склеивания» этих файлов в один контейнер. Выполните в командной строке:
openssl.exe pkcs12 -export -in Certificate.crt -inkey CertificateClient.key -out Client.p12
После выполнения этой команды у вас появится файл Client.p12. Именно его необходимо импортировать в хранилище сертификатов Windows (в папку «Личное» или «My»). При импорте система запросит пароль (если вы его задали при экспорте) и предложит отметить ключ как экспортируемый — рекомендуем это сделать для удобства последующего администрирования.
После того как вы корректно установили сертификат, содержащий закрытый ключ, в системное хранилище, ваш код, использующий COMОбъект, должен начать работать. Рассмотрим пример правильного вызова:
Процедура ПроверитьСоединение()
WinHttp = Новый COMОбъект("WinHttp.WinHttpRequest.5.1");
// Указываем путь к сертификату в хранилище
// LOCAL_MACHINE\My - путь для установленного сертификата
WinHttp.SetClientCertificate("LOCAL_MACHINE\My\ВашеИмяСертификата");
// Настройки для игнорирования ошибок SSL, если это необходимо
WinHttp.Option(4, 13056);
WinHttp.Open("POST", "https://адрес.банка.ru", Ложь);
WinHttp.Send("ВашиДанные");
ТекстОтвета = WinHttp.ResponseText;
КонецПроцедуры
Важно понимать, что WinHttp.WinHttpRequest является морально устаревшим инструментом. В современных версиях платформы 1С (начиная с 8.3) рекомендуется уходить от прямой манипуляции системными хранилищами через COM в сторону нативных средств платформы. Мы рекомендуем рассмотреть использование класса ЗащищенноеСоединениеOpenSSL.
При использовании ЗащищенноеСоединениеOpenSSL вам не требуется устанавливать сертификаты в системное хранилище Windows. Вы можете загружать файл .pfx напрямую из файловой системы или из ХранилищаЗначений внутри 1С. Это значительно упрощает отладку, так как исключает влияние прав доступа системы и настроек CryptoAPI.
Основные выводы для успешной настройки:
PKCS#12.WinHttp может быть неэффективен. В таких случаях лучше использовать специализированные компоненты, такие как КриптоПро CSP, в связке с 1С:Библиотекой электронных подписей.Проанализировав данную ситуацию, мы видим, что основная причина заключалась в неправильной подготовке контейнера сертификата. Соблюдение порядка действий при экспорте в p12 позволяет успешно пройти этап аутентификации и получить ответ от сервера банка.