curl: проверка сертификата SSL | xnix

SSL == TLS. SSL это старое имя. Сейчас для этого понятия используется аббревиатура TLS.

Native SSL. Если libcurl была собрана с поддержкой Schannel или Secure Transport (библиотеки native SSL включены в Windows и Mac OS X), то это вас не касается. Смотрите далее описание, как традиционные подсистемы вашей OS обрабатывают сертификаты. Если нет уверенности, то запустите команду curl -V и просмотрите её результаты. Если строка версии говорит, что здесь присутствует Schannel, то поддержка Schannel встроена.

Зачем нужны сертификаты

Сертификаты это способ установки доверительных отношений. В вашем локальном хранилище сертификатов (local CA certificate store) имеются сертификаты из доверенных центров сертификации (Certificate Authorities, сокращенно CA), которые вы впоследствии используете для проверки достоверности сертификатов сервера, к которому обращаетесь. Они подписаны одним из доверенных серверов сертификации.

Каким центрам сертификации вы доверяете? Вы можете решить доверять одному и тому же набору компаний, которым доверяет ваша операционная система, или одному из известных браузеров. Это в основном доверие через кого-то, кому вы доверяете. Вы должны знать, что современные операционные системы и браузеры настроены доверять сотням компаний, и в последние годы некоторые центры сертификации были признаны не заслуживающими доверия.

Библиотека libcurl по умолчанию проверяет SSL сертификат пира (т. е. сервера, с которым устанавливается защищенное соединение). Это делается с использованием центра сертификации CA, который библиотека SSL может использовать, чтобы убедиться в достоверности сертификата пира.

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

Если же у сервера, к которому вы обращаетесь, установлен самоподписанный сертификат (self-signed certificate), если у вас не установили хранилище сертификатов CA, если сервер использует сертификат, подписанный CA, который не включен в ваше хранилище, или если вы сами знаете, что это нормальный сервер, с которого вам по-любому нужно скачать какой-то файл, то сделайте одно из следующего:

1. Укажите libcurl не проверять пир. Для libcurl такой запрет делается вызовом curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, FALSE);

В командной строке утилиты curl такой запрет достигается использованием опции -k / --insecure.

2. Получите сертификат CA, который может проверять удаленный сервер, и используйте соответствующий параметр, чтобы указать этот CA сертификат для проверки при подключении. Для хакеров libcurl: curl_easy_setopt(curl, CURLOPT_CAINFO, cacert);

3. Добавьте сертификат CA для вашего сервера в существующее хранилище CA сертификатов по умолчанию. Хранилище CA сертификатов по умолчанию можно поменять во время компиляции с помощью следующих опций конфигурации (configure):

--with-ca-bundle=FILE: используйте указанный файл как хранилище CA сертификатов. В этом файле сертификаты CA должны быть склеены в формате PEM.
--with-ca-path=PATH: используйте указанный путь в качестве хранилища CA сертификатов. Сертификаты CA должны быть сохранены в этой директории в виде отдельных PEM-файлов. Вам может понадобиться запустить c_rehash после добавления файлов в эту директорию.

Если не указан ни одна из этих опций, то configure попытается автоматически определить настройку. Также можно явно не устанавливать какое-либо хранилище по умолчанию, но полагаться вместо этого на встроенное хранилище по умолчанию, которое может предоставить библиотека криптографии. Этого можно добиться, если передать опе опции --without-ca-bundle и --without-ca-path в скрипт configure.

Если вы используете Internet Explorer, то вот один из способов распаковать сертификат CA для определенного сервера:

- Просмотрите сертификат двойным щелчком на навесной замочек.
- Узнайте, где хранится сертификат CA (Certificate -> Authority Information Access -> URL).
- Получите копию файла сертификата с помощью curl.
- Преобразуйте его из формата crt в формат PEM, используя утилиту OpenSSL:

- Добавьте outcert.pem в хранилище сертификатов CA, или используйте его отдельно, как описано ниже.

Если вы используете утилиту openssl, вот один из способов распаковки сертификата CA для определенного сервера:

- openssl s_client -showcerts -servername имясервера -connect имясервера:443 > cacert.pem
- Введите "quit" после нажатия на клавишу "ENTER".
- Сертификат будет находиться между маркерами между маркерами "BEGIN CERTIFICATE" и "END CERTIFICATE".
- Если вы хотите увидеть данные в сертификате, то можете выполнить команду: openssl x509 -inform PEM -in certfile -text -out certdata. Здесь certfile это сертификат, который вы распаковали из файла лога. Загляните в certdata.
- Если вы доверяете сертификату, то можете добавить его в ваше хранилище сертификатов CA, или использовать его отдельно, как было описано. Просто помните, что безопасность получится не лучше, чем факт получения вами сертификата.

4. Если вы используете утилиту командной строки curl, то можете указать ваш собственный файл сертификата CA путем установки переменной окружения CURL_CA_BUNDLE в выбранный вами путь.

Если вы используете утилиту curl в Windows, то curl будет искать файл сертификата CA с именем "curl-ca-bundle.crt" в этих директориях и в таком порядке:

- Директория приложения.
- Текущая рабочая директория.
- Системная директория Windows (например C:\windows\system32).
- Директория Windows (например C:\windows).
- Все директории, прописанные в переменной окружения %PATH%.

5. Получите лучший/другой/более новый пакет сертификата CA! Одна из опций - распаковать его из свежего обновленного браузера Firefox путем запуска 'make ca-bundle' в корневом каталоге сборки curl, или можно загрузить версию, которая была сгенерирована таким способом для вас, см. CA Extract [3].

Если пренебречь одним из вышеупомянутых методов при работе с сервером, использующим сертификат, который не подписан одним из сертификатов в установленном хранилище сертификатов CA, приведет к тому, что SSL при установке соединения (handshake) сообщит об ошибке ("certificate verify failed"), и SSL откажется от дальнейшего взаимодействия с этим сервером.

Если libcurl была собрана с поддержкой Schannel (native TLS-подсистема от Microsoft) или с поддержкой Secure Transport (native TLS-подсистема от Apple), то libcurl все еще будет выполнять верификацию сертификата пира, однако вместо того, чтобы использовать пакет сертификатов CA она будет использовать сертификаты, которые встроены в OS. Это те же самые сертификаты, которые появляются в панели управления свойствами Интернет (Internet Options в Windows) или приложении Keychain Access (в OS X). Все настраиваемые правила безопасности для сертификатов будут соблюдены.

Если не отключена проверка сертификатов пира, то Schannel запустит проверки CRL на сертификатах, а Secure Transport на iOS запустит для этого OCSP. Secure Transport на OS X запустит либо OCSP, либо CRL на сертификатах, если эти функции разрешены, и это поведение может быть настроена в свойствах Keychain Access.

Начиная с версии 7.52.0, curl может выполнять HTTPS для прокси отдельно от соединения с сервером. Это соединение TLS обрабатывается отдельно от подключения к серверу, поэтому вместо --insecure и --cacert для управления верификацией сертификата используются --proxy-insecure и --proxy-cacert. С этими опциями есть уверенность, что соединение TLS и доверие к прокси можно полностью отделить от TLS-соединения с сервером.