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))
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
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))
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
Index: server/config.c
===
--- server/config.c (revision 1570984)
+++ server/config.c (working copy)
@@ -2195,7 +2195,7 @@ AP_CORE_DECLARE(const char *) ap_init_virtual_host
s-keep_alive = -1;
s-keep_alive_max = -1;
s-error_log = main_server-error_log;
-s-log.level = APLOG_UNSET;
+s-log.level = main_server-log.level;
s-log.module_levels = NULL;
/* useful default, otherwise we get a port of 0 on redirects */
s-port = main_server-port;
@@ -2237,7 +2237,7 @@ AP_DECLARE(struct ap_logconf *) ap_new_log_config(
AP_DECLARE(void) ap_merge_log_config(const struct ap_logconf *old_conf,
struct ap_logconf *new_conf)
{
-if (new_conf-level != APLOG_UNSET) {
+if (new_conf-level != APLOG_UNSET new_conf-level != DEFAULT_LOGLEVEL)
{
/* Setting the main loglevel resets all per-module log levels.
* I.e. if new-level has been set, we must ignore old-module_levels.
*/
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
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)
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)
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)
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)
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)
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)
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)
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)
On Tue, Feb 18, 2014 at 5:00 PM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
On 18/02/2014 20:06, Jeff Trawick wrote:
On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson
shen...@opensslfoundation.com
mailto:shen...@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
shen...@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)
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
shen...@opensslfoundation.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson
shen...@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
shen...@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)
On 19/02/2014 20:17, Jeff Trawick wrote:
On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson
shen...@opensslfoundation.com mailto:shen...@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
shen...@opensslfoundation.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
On 19/02/2014 20:17, Jeff Trawick wrote: On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson shen...@opensslfoundation.com mailto:shen...@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 shen...@opensslfoundation.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
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)
On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson
shen...@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
shen...@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)
On 18/02/2014 20:06, Jeff Trawick wrote:
On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson
shen...@opensslfoundation.com
mailto:shen...@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
shen...@opensslfoundation.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
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
shen...@opensslfoundation.com
