You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2014/01/29 19:15:55 UTC

Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS

On 29 Jan 2014, at 16:24, kbrand@apache.org wrote:

> Author: kbrand
> Date: Wed Jan 29 16:24:43 2014
> New Revision: 1562500
> 
> URL: http://svn.apache.org/r1562500
> Log:
> propose SSLCertificate[Key]File/SSLCertificateChainFile overhaul for mod_ssl

Would it be possible to do the same for the SSLProxy* directives?

There are some confusing differences in behavior between the forward and reverse facing directives.

Regards,
Graham
--

Re: SSL_CTX_get_{first,next}_certificate

Posted by Kaspar Brand <ht...@velox.ch>.

On 05.02.2014 14:05, Kaspar Brand wrote:
> On 03.02.2014 12:21, Dr Stephen Henson wrote:
>> On 02/02/2014 13:45, Kaspar Brand wrote:
>>> Yes, this sounds like a useful extension - not only for the issue at
>>> hand (i.e. SSL_CONF and stapling initialisation), but as a general
>>> mechanism for retrieving all certificates of an SSL_CTX.
>>>
>>
>> Added now. The API is slightly different, but easy enough to use.
> 
> I have adapted the stapling init code in trunk to switch to this
> mechanism with r1564760 (just committed). Reviews appreciated, would
> afterwards propose for backport.

Steve, I just noticed that using SSL_CTX_set_current_cert became
broken with [1] and [2], respectively - SSL_CTX_get0_certificate
may now return bogus pointers (and we segfault when trying to
dereference them, worst case). Patch for ssl_cert.c attached.

Kaspar


[1] https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=358d352aa244b4f2ef655bccff6658d92d5ce03c

[2] https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=c3f5d3d93ac81c2866a739f1981d948e6aba1fde

Re: agent-based framework for httpd private keys

Posted by Reindl Harald <h....@thelounge.net>.

Am 09.02.2014 08:15, schrieb Kaspar Brand:
> On 07.02.2014 01:58, Daniel Kahn Gillmor wrote:
>> As part of the goal of dropping encrypted private key support, have you
>> considered using an agent-based framework for private keys?
> 
> I haven't, no, since an important aspect of that goal is to reduce
> complexity in code. Dropping ssl_load_encrypted_pkey and friends from
> trunk amounts to a reduction of about 5% of mod_ssl's ~15,000 LoC right now

may i notice as server-admin that i am not willing to run whatever agent
additional on headless machines and most admins out there do the same

first rule:  stop and disable anything
second rule: now enable the things you really need
third rule:  consider to replace software which pulls to much here

Re: agent-based framework for httpd private keys

Posted by Daniel Kahn Gillmor <dk...@fifthhorseman.net>.

On Sun 2014-02-09 02:15:37 -0500, Kaspar Brand wrote:
> On 07.02.2014 01:58, Daniel Kahn Gillmor wrote:
>> As part of the goal of dropping encrypted private key support, have you
>> considered using an agent-based framework for private keys?
>
> I haven't, no, since an important aspect of that goal is to reduce
> complexity in code. Dropping ssl_load_encrypted_pkey and friends from
> trunk amounts to a reduction of about 5% of mod_ssl's ~15,000 LoC right now.
>
>> Anyway, with some sort of agent-based approach, you could preserve
>> encrypted keys-on-disk (for Joe Orton's examples of admins with access
>> to full-machine backups, or secret-keys-on-NFS) while leaving apache
>> agnostic about the way the keys get *into* the agent.
>
> Putting the decrypted keys on a RAM disk (tmpfs etc.) is a much more
> straightforward way to achieve this, IMO, with the benefit of being able
> to rely on a well-established method for configuring private keys (and
> not having to introduce another non-standard layer for performing
> private key operations).

i think an agent-based approach (using a secret-key-holding agent in a
separate memory space) would have prevented the exposure of long-term
secret keys in the recent heartbleed attack [0].

While i appreciate that enabling an agent would probably lead to some
code complexity, an agent-based approach does achieve stronger
protection in some contexts than decrypted keys on a RAM disk.

I don't have time to write a patch any time soon for this, but i just
wanted to highlight that i think the idea still has merit.

Regards,

      --dkg

[0] http://heartbleed.com/

Re: agent-based framework for httpd private keys

Posted by Kaspar Brand <ht...@velox.ch>.

On 07.02.2014 01:58, Daniel Kahn Gillmor wrote:
> As part of the goal of dropping encrypted private key support, have you
> considered using an agent-based framework for private keys?

I haven't, no, since an important aspect of that goal is to reduce
complexity in code. Dropping ssl_load_encrypted_pkey and friends from
trunk amounts to a reduction of about 5% of mod_ssl's ~15,000 LoC right now.

> Anyway, with some sort of agent-based approach, you could preserve
> encrypted keys-on-disk (for Joe Orton's examples of admins with access
> to full-machine backups, or secret-keys-on-NFS) while leaving apache
> agnostic about the way the keys get *into* the agent.

