php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68265 TLS/SSL connections do not honour the SubjectAltName within certificates
Submitted: 2014-10-19 12:57 UTC Modified: 2015-03-05 07:07 UTC
Votes:7
Avg. Score:4.9 ± 0.3
Reproduced:7 of 7 (100.0%)
Same Version:6 (85.7%)
Same OS:7 (100.0%)
From: ondrej@php.net Assigned: rdlowrey (profile)
Status: Closed Package: OpenSSL related
PHP Version: 5.6.2 OS: Linux
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: ondrej@php.net
New email:
PHP Version: OS:

 

 [2014-10-19 12:57 UTC] ondrej@php.net
Description:
------------
As reported here https://bugs.debian.org/759501

--cut here--
Dear Maintainer,

as PHP5.6 enabled peer verification by default I noticed that the
verification does not account the Subject Alternative Names within the
certificate. Upstream knows already a bug to this:
  Bug #55236	Can't open a connection via TLS

The problem get noticeable, when you try to connect to an SSL secured
service via fsockopen() and the hostname used to connect is differing
from the certificates Common Name. Take this example:

kandre@mainframe(pts/12) ~ % openssl s_client -starttls smtp -connect smtp.live.com:587 -CApath /etc/ssl/certs
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - G2
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = *.hotmail.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=*.hotmail.com
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---

Openssl is properly verifying the certificate and comes to the
conclusion, that the certificate CN=*.hotmail.com,X509v3 Subject
Alternative Name: DNS:*.hotmail.com, DNS:*.live.com, DNS:*.outlook.com,
DNS:hotmail.com is valid for smtp.live.com, but php fails to do so.

This could break any application that connects to a SSL secured service
where the connection hostname is not directly within the CommonName
field. From my perspective there is no workaround available except
changing the hostname to connect to into one that is mentioned in the
common name, which fails for the mentioned example, as Microsoft is
(seemingly) not offering any alternative hostname.

Thanks and kind regards,
Andre
--cut here--

The example cert can be retrieved by doing:

# openssl s_client -connect debs.ak-online.net:993

and copy the PEM output to a file (cert.pem).

The x509 content can be checked with:

# openssl x509 -text -in cert.pem -noout

and it has following names:
[...]
        Subject: C=DE, ST=SN, L=Dresden, O=Andre Kl\xE4rner IT-Dienstleistungen, OU=Hosting, CN=debs.ak-online.net
[...]
            X509v3 Subject Alternative Name: 
                DNS:debs.ak-online.be., DNS:debs.ak-online.net.

Cheers,
Ondrej


Test script:
---------------
wget http://www.cacert.org/certs/root.crt
wget http://www.cacert.org/certs/class3.crt
c_rehash .
cat > ssl-test-debs.php << EOF
<?php
# run with the following is you have hashed CAcert.org root certificates under /etc/ssl/certs
# -d openssl.capath=$(pwd)

foreach (array("ssl://debs.ak-online.be","ssl://debs.ak-online.net") as $host){
	echo "trying to connect to $host\n";
	$fp = fsockopen($host, 993, $errno, $errstr, 3);
	if (!$fp) {
	    echo "$errstr ($errno)\n";
	} else {
	    echo "connection succeeded\n";
	}
}
?>
EOF
php -d openssl.capath=$(pwd) ssl-test-debs.php 


Expected result:
----------------
connection succeeded
connection succeeded

Actual result:
--------------
trying to connect to ssl://debs.ak-online.be
PHP Warning:  fsockopen(): Peer certificate CN=`debs.ak-online.net' did not match expected CN=`debs.ak-online.be' in /tmp/php/ssl-test-debs.php on line 8
PHP Warning:  fsockopen(): Failed to enable crypto in /tmp/php/ssl-test-debs.php on line 8
PHP Warning:  fsockopen(): unable to connect to ssl://debs.ak-online.be:993 (Unknown error) in /tmp/php/ssl-test-debs.php on line 8
 (0)
trying to connect to ssl://debs.ak-online.net
connection succeeded


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-03-05 06:59 UTC] rdlowrey@php.net
Automatic comment on behalf of rdlowrey
Revision: http://git.php.net/?p=php-src.git;a=commit;h=65a9a5ca1283cf7ed59a5a14362fd6de0ad713b8
Log: Fixed bug #68265 (SAN match fails with trailing DNS dot)
 [2015-03-05 06:59 UTC] rdlowrey@php.net
-Status: Open +Status: Closed
 [2015-03-05 07:00 UTC] rdlowrey@php.net
Automatic comment on behalf of rdlowrey
Revision: http://git.php.net/?p=php-src.git;a=commit;h=65a9a5ca1283cf7ed59a5a14362fd6de0ad713b8
Log: Fixed bug #68265 (SAN match fails with trailing DNS dot)
 [2015-03-05 07:07 UTC] rdlowrey@php.net
-Assigned To: +Assigned To: rdlowrey
 [2015-03-05 07:07 UTC] rdlowrey@php.net
SAN fields are consulted for peer name verification as of 5.6.0. However, the problem here was actually that valid FQDN names ending in dots were not matched correctly during the SAN checks. This meant that the (valid) DNS names in your SAN entry were not correctly matched:

DNS:debs.ak-online.be., DNS:debs.ak-online.net.

^ The trailing dots were the issue.

Your transfers would have succeeded by simply assigning a manual "peer_name" => "debs.ak-online.net" setting (without the trailing dot). However, as the trailing period is technically correct this scenario is now accounted for when checking SAN names.

Thanks for the report.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 11:01:29 2024 UTC