Опции контекста SSL

Опции контекста SSL — Список опций контекста SSL

Описание

Опции контекста для протоколов ssl:// и tls://

Опции

Имя узла. Если его значение не задано, тогда имя подставляется основываясь на имени хоста, использованного при открытии потока.

Требовать проверки используемого SSL-сертификата.

По умолчанию true .

Требовать проверки имени узла.

По умолчанию true .

Разрешить самоподписанные сертификаты. Требует verify_peer .

По умолчанию false

Расположение файла сертификата в локальной файловой системе, который следует использовать с опцией контекста verify_peer для проверки подлинности удалённого узла.

Если параметр cafile не определён или сертификат не найден, осуществляется поиск в директории, указанной в capath . Путь capath должен быть к корректной директории, содержащей сертификаты, имена которых являются хешем от поля subject, указанного в сертификате.

Путь к локальному сертификату в файловой системе. Это должен быть файл, закодированный в PEM, который содержит ваш сертификат и закрытый ключ. Он дополнительно может содержать открытый ключ эмитента. Закрытый ключ также может содержаться в отдельном файле, заданным local_pk .

Путь к локальному файлу с приватным ключом в случае отдельных файлов сертификата ( local_cert ) и приватного ключа.

Идентификационная фраза, с которой ваш файл local_cert был закодирован.

Прервать, если цепочка сертификата слишком длинная.

По умолчанию проверка отсутствует.

Устанавливает список доступных алгоритмов шифрования. Формат этой строки описан в разделе » шифры(1).

По умолчанию принимает значение DEFAULT .

Если установлено в true , то будет создана опция контекста peer_certificate , содержащая сертификат удалённого узла.

Если установлено в true , то будет создана опция контекста peer_certificate_chain , содержащая цепочку сертификатов.

Если установлено в true , то будет включено указание имени сервера. Включение SNI позволяет использовать разные сертификаты на одном и том же IP-адресе.

Отключает сжатие TLS, что помогает предотвратить атаки типа CRIME.

peer_fingerprint string | array

Прерваться, если дайджест сообщения не совпадает с указанным хешом.

Если указана строка ( string ), то её длина определяет какой алгоритм хеширования будет использован: «md5» (32) или «sha1» (40).

Если указан массив ( array ), то ключи определяют алгоритм хеширования, а каждое соответствующее значение является требуемым хешом.

Устанавливает уровень безопасности. Если не указан, используется стандартный уровень безопасности, указанный в библиотеке. Уровни безопасности описаны в » SSL_CTX_get_security_level(3).

Доступна с PHP 7.2.0 и OpenSSL 1.1.0.

Список изменений

Версия	Описание
7.2.0	Добавлен security_levels . Требуется OpenSSL >= 1.1.0.

Примечания

Замечание: Так как ssl:// — это нижележащий транспортный протокол для обёрток https:// и ftps:// , то любые опции контекста, которые применяются к ssl:// будут также применяться к https:// и ftps:// .

Замечание: Чтобы была доступна возможность указания имени сервера (SNI, Server Name Indication), PHP должен быть скомпилирован с OpenSSL 0.9.8j или более поздней. Используйте константу OPENSSL_TLSEXT_SERVER_NAME чтобы определить, поддерживается ли SNI.

Смотрите также

User Contributed Notes 7 notes

CN_match works contrary to intuitive thinking. I came across this when I was developing SSL server implemented in PHP. I stated (in code):

— do not allow self signed certs (works)
— verify peer certs against CA cert (works)
— verify the client’s CN against CN_match (does not work), like this:

stream_context_set_option($context, ‘ssl’, ‘CN_match’, ‘*.example.org’);

I presumed this would match any client with CN below .example.org domain.
Unfortunately this is NOT the case. The option above does not do that.

What it really does is this:
— it takes client’s CN and compares it to CN_match
— IF CLIENT’s CN CONTAINS AN ASTERISK like *.example.org, then it is matched against CN_match in wildcard matching fashion

Examples to illustrate behaviour:
(CNM = server’s CN_match)
(CCN = client’s CN)

— CNM=host.example.org, CCN=host.example.org —> OK
— CNM=host.example.org, CCN=*.example.org —> OK
— CNM=.example.org, CCN=*.example.org —> OK
— CNM=example.org, CCN=*.example.org —> ERROR

— CNM=*.example.org, CCN=host.example.org —> ERROR
— CNM=*.example.org, CCN=*.example.org —> OK