Putting the decrypted keys on a RAM disk (tmpfs etc.) is a much more
straightforward way to achieve this, IMO, with the benefit of being able
to rely on a well-established method for configuring private keys (and
not having to introduce another non-standard layer for performing
private key operations).

Kaspar

agent-based framework for httpd private keys [was: Re: SSL_CTX_get_{first,next}_certificate]

Posted by Daniel Kahn Gillmor <dk...@fifthhorseman.net>.

On 02/06/2014 12:35 AM, Kaspar Brand wrote:
> On 05.02.2014 18:13, Falco Schwarz wrote:
>> Kaspar, I ran into another issue when using an encrypted private key and "SSLOpenSSLConfCmd PrivateKey".
>> Again it fails to load the encrypted private key with the following errors:
> 
> That's by design, see [1]. Eventually I'd like to drop support for
> encrypted private keys from trunk.

As part of the goal of dropping encrypted private key support, have you
considered using an agent-based framework for private keys?

As a point of reference, OpenSSH added agent-based host key support for
sshd on 2013-07-20.

tTe basic model is:

 0) there is a running agent that holds secret key material and listens
on a socket (unix-domain sockets are nice because of the possibility of
tight filesystem permission control)

 1) the daemon (httpd, sshd) knows how to talk to the agent, to request
a list of available keys, and to request signing or decryption
operations to be done by the keys.

 2) the agent has a set of rules that govern when and how to obey a
specific request for signing or decryption operations

 3) the sysadmin has an interface to load password-protected keys into
the agent.

You can also run the agent under a different user account than the web
server, so that a runaway web server process wouldn't have access to the
secret key material without some other privilege escalation.  And you
can commit to a very small-footprint agent, with less room for bugs and
exploits, as compared to the entire modular webserver.

PKCS#11 is one formalization of this approach (though i think that PKCS
#11's shared object interface itself is pretty problematic in today's
multi-core/multi-threaded/multi-process architectures).

Anyway, with some sort of agent-based approach, you could preserve
encrypted keys-on-disk (for Joe Orton's examples of admins with access
to full-machine backups, or secret-keys-on-NFS) while leaving apache
agnostic about the way the keys get *into* the agent.

	--dkg

Re: SSL_CTX_get_{first,next}_certificate

Posted by Kaspar Brand <ht...@velox.ch>.

On 05.02.2014 18:13, Falco Schwarz wrote:
> Kaspar, I ran into another issue when using an encrypted private key and "SSLOpenSSLConfCmd PrivateKey".
> Again it fails to load the encrypted private key with the following errors:

That's by design, see [1]. Eventually I'd like to drop support for
encrypted private keys from trunk.

Thanks for testing r1564760. I have integrated this into the
mod_ssl-2.4.x-certkeyfile-v3.diff backport proposal (see r1565083).

Kaspar

[1]
https://mail-archives.apache.org/mod_mbox/httpd-dev/201311.mbox/%3C52838765.8020401%40velox.ch%3E

RE: SSL_CTX_get_{first,next}_certificate

Posted by Falco Schwarz <hi...@falco.me>.

> I have adapted the stapling init code in trunk to switch to this
> mechanism with r1564760 (just committed). Reviews appreciated, would
> afterwards propose for backport.
>
> Kaspar

FWIW, r1564760 applies without error to 2.4.x and seems to work.
It reads the Stapling information from "SSLOpenSSLConfCmd Certificate".
The OCSP Stapling information is sent to the client and no errors are occuring.


Kaspar, I ran into another issue when using an encrypted private key and "SSLOpenSSLConfCmd PrivateKey".
Again it fails to load the encrypted private key with the following errors:

2014-02-05 18:02:24 foo.bar [ssl|emerg] AH02407: "SSLOpenSSLConfCmd PrivateKey /opt/apache/conf/ssl/foo.bar.key" failed for foo.bar:443
2014-02-05 18:02:24 foo.bar [ssl|emerg] SSL Library Error: error:0906A068:PEM routines:PEM_do_header:bad password read -- You entered an incorrect pass phrase!?
2014-02-05 18:02:24 foo.bar [ssl|emerg] SSL Library Error: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib
[Wed Feb 05 18:02:24.877145 2014] [ssl:emerg] [pid 26568] AH02312: Fatal error initialising mod_ssl, exiting.

Works fine with an unencrypted key, though. I do not know whether this is on OpenSSL's part or mod_ssl's.

Falco

Re: SSL_CTX_get_{first,next}_certificate

Posted by Kaspar Brand <ht...@velox.ch>.

On 03.02.2014 12:21, Dr Stephen Henson wrote:
> On 02/02/2014 13:45, Kaspar Brand wrote:
>> Yes, this sounds like a useful extension - not only for the issue at
>> hand (i.e. SSL_CONF and stapling initialisation), but as a general
>> mechanism for retrieving all certificates of an SSL_CTX.
>>
> 
> Added now. The API is slightly different, but easy enough to use.

