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.
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
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.
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
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
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
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
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
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
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.
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
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
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,
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);
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 =
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
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
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
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
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
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.
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
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
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
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
25 matches
Mail list logo
