[openssl.org #2732] Bug: verification fails if muliple certification path (EV/Verisign)

[Steffen Ullrich via RT]

Hi, we get the following verification problem in our product, because
some servers like signin.ebay.de, comdirect.de or meine.deutsche-bank.de
add additional certicates to the chain, which are needed for some 
clients but not for others. Unfortunatly these are not minor companies
and all of the certificates are EV.
Tests done with various openssl versions from 0.9.7j up to 1.0.0a on 
OpenBSD and 1.0.0e and 1.0.1beta2 on Ubuntu 11.10.

Details:

The server sends 3 certificates (cert3, cert2 and cert1) while the client
has certB and/or certR as a trusted root certificate. 
certR signs cert1, while certB signs cert2 by using the same public key
as cert1.
The certificate hierarchy as a picture:

   -
   | Cert3 |
   |   |   |
   | Cert2 --
   |   |   ||
   | Cert1 ||
   |___|___||
   ||
   ||
 CertR -\ CertB -\
   ||   ||


cert3.pem 
  - ..CN=meine.deutsche-bank.de
  - SHA1 Fingerprint=6C:F2:11:14:DC:4F:77:95:1A:67:63:E1:64:2B:AE:2F:DF:33:EB:BC
cert2.pem 
  - ..CN=VeriSign Class 3 Extended Validation SSL SGC CA 
  - SHA1 Fingerprint=B1:80:39:89:98:31:F1:52:61:46:67:CF:23:FF:CE:A2:B0:E7:3D:AB
cert1.pem 
  - ..CN=VeriSign Class 3 Public Primary Certification Authority - G5
  - SHA1 Fingerprint=29:B7:3D:9F:75:01:B8:C0:AD:FD:5E:43:37:A3:90:D1:AD:20:5F:48

certB.pem 
  - ..CN=VeriSign Class 3 Public Primary Certification Authority - G5
  - SHA1 Fingerprint=4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5
  - this has the same public key as cert1, but is self signed
certR.pem 
  - C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
  - SHA1 Fingerprint=74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
  - this is very old but still valid, but MD2/RSA signed and thus probably not 
added in some products
(it's not in /etc/ssl/certs on Ubuntu 11.10)


The following tests will be done

- openssl verify -verbose -CAfile chain21.pem cert3.pem
  cat cert2.pem cert1.pem > chain21.pem
  will FAIL because neither certB nor certR are present and so no root is found

- openssl verify -verbose -CAfile chain21R.pem cert3.pem 
  cat cert2.pem cert1.pem certR.pem > chain21R.pem
  will SUCCEED because a complete hierarchy to the root can be found:
  cert3 - cert2 - cert1 - certR

- openssl verify -verbose -CAfile chain2B.pem cert3.pem
  cat cert2.pem certB.pem > chain2B.pem
  will SUCCEED because a complete hierarchy to the root can be found:
  cert3 - cert2 - certB

so far everything is like expected, but it gets interesting if we have
both cert1 and certB. Note that cert1 has the same public key as certB
so that both certificates sign cert2.

- openssl verify -verbose -CAfile chain21B.pem cert3.pem
  cat cert2.pem cert1.pem certB.pem > chain21B.pem
  The expected thing is, that it will succeed because it can verify
  cert3 - cert2 - cert B and just ignore cert1.
  But it FAILs because it tries cert3 - cert2 - cert1 - .. and then it
  is missing certR

- openssl verify -verbose -CAfile chain2B1.pem cert3.pem
  cat cert2.pem certB.pem cert1.pem > chain2B1.pem
  same certificates as last test, but this time certB is before cert1.
  I would expect, that the order does not matter, but this SUCCEEDs 
  because of cert3 - cert2 - certB and it ignores cert1

And this is where the bug is: one should expect, that it ignores an
the unneeded cert1 in both cases, but the behavior depends on the order
of the certicates in the chain.

The bug causes konqueror (using openssl) to fail on certificate check,
while Chrome and firefox (using NSS) succeed. At least FF seems to 
have certR too, but uses certB, probably because the trust chain is
shorter.  Opera on Linux and MSIE8 on Windows XP succeed too, also using 
certB and not certR for verification.

A similar problem was already reported, but w/o response:
http://rt.openssl.org/Ticket/Display.html?id=2634
and maybe http://rt.openssl.org/Ticket/Display.html?id=1851
is also related.

If you need more information or tests please let me know.

Regards,
Steffen Ullrich

-- 
GeNUA Gesellschaft für Netzwerk - und Unix-Administration mbH
Domagkstr. 7, D-85551 Kirchheim. http://www.genua.de
Tel: (089) 99 19 50-0, Fax: (089) 99 10 50 - 999

Geschäftsführer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht München HRB 98238

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
57:bf:fb:03:fb:2c:46:d4:e1:9e:ce:e0:d7:43:7f:13
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification 
Authority
Validity
Not Before: Nov  8 00:00:00 2006 GMT
Not After : Nov  7 23:59:59 2021 GMT
Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 
VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary 
Certification Authority - G5
  

[openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient

[Steffen Ullrich via RT]

Hi,
in openssl 1.1 you add a new function X509_check_host, see also RT#2909. 
In the current implementation it is incomplete and also wrong. The current
reference to hostname checking should be RFC 6125, which describes the
recommended general behavior and also the behavior for different protocols.

- wrong: according to RFC 6125 section 7.2 only the leftmost label should be
  checked for wildcards, but you support also something like
  www.*.example.com (there is even a test for it).

- wrong: you match wildcards within IDNA labels (there is also a test for
  it), which is not allowed. While according to 
  http://rt.openssl.org/Ticket/Display.html?id=2909#txn-35213
  the IDNA handling could not be found in any standard, RFC 6125 section 7.2
  is actually quite clear about it.

- insufficient: you have a flag X509_CHECK_FLAG_NO_WILDCARDS to disable
  wldcard checking and a flag X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT to check
  the CN even if subject alternative names are present. That's not
  sufficient to describe the hostname checking which needs to be done for
  the various protocols:
  - http, xmpp, ftp (RFC2818, RFC3920, RFC4217, RFC6125):
- X509_CHECK_FLAG_NO_WILDCARDS should be false
- in theory X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT should be false too, but
  its behavior does not match whats required from the RFC: the current
  implementation does check CN if there are no subject alternative
  names, but it should check CN if the are no DNS subject alternative
  names. So if SAN sections contains only IP it should check CN too.
  - ldap (RFC4513)
- ldap only allows in subject alternative names something like
  *.foo.com, but not x*.foo.com like it is allowed with http and done
  with the current wildcards check
- it also should check the CN always, but does not allow wildcards in
  the CN
  - smtp, imap, pop3, nntp ... (RFC2595, RC4642, RFC5539...)
- these protocols don't allow x*.foo.com too, e.g only *.foo.com
- CN should be checked always and it allows wildcards too (*.foo.com not
  x*.foo.com)

  In the IO::Socket::SSL Perl-Module I've implemented the following ways to
  describe the behavior:
  - How wildcards can be matched inside subject alternative names:
wildcards_in_alt: 0|leftmost|anywhere
  0:no checking
  leftmost: *.foo.com but not x*.foo.com
  anywhere: x*.foo.com too
  - If CN should be checked at all:
check_cn: 0|when_only|always
  0: never check CN
  when_only: only check if no DNS names in subject alternative names
  always:always check CN too
  - How wildcards can be matched inside the CN:
wildcards_in_cn: 0|leftmost|anywhere

- probably useful: while no RFC currently forbids something like *.com you
  have a check to disallow wildcards in the two rightmost suffixes. I think
  it makes sense to have that, although it is not sufficient (e.g. *.co.uk
  should also not be allowed). But doing this 100% correct will be tricky,
  because there is currently no definition of correct behavior in this area:
  While chrome disallows *.co.uk firefox allows it.

Regards,
Steffen

-- 
genua
Gesellschaft fuer Netzwerk- und Unix-Administration mbH
Domagkstrasse 7, 85551 Kirchheim bei Muenchen
tel +49 89 991950-0, fax -999, www.genua.de
Geschaeftsfuehrer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht Muenchen HRB 98238

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org