I have adapted the stapling init code in trunk to switch to this
mechanism with r1564760 (just committed). Reviews appreciated, would
afterwards propose for backport.

Kaspar

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.

On 19/02/2014 20:17, Jeff Trawick wrote:
> On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson
> <shenson@opensslfoundation.com <ma...@opensslfoundation.com>> wrote:
> 
>     On 19/02/2014 18:37, Jeff Trawick wrote:
>     >
>     >
>     > I think this is the trick...
>     >
>     > +    rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
>     > +    while (rc) {
>     > +        x = SSL_CTX_get0_certificate(ctx);
>     > +        if (x) {
>     > +            chain = NULL;
>     > +            SSL_CTX_get0_chain_certs(ctx, &chain);
>     > +            if (chain) {
>     > +                for (i = 0; i < sk_X509_num(chain); i++) {
>     > +                    X509 *x = sk_X509_value(chain, i);
>     > +                    /* do something */
>     > +                }
>     > +            }
>     > +        }
>     > +        rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
>     > +    }
>     >
>     > I'm working on Certificate Transparency support for httpd; as part of
>     submitting
>     > server certs with any necessary intermediate certs to CT logs I wanted to
>     > extract them straight from the SSL_CTX so that it didn't matter how
>     exactly they
>     > got there/were configured.
>     >
> 
>     Unfortunately that wont work in all cases. There are several distinct ways CA
>     certificates can be configured.
> 
>     In OpenSSL versions before 1.0.2 two ways existed. These had origins way back to
>     the SSLeay days.
> 
>     One was a set of extra certificates which are shared amongst all the server
>     certificate types in an SSL_CTX. This is far from ideal because you could have
>     (for example) an RSA and a ECDSA certificate with different chains which you
>     couldn't configure using this method. It could also end up using the wrong chain
>     if the server is misconfigured. It also makes it impossible to have different
>     chains with different SSL structures sharing the same parent SSL_CTX.
>     On the plus side the set of certificates is configured only once and can be
>     retrieved by an application. I notice httpd can use this method.
> 
>     The second method is used in the absence of any extra certificates. An attempt
>     is made to build a complete chain using the normal certificate verification
>     routine and trust store. This is done on the fly on each incoming connection
>     which is inefficient. It also uses the same certificate store used for client
>     certificate verification (which might not be ideal). It does however have the
>     advantage that it can handle different chains for different certificate types.
>     I *think* httpd can use this method too as it's done pretty much automatically.
> 
>     In OpenSSL 1.0.2 this has been extended.
> 
>     One method is the one which you used above. This supports distinct chains per
>     certificate type and per-SSL structure.
> 
>     However for that to work it needs application support either explicitly by using
>     SSL_CTX_add0_chain_cert or via the use of SSL_CTX_use_cetificate_chain_file
>     which uses this transparently in OpenSSL 1.0.2. I just checked and  httpd
>     currently doesn't use either of these but an enhancement to tidy up certificate
>     handling by Kaspar Brand does use SSL_CTX_use_certificate_chain_file.
> 
> 
> I need to make sure I understood this...
> 
> Let's say I have OpenSSL 1.0.2 and httpd trunk.   httpd trunk has the (or
> "some") code to call SSL_CTX_use_certificate_chain_file.  The code I posted
> above will do the right thing, correct?
> 

It also has some code that can call SSL_CTX_add_extra_chain_cert for which the
above wont work.

> If I have OpenSSL 1.0.2 but httpd 2.4.x, there's no code to
> call SSL_CTX_use_certificate_chain_file, so the code I posted won't work.
> 

Correct.

> 
>     That means getting a method that works in all cases is problematical.
> 
>     You can use SSL_CTX_get_extra_chain_certs which retrieves the chain for the
>     current certificate or (if it is empty) the per-ctx chain.
> 
> 
> And this works with httpd 2.4.x, which doesn't have the call to
> SSL_CTX_use_certificate_chain_file?
>  

It also works with trunk where is call SSL_CTX_add_extra_chain_cert. So IMHO
that's the best strategy.

Not that you can get duplicate certificates using any of the techniques as the
same CA might issue more than one server certificate.

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

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.

On 19/02/2014 20:17, Jeff Trawick wrote:
> On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson
> <shenson@opensslfoundation.com <ma...@opensslfoundation.com>> wrote:
> 
>     That works for two cases above. If however the on the fly chain building is
>     performed it will fail.
> 
> 
> Perhaps this is naive, but it may be reasonable for now to require that the log
> have access to the certificates required to perform the same "on the fly" chain
> building as the server, in the case where a chain is not configured.
> 

That sort of relates to a separate(ish) mechanism in 1.0.2.

I've never been happy with the "on the fly" chain building. It's inefficient
(building the chain on every connection), has no error mechanism if the chain
cannot be completely built (which would be useful as an error indication:
missing intermediate CA certificates in server configuration often cause
problems) and it uses the verification store (which is also used for client
authentication).