According to PHP sources I believe that the same applies if you are trying to act as Client and the server contains a wildcard certificate. If you set CN_match to myserver.example.org and server presents itself with *.example.org, the connection is allowed.

Everything above applies to PHP version 5.2.12.
I will supply a patch to support CN_match starting with asterisk.

Php ssl on windows

Для поддержки OpenSSL в PHP вам необходимо скомпилировать его с опцией —with-openssl[=DIR].

Также библиотека OpenSSL имеет дополнительные требования для нормальной работы во время исполнения. Самое главное, OpenSSL требуется доступ к генераторам случайных и псевдослучайных чисел; на большинстве систем Unix/Linux, это означает доступ к устройствам /dev/urandom или /dev/random .

Начиная с PHP 5.6.3, доступна опция конфигурации —with-system-ciphers, которая заставляет PHP использовать системный список шифров вместо жёстко заданного по умолчанию.

Замечание: Замечания для пользователей Win32

Для работы этого расширения системной переменной Windows PATH должны быть доступны DLL -файлы. Чтобы узнать как этого достичь, обратитесь к разделу FAQ «Как добавить мою директорию с PHP в переменную Windows PATH». Хотя копирование DLL-файлов из директории PHP в системную папку Windows также решает проблему (потому что системная директория по умолчанию находится в переменной PATH ), это не рекомендуется. Этому расширению требуются следующие файлы в переменной PATH : libeay32.dll , либо, начиная с OpenSSL 1.1, libcrypto-*.dll .

Дополнительно, если вы собираетесь использовать функции генерации ключей и подписи сертификатов, вам придётся установить корректный файл openssl.cnf в вашей системе. Мы включили демонстрационный конфигурационный файл в бинарную поставку под win32. Он лежит в директории extras/openssl .

PHP будет искать openssl.cnf , используя следующую логику:

• Переменная окружения OPENSSL_CONF . Если установлена, то должна содержать путь (включая имя файла) до конфигурационного файла.
• переменная окружения SSLEAY_CONF . Если установлена, то должна содержать путь (включая имя файла) до конфигурационного файла.
• Файл openssl.cnf будет искаться по стандартному пути для сертификатов, заданному при компиляции DLL. Обычно он задан как C:\Program Files\Common Files\SSL\openssl.cnf (x64) или C:\Program Files (x86)\Common Files\SSL\openssl.cnf (x86), или до PHP 7.4.0, как C:\usr\local\ssl\openssl.cnf .

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

Убедитесь, что непривилегированным пользователям не разрешено изменять openssl.cnf .

Список изменений

Версия	Описание
7.4.0	Конфигурационный путь OpenSSL был изменён с C:\usr\local\ssl на C:\Program Files\Common Files\SSL или C:\Program Files (x86)\Common Files\SSL , соответственно.

User Contributed Notes 8 notes

Having recently installed Apache2.2 with PHP 5.2.17 on my Windows 7 development machine, I want to pass along my findings about how to set things up to load the correct versions of the OpenSSL DLLs. Many people have posted elsewhere about the «DLL Hell» that results if the a wrong version is loaded.

First, install Apache 2.2 and check its operation, then download the Windows binaries for PHP from http://windows.php.net/download/. Note that according to the sidebar on that page the recommended version of PHP for use with Apache2 is currently 5.2.17, even though it is back level. Plus, this version comes with all the DLLs you need to use OpenSSL — no need to recompile as the old PHP man page suggests.

Having verified the PHP installation, turn on the OpenSSL support by uncommenting the line

in php.ini, which you will find in the PHP directory (I’ll assume you made that c:/PHP). Next check the location of php_openssl.dll, which you should find in c:/PHP/ext. Also in php.ini find the key extension_dir, and change its value to c:/php/ext. Next, put this location on the end of your PATH (there’s no need to reboot).

At this point, when you start Apache it will attempt to load php_openssl.dll, but if your setup is anything like mine you will see an error. I prefer to start Apache manually, and the error appears in a dialog box: «The ordinal 4114 could not be located in the dynamic link library LIBEAY32.dll». (I’m not sure whether you would get this message if you started Apache as a service). The Apache log also contains an error message saying that php_openssl.dll cannot be loaded, though that message doesn’t name libeay32.dll. Welcome to DLL Hell.

Libeay32.dll enters the picture because php_openssl.dll depends on it (and also on ssleay32.dll). What I think happens is that Apache first tries to load php_openssl.dll programmatically from the path specified by the extension_dir key. But then, the loading of the so-called dependent DLLs is left to Windows’ default mechanism. If Windows finds an incompatible version of a dependent DLL, you get the error.

