Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

Re: svn commit: r1374214 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


httpd-dev.2012 at velox

Aug 18, 2012, 12:00 AM

Post #1 of 3 (374 views)
Permalink
Re: svn commit: r1374214 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c

On 17.8.12 13:59, jorton [at] apache wrote:
> Author: jorton
> Date: Fri Aug 17 11:59:45 2012
> New Revision: 1374214
>
> URL: http://svn.apache.org/viewvc?rev=1374214&view=rev
> Log:
> * modules/ssl/ssl_engine_init.c (ssl_init_proxy_certs): Fix test for
> missing decrypted private keys, and ensure that the keypair matches.

[...]

> @@ -1412,6 +1421,8 @@ static void ssl_init_proxy_certs(server_
> ssl_die(s);
> }
>
> + /* ### Why is all the following done? Why is it necessary or
> + * useful for the server to try to verify its own client cert? */

It's the somewhat surprising way to let OpenSSL build the chain of the
client cert, cf.

http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E620C5E.3050802 [at] opensslfoundation%3E
http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E61C3CE.4020500 [at] velox%3E
http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E625521.3000905 [at] opensslfoundation%3E

Kaspar


shenson at opensslfoundation

Aug 18, 2012, 3:56 AM

Post #2 of 3 (354 views)
Permalink
Re: svn commit: r1374214 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c [In reply to]

On 18/08/2012 08:00, Kaspar Brand wrote:
> On 17.8.12 13:59, jorton [at] apache wrote:
>> Author: jorton
>> Date: Fri Aug 17 11:59:45 2012
>> New Revision: 1374214
>>
>> URL: http://svn.apache.org/viewvc?rev=1374214&view=rev
>> Log:
>> * modules/ssl/ssl_engine_init.c (ssl_init_proxy_certs): Fix test for
>> missing decrypted private keys, and ensure that the keypair matches.
>
> [...]
>
>> @@ -1412,6 +1421,8 @@ static void ssl_init_proxy_certs(server_
>> ssl_die(s);
>> }
>>
>> + /* ### Why is all the following done? Why is it necessary or
>> + * useful for the server to try to verify its own client cert? */
>
> It's the somewhat surprising way to let OpenSSL build the chain of the
> client cert, cf.
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E620C5E.3050802 [at] opensslfoundation%3E
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E61C3CE.4020500 [at] velox%3E
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E625521.3000905 [at] opensslfoundation%3E
>

Though this quirk has been addressed in the current development version of
OpenSSL. It's now possible to set certificate chains on a per-type and per-SSL
context basis, instead of one per parent SSL_CTX. The functionality is likely to
be back ported to OpenSSL 1.0.2.

Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shenson [at] opensslfoundation


jorton at redhat

Aug 21, 2012, 2:31 AM

Post #3 of 3 (339 views)
Permalink
Re: svn commit: r1374214 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c [In reply to]

On Sat, Aug 18, 2012 at 09:00:00AM +0200, Kaspar Brand wrote:
> On 17.8.12 13:59, jorton [at] apache wrote:
> > @@ -1412,6 +1421,8 @@ static void ssl_init_proxy_certs(server_
> > ssl_die(s);
> > }
> >
> > + /* ### Why is all the following done? Why is it necessary or
> > + * useful for the server to try to verify its own client cert? */
>
> It's the somewhat surprising way to let OpenSSL build the chain of the
> client cert, cf.
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E620C5E.3050802 [at] opensslfoundation%3E
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E61C3CE.4020500 [at] velox%3E
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E625521.3000905 [at] opensslfoundation%3E

Ah, I see. Thanks Kaspar. I've updated the comment.

Regards, Joe

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.