I'd be happy if httpd moved to a more robust mechanism.

In OpenSSL 1.0.2 there is a technique which might be usable here. You can set a
separate chain store which is only used for chain building. You can also make an
explicit call to SSL_CTX_build_cert_chain and it will build the chain internally
for the current certificate and store it for later use.

So to handle this typically you'd set up the chain store, call
SSL_CTX_built_cert_chain once on every configured certificate and return an
error condition on failure. The SSL_CTX would then have the chain set up
correctly for each configured certificate in the correct order with no way
misconfiguration could get it wrong.

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

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Jeff Trawick <tr...@gmail.com>.

On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson <
shenson@opensslfoundation.com> wrote:

> On 19/02/2014 18:37, Jeff Trawick wrote:
> >
> >
> > I think this is the trick...
> >
> > +    rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
> > +    while (rc) {
> > +        x = SSL_CTX_get0_certificate(ctx);
> > +        if (x) {
> > +            chain = NULL;
> > +            SSL_CTX_get0_chain_certs(ctx, &chain);
> > +            if (chain) {
> > +                for (i = 0; i < sk_X509_num(chain); i++) {
> > +                    X509 *x = sk_X509_value(chain, i);
> > +                    /* do something */
> > +                }
> > +            }
> > +        }
> > +        rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
> > +    }
> >
> > I'm working on Certificate Transparency support for httpd; as part of
> submitting
> > server certs with any necessary intermediate certs to CT logs I wanted to
> > extract them straight from the SSL_CTX so that it didn't matter how
> exactly they
> > got there/were configured.
> >
>
> Unfortunately that wont work in all cases. There are several distinct ways
> CA
> certificates can be configured.
>
> In OpenSSL versions before 1.0.2 two ways existed. These had origins way
> back to
> the SSLeay days.
>
> One was a set of extra certificates which are shared amongst all the server
> certificate types in an SSL_CTX. This is far from ideal because you could
> have
> (for example) an RSA and a ECDSA certificate with different chains which
> you
> couldn't configure using this method. It could also end up using the wrong
> chain
> if the server is misconfigured. It also makes it impossible to have
> different
> chains with different SSL structures sharing the same parent SSL_CTX.
> On the plus side the set of certificates is configured only once and can be
> retrieved by an application. I notice httpd can use this method.
>
> The second method is used in the absence of any extra certificates. An
> attempt
> is made to build a complete chain using the normal certificate verification
> routine and trust store. This is done on the fly on each incoming
> connection
> which is inefficient. It also uses the same certificate store used for
> client
> certificate verification (which might not be ideal). It does however have
> the
> advantage that it can handle different chains for different certificate
> types.
> I *think* httpd can use this method too as it's done pretty much
> automatically.
>
> In OpenSSL 1.0.2 this has been extended.
>
> One method is the one which you used above. This supports distinct chains
> per
> certificate type and per-SSL structure.
>
> However for that to work it needs application support either explicitly by
> using
> SSL_CTX_add0_chain_cert or via the use of SSL_CTX_use_cetificate_chain_file
> which uses this transparently in OpenSSL 1.0.2. I just checked and  httpd
> currently doesn't use either of these but an enhancement to tidy up
> certificate
> handling by Kaspar Brand does use SSL_CTX_use_certificate_chain_file.
>

I need to make sure I understood this...

Let's say I have OpenSSL 1.0.2 and httpd trunk.   httpd trunk has the (or
"some") code to call SSL_CTX_use_certificate_chain_file.  The code I posted
above will do the right thing, correct?

If I have OpenSSL 1.0.2 but httpd 2.4.x, there's no code to
call SSL_CTX_use_certificate_chain_file, so the code I posted won't work.


> That means getting a method that works in all cases is problematical.
>
> You can use SSL_CTX_get_extra_chain_certs which retrieves the chain for the
> current certificate or (if it is empty) the per-ctx chain.
>

And this works with httpd 2.4.x, which doesn't have the call to
SSL_CTX_use_certificate_chain_file?


>
> That works for two cases above. If however the on the fly chain building is
> performed it will fail.
>

Perhaps this is naive, but it may be reasonable for now to require that the
log have access to the certificates required to perform the same "on the
fly" chain building as the server, in the case where a chain is not
configured.

--/--

Thanks!


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



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: LogLevel inheritance/merging for VirtualHost in 2.4.x (Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS))

Posted by Kaspar Brand <ht...@velox.ch>.

On 23.02.2014 09:03, Kaspar Brand wrote:
> On 22.02.2014 19:17, Falco Schwarz wrote:
>> Kaspar, I switched back to your version and realized, that the directive SSLCertificateChainFile was always used in a VirtualHost.
>>
>> If the directive is in server scope, the warning is written correctly. 		 	   		  
> 
> Yes, that's the underlying issue which changing cmd->server to NULL in
> the ap_log_error actually uncovers: it's a somewhat (at least IMO)
> unfortunate side effect of how the LogLevel for a new VirtualHost is
> inherited/merged from the global LogLevel directive, or more
> specifically, the order in which it happens.