So clearly the fix is to ensure that the correct version of libeay32.dll is loaded. On my machine, at least three other processes have loaded various versions of this same DLL. They include the Mozy backup client, Windows Explorer (because Mozy installs support in Explorer) and the OpenOffice suite. My machine is quite different in this respect from a dedicated server on which one probably wants as few extraneous processes as possible. Presumably on a server one can follow advice that suggests copying the dlls to the system32 directory, for example. But I’m not about to mess with my other programs by making system-wide changes.

So what to do? I didn’t find the available information on how Windows searches for DLLs to be very useful, mainly because I didn’t understand it. But it does say that the first place Windows looks is «The directory from which the application loaded.»

To cut to the chase, after a lot of experimentation I came to a key realization — «the application» is APACHE, not PHP. So I copied libeay32.dll to the Apache2.2/bin directory. Problem solved. No error messages and running phpinfo confirms that OpenSSL is present and enabled.

SSL не работает в PHP5.6 на Windows

Но оба возвращаются:

Как будто я не смог подключиться.

• Я пробовал PHP5.6 для x86 и PHP5.6 для x64
• Я использовал последний релиз в http://windows.php.net/download#php-5.6
• В Linux, кажется, работает нормально.
• Это происходит только с некоторыми полями, другие работают хорошо.
• PHP с CURL и SSL отлично работают в PHP5.6

Замечания: Странно в php5.4 работает отлично.

Ошибка в этой версии PHP?

Подробности:

Зарегистрированные потоковые сокеты: tcp, udp, ssl, sslv3, sslv2, tls

Компилятор: MSVC9 (Visual C ++ 2008)

Настроить команду (скомпилировать):

OpenSSL

Поддержка OpenSSL: включена

Версия библиотеки OpenSSL: OpenSSL 1.0.1c 10 мая 2012 г.

Версия заголовка OpenSSL: OpenSSL 1.0.1e 11 февраля 2013 г.

Зарегистрированные потоковые сокеты: tcp, udp, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2

Компилятор: MSVC11 (Visual C ++ 2012)

Настроить команду (скомпилировать):

OpenSSL

Поддержка OpenSSL: включена

Версия библиотеки OpenSSL: OpenSSL 1.0.1c 10 мая 2012 г.

Версия заголовка OpenSSL: OpenSSL 1.0.1t 3 мая 2016 г.

Конфигурация Openssl по умолчанию: c: /openssl-1.0.1c-X64/ssl/openssl.cnf

openssl.cafile: нет значения

openssl.capath: нет значения

Решение

Даже сертификаты PHP5.5 работают в PHP некоторым образом, но после изменения PHP5.6, как описано в: http://php.net/manual/en/migration56.openssl.php

Все зашифрованные клиентские потоки теперь включают одноранговую проверку по умолчанию. По умолчанию для проверки сертификата однорангового узла будет использоваться стандартная CA-пакет OpenSSL. В большинстве случаев не нужно вносить никаких изменений для взаимодействия с серверами с действительными сертификатами SSL, поскольку распространители обычно настраивают OpenSSL для использования известных хороших пакетов CA.

Пакет CA по умолчанию может быть переопределен на глобальном уровне путем установки openssl.cafile или же openssl.capath настройки конфигурации или для каждого отдельного запроса с использованием параметров контекста cafile или capath.

Хотя в целом это не рекомендуется, можно отключить проверку сертификата однорангового узла для запроса, установив для параметра контекста verify_peer значение FALSE и отключить проверку имени партнера, установив verify_peer_name контекстная опция для FALSE ,

fsockopen попробуйте разрешить соединение используя cafile, если php.ini не настроен, эта ошибка показа 0 , Вы можете попробовать два решения:

Настройте php.ini:

Вы можете скачать https://curl.haxx.se/ca/cacert.pem и настройте php.ini так:

Может быть, вам нужно перезагрузить Apache / Ngnix

Настройка во время исполнения:

Настроить fsockopen возможно, но вы можете использовать fopen + stream_context_create или используйте stream_socket_client ,

Примечание: иногда серверы блокируют такие функции, как fopen и file_get_contents URL-адресов доступа

Если вы решите отключить проверку по любой причине, вы можете просто сделать это:

Другие решения

Если значение вернулось в errno является 0 и функция вернулась FALSE , это признак того, что ошибка произошла до [системного уровня] connect() вызов. Скорее всего, это связано с проблемой инициализации сокета.