Bug 47329 - SSLCADNRequest* & SSLCACertificate* silently do not work with 'Trusted' certificates
Summary: SSLCADNRequest* & SSLCACertificate* silently do not work with 'Trusted' certi...
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.2.6
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2009-06-07 07:13 UTC by tlhackque
Modified: 2018-11-07 21:09 UTC (History)
0 users



Attachments
Perl utility to create Client Request file from concatenated certificates (1.09 KB, text/plain)
2009-06-07 07:13 UTC, tlhackque
Details
test patch (353 bytes, patch)
2009-06-25 01:54 UTC, Joe Orton
Details | Diff
Certificates that exhibit this problem (2.51 KB, application/octet-stream)
2009-06-25 05:39 UTC, tlhackque
Details
Patch with better error report (498 bytes, patch)
2009-06-27 02:12 UTC, tlhackque
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description tlhackque 2009-06-07 07:13:51 UTC
Created attachment 23770 [details]
Perl utility to create Client Request file from concatenated certificates

The documentation for SSLCADNRequest* (and probably the SSL HOWTO) should indicate that TRUSTED certificates can not be used.

The documentation for SSLCACertificate* should indicate that while TRUSTED certificates can be used for verification by the server, they will not be sent to the client.

It turns out that my CA certificate is marked TRUSTED (e.g. begins with --BEGIN TRUSTED CERTIFICATE).  mod_ssl is perfectly happy to accept such certificates, but they are never sent to the client; openssl s_client will report "No certificate names sent".  There is no warning in any of the logfiles; the directive is silently ignored, although the files are read.

This is astoundingly confusing, since such certificates work perfectly well with SSLCACertificate* - they work as expected!

I think this is a documentation defficiency, although one might argue (after a lot of debugging) that a warning is deserved.

In general, I found the documentation of the SSL*Certificate* directives very confusing because it is so terse.  It would be helpful to emphasize that:

SSLCertificate* define the server's certificate & it's authentication chain

SSLCACertificate* define the Client's certificate issuers that are acceptable to the server.  Intermediate CAs are not required.

SSLCADNRequest* define the certificate issuers that the Client will be told to select, and should include any Intermediate CAs.

I wrote a small perl script that will convert a file containing any number of certificates into a format that's acceptable to SSLCADNRequestFile (and openssl!).  It removes any trust from each certificate, and includes the subject, issuer, and fingerprint as comments.  Perhaps it will be useful to someone else - it's attached to this report.
Comment 1 tlhackque 2009-06-07 07:57:51 UTC
I should have mentioned the environment:

OpenSSL/0.9.8b Fedora core 6
Comment 2 tlhackque 2009-06-24 08:29:35 UTC
The more I think about this, the more convinced I become that an error message (or a fix) is required.

The user is supplying a valid certificate that httpd is not able to process.  Httpd doesn't behave as expected.  

I lived without the correct information being sent to by clients' browsers for several years (yes, years) until I was finally able to get traces showing that the valid CA messages weren't being sent.  It was particularly confusing as an administrator, as when using SSLCACertificate*, the certificate was used correctly by httpd for one purpose, but not for another.  And of course, it only really impacts clients with more than one certificate to send...

While the documentation should be improved, I don't think that's sufficient.

Arguably this can be pushed upstream to OpenSSL, as HTTPD seems to just pass the filename along.  Or HTTPD can validate the certificate itself.  But someone, somewhere in the chain needs to detect this error, and httpd needs to ultimately report it.  Silently ignoring a valid certificate isn't acceptable.
Comment 3 Joe Orton 2009-06-25 01:54:22 UTC
Created attachment 23876 [details]
test patch

If you apply this patch, do you get errors logged when loading the bogus certs?
Comment 4 tlhackque 2009-06-25 05:34:03 UTC
Thanks, that's progress:

I commented-out SSLCADNRequestFile (leaving it to default to SSLCACertificateFile, which has the trust).

Now get these errors, and httpd doesn't start:

[Thu Jun 25 08:08:12 2009] [error] SSL Library Error: 151441516 error:0906D06C:PEM routines:PEM_read_bio:no start line Bad file contents or format - or even just a forgotten SSLCertificateKeyFile?
[Thu Jun 25 08:08:12 2009] [error] SSL Library Error: 151441516 error:0906D06C:PEM routines:PEM_read_bio:no start line Bad file contents or format - or even just a forgotten SSLCertificateKeyFile?

Not sure why I get two errors, but two is better than none!

If I re-enable SSLCADNRequestFile, neither error appears and httpd starts normally.

Would be great if it reported the directive & filename; ideal if also the config filename/locn.

I'll attach a .zip file with both certificates to facilitate testing.

Thanks for your help.  I'm sure this will save other people some pain & suffering!
Comment 5 tlhackque 2009-06-25 05:39:43 UTC
Created attachment 23878 [details]
Certificates that exhibit this problem

Here is the trusted certificate & the same certificate with trust removed (using the perl script previously attached.)  You can use these to validate your patch.


Archive:  47329.zip
 Length   Method    Size  Ratio   Date   Time   CRC-32    Name
--------  ------  ------- -----   ----   ----   ------    ----
    1996  Defl:N     1019  49%  09-04-07 09:36  1551832f  etc/pki/tls/ca/litts_net_ca-cert.pem
    2262  Defl:N     1150  49%  06-07-09 09:38  8916e5cb  etc/pki/tls/certs/litts_net_client_cas.pem
--------          -------  ---                            -------
    4258             2169  49%                            2 files

openssl x509 -noout -text -in /etc/pki/tls/ca/litts_net_ca-cert.pem -out t1.tmp
openssl x509 -noout -text -in /etc/pki/tls/certs/litts_net_client_cas.pem -out t2.tmp
diff t1.tmp t2.tmp
60,63d59
< Trusted Uses:
<   TLS Web Client Authentication, TLS Web Server Authentication, E-mail Protection
< No Rejected Uses.
< Alias: litts.net Primary Certification Authority
Comment 6 tlhackque 2009-06-25 13:59:03 UTC
(Follow-up to comment #4)
Two errors >are< expected - I have two virtual hosts in the server that I tested; a common included config file supplies these directives.

You've definitely caught the error; if the output were a bit cleaner (and the doc updated), I'd be very happy with the fix.

Thanks again for your efforts.
Comment 7 tlhackque 2009-06-27 02:12:26 UTC
Created attachment 23889 [details]
Patch with better error report

There may be a better way to code it, but here's a version of the test patch that reports the offending filename, as in:

[Sat Jun 27 04:59:39 2009] [error] Failed to load client CA certificate from /etc/pki/tls/ca/litts_net_ca-cert.pem, SSL library error:
[Sat Jun 27 04:59:39 2009] [error] SSL Library Error: 151441516 error:0906D06C:PEM routines:PEM_read_bio:no start line Bad file contents or format - or even just a forgotten SSLCertificateKeyFile?

I'm not sure how to get back to the config file/directive, but at least this gives the filename and why it's being loaded...
Comment 8 tlhackque 2011-03-31 16:05:41 UTC
In reviewing my local patches and SVN trunk, I noticed that nothing has been done about this.

Could someone at least check-in the last "test" patch?

It would be nice if the error could report the offending config file/directive, but the patch as-is (attached 2009-06-27 02:12 EDT) is a vast improvement over silent failures.

--thanks.
Comment 9 tlhackque 2011-03-31 21:17:40 UTC
Hmmm, it looks as though Bug 40312 is related.  A patch was proposed and checked-in there which only addresses 1/2 the cases, although analyzing it turned up problems with the patch here.  See my comments at https://issues.apache.org/bugzilla/show_bug.cgi?id=40312.

Note, however, that the documentation issue ("TRUSTED certificates can't be used") was not addressed there.
Comment 10 William A. Rowe Jr. 2018-11-07 21:09:39 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.