For the record: I have now committed your suggested change (switching
from cmd->server to NULL) in r1676085, as it turned out to be the most
appropriate fix for this specific case - and does not have unwanted side
effects either. Proposed for backport to 2.4.x in r1676086.

Kaspar

Re: LogLevel inheritance/merging for VirtualHost in 2.4.x

Posted by Kaspar Brand <ht...@velox.ch>.

On 23.02.2014 09:03, Kaspar Brand wrote:
> Yes, that's the underlying issue which changing cmd->server to NULL in
> the ap_log_error actually uncovers: it's a somewhat (at least IMO)
> unfortunate side effect of how the LogLevel for a new VirtualHost is
> inherited/merged from the global LogLevel directive, or more
> specifically, the order in which it happens.
> 
> If you insert "LogLevel warn" (or higher) in the VirtualHost block
> *before* any SSLCertificateChainFile directive, then you'll see the
> vhost-scope warnings on stderr (or in the log on reloads) as well.
> 
> One potential fix could consist of the attached patch for
> server/config.c, though I'm not sure if it doesn't have unwanted side
> effects, either (cf. r1024427 as to why it was last changed into the
> opposite direction).

After another look at this, an better solution might be the attached
patch - any opinions/insights from people who are more familiar with the
logging stuff than me?

Kaspar

LogLevel inheritance/merging for VirtualHost in 2.4.x (Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS))

Posted by Kaspar Brand <ht...@velox.ch>.

On 22.02.2014 19:17, Falco Schwarz wrote:
> Kaspar, I switched back to your version and realized, that the directive SSLCertificateChainFile was always used in a VirtualHost.
> 
> If the directive is in server scope, the warning is written correctly. 		 	   		  

Yes, that's the underlying issue which changing cmd->server to NULL in
the ap_log_error actually uncovers: it's a somewhat (at least IMO)
unfortunate side effect of how the LogLevel for a new VirtualHost is
inherited/merged from the global LogLevel directive, or more
specifically, the order in which it happens.

If you insert "LogLevel warn" (or higher) in the VirtualHost block
*before* any SSLCertificateChainFile directive, then you'll see the
vhost-scope warnings on stderr (or in the log on reloads) as well.

One potential fix could consist of the attached patch for
server/config.c, though I'm not sure if it doesn't have unwanted side
effects, either (cf. r1024427 as to why it was last changed into the
opposite direction). I guess sf is the expert on this, so I'm hoping for
his views on this. Note that config.c:ap_merge_log_config() is only part
of 2.4.x, i.e. with 2.2.x, the situation is different.

Kaspar

RE: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Falco Schwarz <hi...@falco.me>.

Kaspar, I switched back to your version and realized, that the directive SSLCertificateChainFile was always used in a VirtualHost.

If the directive is in server scope, the warning is written correctly.

RE: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Falco Schwarz <hi...@falco.me>.

> Date: Sat, 22 Feb 2014 15:16:27 +0100
> The only explanation I can imagine then is that your mod_ssl.so / httpd
> binary does not include the complete mod_ssl-2.4.x-certkeyfile-v3.diff
> patch. Does "strings mod_ssl.so | grep AH02559" show any output?
>
> Kaspar
 
Unfortunately yes. I checked out a fresh 2.4.x copy and reapplied the patch, just to make sure. This line is in mod_ssl.so:
AH02559: The SSLCertificateChainFile directive (%s:%d) is deprecated, SSLCertificateFile should be used instead
The Warning does not get logged, though.
 
If I change modules/ssl/ssl_engine_config.c like this, the warning is shown in STDERR:
 
--- ssl_engine_config.c 2014-02-22 15:41:46.116497925 +0100
+++ ssl_engine_config2.c        2014-02-22 15:49:07.560507617 +0100
@@ -795,7 +795,7 @@
     SSLSrvConfigRec *sc = mySrvConfig(cmd->server);
     const char *err;
 
-    ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_STARTUP, 0, cmd->server,
+    ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_STARTUP, 0, NULL,
                  APLOGNO(02559)
                  "The SSLCertificateChainFile directive (%s:%d) is deprecated, "
                  "SSLCertificateFile should be used instead",
 
Though it is then shown on stopping, starting, config checking. 
That is why I thought there might be an error regarding cmd->server with ap_log_error.

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Kaspar Brand <ht...@velox.ch>.

On 22.02.2014 11:27, Falco Schwarz wrote:
> Yes, for testing I am currently using these directives (without comment):
> 
> SSLCertificateFile      conf/ssl/foo.bar.cer    # leaf only
> SSLCertificateKeyFile   conf/ssl/foo.bar.key    # key only
> SSLCertificateChainFile conf/ssl/foo.bar.ca     # chain only 		 	   		  

