CentOS PHP локон не может вести переговоры приемлемый набор параметров безопасности

Question

На Ubuntu 14.04.3 этот код работает отлично:

$url_login = "https://test.example.com/login.do"; 

$cert_file = '/var/www/html/test/cert.pem'; 
$ssl_key = '/var/www/html/test/cert_private.pem'; 

$post_fields = 'userAction=1&cancelReason=&cancelType=&account=&memoType=&userText=&userid=99999999&password=xxxxxxxxxxxxxxxx'; 

$ch = curl_init(); 

$options = array( 
    CURLOPT_RETURNTRANSFER => 1, 
    CURLOPT_HEADER   => 1, 
    CURLOPT_FOLLOWLOCATION => 1, 
    CURLOPT_SSL_VERIFYHOST => 0, 
    CURLOPT_SSL_VERIFYPEER => 0, 

    CURLOPT_USERAGENT => 'Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)', 
    CURLOPT_VERBOSE  => 0, 
    CURLOPT_URL => $url_login , 

    CURLOPT_SSLCERT => $cert_file , 
    CURLOPT_SSLCERTTYPE, 'PEM', 
    CURLOPT_SSLKEY => $ssl_key, 

    CURLOPT_COOKIESESSION => 1, 

    CURLOPT_POST => true, 
    CURLOPT_POSTFIELDS => $post_fields 
); 

curl_setopt_array($ch , $options); 

$output = curl_exec($ch); 

РНР на Ubuntu использует локон с OpenSSL.

На Centos 7, если не удается с:

Curl Error : SSL peer was unable to negotiate an acceptable set of security parameters. 

локон здесь с НСС.

«cert.pem» содержит только сертификат клиента с сертификатной цепочкой, а «cert_private.pem» содержит закрытый ключ, а не пароль. (----- НАЧАТЬ ЧАСТИЧНЫЙ КЛЮЧ RSA -----).

Как я могу заставить вышеуказанный PHP-код работать с обоими? openssl и nss реализации curl?

Answer 1

Как об исправлении:

CURLOPT_SSLCERTTYPE, 'PEM', 

в

CURLOPT_SSLCERTTYPE => 'PEM', 

?

Answer 2

Я также сталкивался с этой проблемой, используя аутентификацию сертификата клиента с помощью nss, в то время как openssl отлично работает.

После долгих испытаний, это то, что я установил с сервером, который мы пытаемся связаться:

• завиток с использованием TLS v1.2 (по умолчанию в некоторых случаях) с сертификатом клиента не удается
• зависание с использованием TLS v1.2 с сертификатом клиента, требуемым сервером, но не используемым клиентом, успешно соединяется. Однако клиент не аутентифицирован.
• завиток с использованием TLS v1.0 с сертификатом клиента успешно

выше происходит независимо от шифра, как правило, мы используем rsa_aes_256_cbc_sha_256.

Быстрый обходной путь, чтобы заставить TLS v1.0:

CURLOPT_SSLVERSION => 4, 

Очевидно, что это не является идеальным, и ваш сервер может не поддерживать его.

Другой вариант - скомпилировать curl с openssl или даже GnuTLS (хотя я не тестировал последний) вместо nss. Опять же, это может быть не вариант.

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

Просто для справки, это полное сообщение об ошибке с помощью локон в командной строке:

* NSS error -12227 (SSL_ERROR_HANDSHAKE_FAILURE_ALERT) 
* SSL peer was unable to negotiate an acceptable set of security parameters. 
* Closing connection 0 
curl: (35) SSL peer was unable to negotiate an acceptable set of security parameters. 

Update 2015-11-24: Дальнейшее тестирование с Wireshark и ssltap показывает начальное рукопожатие преуспевает и соединение доходит до клиента, отправляющего ChangeCipherSpec, за которым следует его зашифрованное сообщение «Закончено».

Затем сервер должен расшифровать сообщение «Закончено» клиента, проверить хэш и MAC и ответить своим собственным зашифрованным сообщением «Закончено». Вместо этого сервер отвечает «handshake_failure» на этом этапе.

Это должно дать представление о том, где NSS не работает.

Chrome, Openssl и Charles Proxy могут аутентифицироваться с использованием сертификата клиента. Firefox (с использованием NSS) и завиток (с NSS) в этот момент не работают.

Обновление 2015-11-27: Дополнительная информация, предоставленная оперативной группой сервера, предполагает, что это может быть проблемой с сервером, не соответствующим требованиям. Проблема возникает только при использовании TLS 1.2 при определенных обстоятельствах. Это объясняет, почему некоторые библиотеки SSL, такие как OpenSSL, достаточно гибки, чтобы обойти это.

NSS может быть более строгим в соответствии с RFC. Я буду обновлять ответ, если/когда мы услышим больше от операционной команды, управляющей сервером.

Обновление 2017-01-25: Программное обеспечение веб-сервера и балансировочные устройства настраиваются на платежный шлюз конкретного банка. Мы недавно попробовали снова с новым клиентом, и теперь сервер работает как с Curl, построенным с помощью NSS, так и с OpenSSL, и больше не видит ошибки. Вкратце: обходным путем было использование другой библиотеки SSL и дождаться, когда разработчики исправят серверное программное обеспечение.