php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78414 TLS handshake fails when the certificate chain has more than 2 certificates
Submitted: 2019-08-14 10:09 UTC Modified: 2025-02-06 14:37 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:1 of 2 (50.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: romain at thouvenin dot pro Assigned: bukka (profile)
Status: Not a bug Package: OpenSSL related
PHP Version: 7.1.31 OS: Ubuntu 16.04
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: romain at thouvenin dot pro
New email:
PHP Version: OS:

 

 [2019-08-14 10:09 UTC] romain at thouvenin dot pro
Description:
------------
Using the test code below, I am able to open a SSL connection to a RabbitMQ server if the cert file has only 2 certificates (the client certificate and one intermediate certificate) but not if it contains the full chain of certificates (client cert, 3 intermediates and the root) provided by the CA (my use case is a wildcard certificate provided by Sectigo).

The problem might be related to some implementation detail of RabbitMQ (software written in Erlang) because I am able to connect to a `openssl s_server` with the full chain. But at the same time, I am also able to connect to the RabbitMQ server with the full chain from a `openssl s_client` and from a Ruby client. 
To recap:

 PHP client (fullchain)  -> RabbitMQ         ===> KO!
 PHP client (shortchain) -> RabbitMQ         ===> OK
 PHP client (fullchain)  -> openssl s_server ===> OK
 openssl s_client (full) -> RabbitMQ         ===> OK
 Ruby client (fullchain) -> RabbitMQ         ===> OK

So whatever this implementation detail might be, other clients are able to handle it.



Test script:
---------------
<?php

$context = stream_context_create([
    'ssl' => [
        'local_cert' => 'full-chain.pem',
        'local_pk' => 'key.pem',
    ],
]);

$errno = NULL;
$errstr = NULL;
$sock = stream_socket_client(
    'tcp://rabbitmq.domain.tld:5671',
    $errno,
    $errstr,
    3,
    STREAM_CLIENT_CONNECT,
    $context
);

stream_set_blocking($sock, true);
stream_socket_enable_crypto($sock, true, STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT);

Expected result:
----------------
No output.

I should be able to use the full chain since the server may not have the intermediate certificates in its trusted store.

Actual result:
--------------
PHP Warning:  stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages:
error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure


There is no SSL handshake-related output in the server logs

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2025-02-06 14:37 UTC] bukka@php.net
-Status: Open +Status: Not a bug -Assigned To: +Assigned To: bukka
 [2025-02-06 14:37 UTC] bukka@php.net
Apology for long delay.

I have been trying to experiment with this and even setup RabbitMQ with custom certs and was not able to recreate this.

I don't think this has actually anything to do with RabbitMQ. The thing is that the example is wrong because local_pk and local_cert are used only for PHP server with STREAM_SERVER_LISTEN (local_pk is for private key and local_cert is for the cert chain). For the client there are INI setting `openssl.cafile` and `openssl.capath` instead.

It's strange that it's failing if you specify the full-chain.pem. I tried to recreate with my full and short chain and just was not able to see any problem.


Anyway if you are still experiencing the issue or have some further notes, please create a new GitHub issue ideally with some cert chain that I can use to recreate it. I will close this as not a bug.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Thu Mar 20 16:01:29 2025 UTC