The only explanation I can imagine then is that your mod_ssl.so / httpd
binary does not include the complete mod_ssl-2.4.x-certkeyfile-v3.diff
patch. Does "strings mod_ssl.so | grep AH02559" show any output?

Kaspar

RE: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Falco Schwarz <hi...@falco.me>.

> Date: Sat, 22 Feb 2014 11:22:14 +0100
> Does your current config still include an SSLCertificateChainFile directive?
>
> Kaspar

Yes, for testing I am currently using these directives (without comment):

SSLCertificateFile      conf/ssl/foo.bar.cer    # leaf only
SSLCertificateKeyFile   conf/ssl/foo.bar.key    # key only
SSLCertificateChainFile conf/ssl/foo.bar.ca     # chain only

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Kaspar Brand <ht...@velox.ch>.

On 22.02.2014 11:06, Falco Schwarz wrote:
> Perhaps I am missing something here, but if it is printed to stderr I should see it in the console when starting, right? Because I am unable to see it anywhere.
> 
> Even when reloading or restarting it is not written to the error log.
> It does not show up with -t either. Any clues?

Does your current config still include an SSLCertificateChainFile directive?

Kaspar

RE: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Falco Schwarz <hi...@falco.me>.

Perhaps I am missing something here, but if it is printed to stderr I should see it in the console when starting, right? Because I am unable to see it anywhere.

Even when reloading or restarting it is not written to the error log.
It does not show up with -t either. Any clues?

> Date: Sat, 22 Feb 2014 10:31:54 +0100
> It's printed to stderr, as ssl_cmd_SSLCertificateChainFile is executed
> before any ErrorLog files have been opened (when reloading with SIGHUP
> or SIGUSR1, you'll see them in the error log). My primary goal was that
> these warnings would be shown on the console when the config is checked
> with -t, that's why I put them into ssl_engine_config.c.
>
> Kaspar

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Kaspar Brand <ht...@velox.ch>.

On 20.02.2014 21:37, Falco Schwarz wrote:
> As I read through the changed code I found a smaller issue with the deprecation warning of SSLCertificateChainFile:
> 
> + ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_STARTUP, 0, cmd->server,
> + APLOGNO(02559)
> + "The SSLCertificateChainFile directive (%s:%d) is deprecated, "
> + "SSLCertificateFile should be used instead",
> + cmd->directive->filename, cmd->directive->line_num);
> 
> There seems to be an error related to this change, I guess in cmd->server?
> This warning is never logged. 		 	   		  

It's printed to stderr, as ssl_cmd_SSLCertificateChainFile is executed
before any ErrorLog files have been opened (when reloading with SIGHUP
or SIGUSR1, you'll see them in the error log). My primary goal was that
these warnings would be shown on the console when the config is checked
with -t, that's why I put them into ssl_engine_config.c.

Kaspar

RE: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Falco Schwarz <hi...@falco.me>.

> Date: Thu, 20 Feb 2014 07:35:01 +0100
> That's part of the mod_ssl backport proposal currently in 2.4.x/STATUS.
> (A previous version had a vote from jorton, but I'm not sure if he's
> willing to refresh that... perhaps people feel uneasy with getting this
> into 2.4.8? A third vote would be needed in any case.)
> 
> Kaspar

As far as testing the functionality, the patch works as advertised. 
It would be great if this gets reviewed and added.


As I read through the changed code I found a smaller issue with the deprecation warning of SSLCertificateChainFile:

+ ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_STARTUP, 0, cmd->server,
+ APLOGNO(02559)
+ "The SSLCertificateChainFile directive (%s:%d) is deprecated, "
+ "SSLCertificateFile should be used instead",
+ cmd->directive->filename, cmd->directive->line_num);

There seems to be an error related to this change, I guess in cmd->server?
This warning is never logged.

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Kaspar Brand <ht...@velox.ch>.

On 19.02.2014 20:23, Dr Stephen Henson wrote:
> However for that to work it needs application support either explicitly by using
> SSL_CTX_add0_chain_cert or via the use of SSL_CTX_use_cetificate_chain_file
> which uses this transparently in OpenSSL 1.0.2. I just checked and  httpd
> currently doesn't use either of these but an enhancement to tidy up certificate
> handling by Kaspar Brand does use SSL_CTX_use_certificate_chain_file.

That's part of the mod_ssl backport proposal currently in 2.4.x/STATUS.
(A previous version had a vote from jorton, but I'm not sure if he's
willing to refresh that... perhaps people feel uneasy with getting this
into 2.4.8? A third vote would be needed in any case.)

Kaspar

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.

On 19/02/2014 18:37, Jeff Trawick wrote:
> 
> 
> I think this is the trick...
> 
> +    rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
> +    while (rc) {
> +        x = SSL_CTX_get0_certificate(ctx);
> +        if (x) {
> +            chain = NULL;
> +            SSL_CTX_get0_chain_certs(ctx, &chain);
> +            if (chain) {
> +                for (i = 0; i < sk_X509_num(chain); i++) {
> +                    X509 *x = sk_X509_value(chain, i);
> +                    /* do something */
> +                }
> +            }
> +        }
> +        rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
> +    }
>  
> I'm working on Certificate Transparency support for httpd; as part of submitting
> server certs with any necessary intermediate certs to CT logs I wanted to
> extract them straight from the SSL_CTX so that it didn't matter how exactly they
> got there/were configured.
> 

Unfortunately that wont work in all cases. There are several distinct ways CA
certificates can be configured.

In OpenSSL versions before 1.0.2 two ways existed. These had origins way back to
the SSLeay days.

One was a set of extra certificates which are shared amongst all the server
certificate types in an SSL_CTX. This is far from ideal because you could have
(for example) an RSA and a ECDSA certificate with different chains which you
couldn't configure using this method. It could also end up using the wrong chain
if the server is misconfigured. It also makes it impossible to have different
chains with different SSL structures sharing the same parent SSL_CTX.
On the plus side the set of certificates is configured only once and can be
retrieved by an application. I notice httpd can use this method.

The second method is used in the absence of any extra certificates. An attempt
is made to build a complete chain using the normal certificate verification
routine and trust store. This is done on the fly on each incoming connection
which is inefficient. It also uses the same certificate store used for client
certificate verification (which might not be ideal). It does however have the
advantage that it can handle different chains for different certificate types.
I *think* httpd can use this method too as it's done pretty much automatically.

In OpenSSL 1.0.2 this has been extended.

One method is the one which you used above. This supports distinct chains per
certificate type and per-SSL structure.

However for that to work it needs application support either explicitly by using
SSL_CTX_add0_chain_cert or via the use of SSL_CTX_use_cetificate_chain_file
which uses this transparently in OpenSSL 1.0.2. I just checked and  httpd
currently doesn't use either of these but an enhancement to tidy up certificate
handling by Kaspar Brand does use SSL_CTX_use_certificate_chain_file.

That means getting a method that works in all cases is problematical.

You can use SSL_CTX_get_extra_chain_certs which retrieves the chain for the
current certificate or (if it is empty) the per-ctx chain.

That works for two cases above. If however the on the fly chain building is
performed it will fail.

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

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Jeff Trawick <tr...@gmail.com>.

On Tue, Feb 18, 2014 at 5:00 PM, Dr Stephen Henson <
shenson@opensslfoundation.com> wrote:

> On 18/02/2014 20:06, Jeff Trawick wrote:
> > On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson <
> shenson@opensslfoundation.com
> > <ma...@opensslfoundation.com>> wrote:
> >
> >     On 02/02/2014 13:45, Kaspar Brand wrote:
> >     > On 01.02.2014 14:37, Dr Stephen Henson wrote:
> >     >> I'm wondering how that could be avoided. Would a way to enumerate
> all
> >     >> certificates in an SSL_CTX structure in OpenSSL help? Something
> like
> >     >> SSL_CTX_get0_first_certificate() and
> SSL_CTX_get0_next_certificate().
> >     That would
> >     >> also set the current certificate at the same time in case
> applications
> >     wanted to
> >     >> inspect the private key or chain.
> >     >
> >     > Yes, this sounds like a useful extension - not only for the issue
> at
> >     > hand (i.e. SSL_CONF and stapling initialisation), but as a general
> >     > mechanism for retrieving all certificates of an SSL_CTX.
> >     >
> >
> >     Added now. The API is slightly different, but easy enough to use.
> >
> >     To iterate over all certificates in an SSL_CTX something like this
> will do the
> >     trick:
> >
> >     X509 *x;
> >     int rv;
> >     rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
> >     while (rv)
> >             {
> >             X509 *x = SSL_CTX_get0_certificate(ctx);
> >             rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
> >             }
> >
> >     Steve.
> >
> >
> > Is the leaf certificate always first?  (And/or maybe it is up to how the
> admin
> > configures it and it only works if the leaf is first?)
> >
> > The APIs work this way with the OpenSSL 1.0.2 branch now?
> >
> > TIA!
> >
>
> An SSL_CTX can have multiple server certificates associated with it
> and the one used depends on the ciphersuite negotiated by the client.
>

Thanks, I had forgotten about that!


>
> The certificate you get from SSL_CTX_get0_certificate is the server
> certificate
> which will always be a leaf certificate. You need different APIs to get
> the rest
> of the chain (assuming one has been configured).
>

I think this is the trick...

+    rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
+    while (rc) {
+        x = SSL_CTX_get0_certificate(ctx);
+        if (x) {
+            chain = NULL;
+            SSL_CTX_get0_chain_certs(ctx, &chain);
+            if (chain) {
+                for (i = 0; i < sk_X509_num(chain); i++) {
+                    X509 *x = sk_X509_value(chain, i);
+                    /* do something */
+                }
+            }
+        }
+        rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
+    }

I'm working on Certificate Transparency support for httpd; as part of
submitting server certs with any necessary intermediate certs to CT logs I
wanted to extract them straight from the SSL_CTX so that it didn't matter
how exactly they got there/were configured.

Thanks again...


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



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.

On 18/02/2014 20:06, Jeff Trawick wrote:
> On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson <shenson@opensslfoundation.com
> <ma...@opensslfoundation.com>> wrote:
> 
>     On 02/02/2014 13:45, Kaspar Brand wrote:
>     > On 01.02.2014 14:37, Dr Stephen Henson wrote:
>     >> I'm wondering how that could be avoided. Would a way to enumerate all
>     >> certificates in an SSL_CTX structure in OpenSSL help? Something like
>     >> SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate().
>     That would
>     >> also set the current certificate at the same time in case applications
>     wanted to
>     >> inspect the private key or chain.
>     >
>     > Yes, this sounds like a useful extension - not only for the issue at
>     > hand (i.e. SSL_CONF and stapling initialisation), but as a general
>     > mechanism for retrieving all certificates of an SSL_CTX.
>     >
> 
>     Added now. The API is slightly different, but easy enough to use.
> 
>     To iterate over all certificates in an SSL_CTX something like this will do the
>     trick:
> 
>     X509 *x;
>     int rv;
>     rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
>     while (rv)
>             {
>             X509 *x = SSL_CTX_get0_certificate(ctx);
>             rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
>             }
> 
>     Steve.
> 
> 
> Is the leaf certificate always first?  (And/or maybe it is up to how the admin
> configures it and it only works if the leaf is first?)
> 
> The APIs work this way with the OpenSSL 1.0.2 branch now?
> 
> TIA!
>  

An SSL_CTX can have multiple server certificates associated with it
and the one used depends on the ciphersuite negotiated by the client.

The certificate you get from SSL_CTX_get0_certificate is the server certificate
which will always be a leaf certificate. You need different APIs to get the rest
of the chain (assuming one has been configured).

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

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Jeff Trawick <tr...@gmail.com>.

On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson <
shenson@opensslfoundation.com> wrote:

> On 02/02/2014 13:45, Kaspar Brand wrote:
> > On 01.02.2014 14:37, Dr Stephen Henson wrote:
> >> I'm wondering how that could be avoided. Would a way to enumerate all
> >> certificates in an SSL_CTX structure in OpenSSL help? Something like
> >> SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate().
> That would
> >> also set the current certificate at the same time in case applications
> wanted to
> >> inspect the private key or chain.
> >
> > Yes, this sounds like a useful extension - not only for the issue at
> > hand (i.e. SSL_CONF and stapling initialisation), but as a general
> > mechanism for retrieving all certificates of an SSL_CTX.
> >
>
> Added now. The API is slightly different, but easy enough to use.
>
> To iterate over all certificates in an SSL_CTX something like this will do
> the
> trick:
>
> X509 *x;
> int rv;
> rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
> while (rv)
>         {
>         X509 *x = SSL_CTX_get0_certificate(ctx);
>         rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
>         }
>
> Steve.
>

Is the leaf certificate always first?  (And/or maybe it is up to how the
admin configures it and it only works if the leaf is first?)

The APIs work this way with the OpenSSL 1.0.2 branch now?

TIA!


> --
> Dr Stephen Henson. OpenSSL Software Foundation, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD 21710
> +1 877-673-6775
> shenson@opensslfoundation.com
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.

On 02/02/2014 13:45, Kaspar Brand wrote:
> On 01.02.2014 14:37, Dr Stephen Henson wrote:
>> I'm wondering how that could be avoided. Would a way to enumerate all
>> certificates in an SSL_CTX structure in OpenSSL help? Something like
>> SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate(). That would
>> also set the current certificate at the same time in case applications wanted to
>> inspect the private key or chain.
> 
> Yes, this sounds like a useful extension - not only for the issue at
> hand (i.e. SSL_CONF and stapling initialisation), but as a general
> mechanism for retrieving all certificates of an SSL_CTX.
> 

Added now. The API is slightly different, but easy enough to use.

To iterate over all certificates in an SSL_CTX something like this will do the
trick:

X509 *x;
int rv;
rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
while (rv)
	{
	X509 *x = SSL_CTX_get0_certificate(ctx);
	rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
	}

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

SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

Posted by Kaspar Brand <ht...@velox.ch>.

On 01.02.2014 14:37, Dr Stephen Henson wrote:
> I'm wondering how that could be avoided. Would a way to enumerate all
> certificates in an SSL_CTX structure in OpenSSL help? Something like
> SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate(). That would
> also set the current certificate at the same time in case applications wanted to
> inspect the private key or chain.

Yes, this sounds like a useful extension - not only for the issue at
hand (i.e. SSL_CONF and stapling initialisation), but as a general
mechanism for retrieving all certificates of an SSL_CTX.

Kaspar