Re: mod_ssl and missing debug logging
On 29 May 2014, at 19:15, Graham Leggett minf...@sharp.fm wrote: LogLevel debug This is httpd v2.4.9. Unfortunately I am unable to help you with your error, however if you're trying to see more information, did you try to turn logging all the way up? LogLevel warn ssl:trace4 You could try even higher, up until trace8. It can ne quite noisy though and at some point it starts to get unusable.
Re: SSL and NPN
AFAIK OpenSSL does not support NPN out of the box either and obe would have to apply patches to the openssl-src in order to get NPN support. In OpenSSL 1.0.2 ALPN support has been added, though. I know it is easy to say and probably takes a lot of effort to implement, but wouldn't it be better to implement ALPN into httpd? On 28 Apr 2014, at 23:50, Jim Jagielski j...@jagunet.com wrote: Any reason to NOT include http://svn.apache.org/viewvc?view=revisionrevision=1332643 http://svn.apache.org/viewvc?view=revisionrevision=1487772 in 2.4??
Re: DH params and multiple certificates in one VHost
On Sat, Apr 19, 2014 at 8:19 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: The problem is the one pointed out by Steve in [2] already, I think: in the callback, SSL_get_privatekey() doesn't get us the private key which is actually used for the current connection, it only returns the current key i.e. the last one we configured. [2] https://mail-archives.apache.org/mod_mbox/httpd-dev/201402.mbox/%3c53057121.70...@opensslfoundation.com%3E Oh my, I must have completely forgotten about [2]. I am sorry, I didn't intend to reopen the same issue again. Like Steve said, the right thing would probably be that OpenSSL actually returns the private key used by the connection. (and apologies Harald, I got confused by the displayed name.)
Re: DH params and multiple certificates in one VHost
I successfully tested your attached patch with the latest 1.0.2 branch. The DH temp key now has the bit length of the used RSA key, regardless of SSLCertificate[Key]File order. Thank you, Kaspar. On Sat, Apr 19, 2014 at 9:11 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 19.04.2014 09:00, Falco Schwarz wrote: that OpenSSL actually returns the private key used by the connection. I just noticed [1], so you might want to try the attached (but untested) patch with 1.0.2-beta1 at least (beware of CVE-2014-0160 though, later versions preferred). Kaspar [1] https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=58b86e4235cd420f607819727d372af9f7a80224
DH params and multiple certificates in one VHost
As of httpd-2.4.7 the strength of DH temp keys is determined by the private key's bit length. I recently noticed the following behavior (using httpd-2.4.9 and openssl-1.0.2-beta2-dev): I am using multiple certificates for one VHost (ECC and RSA): SSLCertificateFile conf/ssl/example.org.ecc.cer SSLCertificateKeyFile conf/ssl/example.org.ecc.key SSLCertificateFile conf/ssl/example.org.rsa.cer SSLCertificateKeyFile conf/ssl/example.org.rsa.key If no DH params are specified in the first certificate, then the DH temp key is dependent on the last private key's bit length, instead of the first. So, if the ECC key is defined last, then the DH temp key will be 1024bit. If the RSA key is defined last, then the dh temp key will be 2048bit. From a users perspective it would be helpful if the DH temp key is always associated with the first certificate, regardless whether dh params are specified or not.
Re: DH params and multiple certificates in one VHost
On Fri, Apr 18, 2014 at 4:04 PM, Daniel Kahn Gillmor d...@fifthhorseman.netwrote: Looking at the code, it appears that ssl_callback_TmpDH() in modules/ssl/ssl_engine_kernel.c doesn't try to match ECC keys at all -- this probably needs to be updated. That was also my conclusion. It kinda makes sense that ECC keys are not matched, because there is no ECDSA+DH cipher. However ssl_callback_TmpDH() would either have to iterate through all private keys or just read the first key in order to be consistent with DH / ECDH params. Reindl, that is quite a good guide on how to setup certificates as of 2.4.9. Unfortunately you are describing what changed concerning certificate chains, I was talking about different algorithms for server authentication. I guess that was not exactly clear from my description, sorry. Either way, you cannot mix ECC and RSA keys in one file, you have to use multiple SSLCertificate[Key]File directives, see [1]. [1] http://httpd.apache.org/docs/2.4/en/mod/mod_ssl.html#sslcertificatefile
Re: [VOTE] Release Apache httpd 2.4.9 as GA
I do not know whether this is relevant to these errors, but in ssl_engine_kernel.c there is a comment about renegotiation with the perl test framework, line 806: /* XXX: Should replace setting state with SSL_renegotiate(ssl); * However, this causes failures in perl-framework currently, * perhaps pre-test if we have already negotiated? */ As of 2.4.9: (tested with OpenSSL 1.0.1f and 1.0.2-dev on Ubuntu) +1: SLES11 SP3 (32bit + 64bit), Ubuntu 13.10 (64bit) Falco On Fri, Mar 14, 2014 at 11:51 PM, Rainer Jung rainer.j...@kippdata.dewrote: On 14.03.2014 20:55, Plüm, Rüdiger, Vodafone Group wrote: -Ursprüngliche Nachricht- Von: Rainer Jung [mailto:rainer.j...@kippdata.de] Gesendet: Freitag, 14. März 2014 19:14 An: dev@httpd.apache.org Betreff: Re: [VOTE] Release Apache httpd 2.4.9 as GA On 13.03.2014 17:49, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.9 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.9 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. I get some test failures: t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 4) Failed tests: 3-4, 7-8 t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 2) Failed tests: 1-2 They happen during renegotiation. All parts should be using OpenSSL 1.0.1f. The requests end up with status 403 instead of 200. Which MPM? I think all of them, but definitly prefork. Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.8 as GA
On 11 Mar 2014, at 22:43, Steffen i...@apachelounge.com wrote: Builds fine on VC11 Win32, other flavors I try tomorrow Till now it runs fine, but get the following (run OpenSSL 1.0.1f): AH02559: The SSLCertificateChainFile directive (D:/servers/apacheS/conf/extra/httpd-ssl.conf:55) is deprecated, SSLCertificateFile should be used instead In the change log it is mentioned. By instruction of my certificate Certification Authority in conf: SSLCertificateChainFile conf/sub.class2.server.ca.cer SSLCACertificateFile conf/ca.cer Changed to: SSLCACertificateFile conf/sub.class2.server.ca.cer and as expected the warning is gone. Not sure if it has any consequences ? Instead of using SSLCACertificateFile, try using only SSLCertificateFile, as described here: http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile
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)
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)
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.
DH params and multiple certificates
As of svn.apache.org/r1527295 standardized DH parameters were added to mod_ssl. If I understand docs correctly, the bit length is based on the RSA/DSA key. With the recent support of multiple certificates per VirtualHost it is possible to use an RSA and ECC certificate. When using RSA and ECC, the DH bit length is dependent on the certificate configured last, so: - if ECC is configured last, 1024 bit DH params are set (minimum) - if RSA is configured last, the DH params depend on the private keys bit length (it works) The ECC certificate should in any way be skipped and not taken into account when setting DH params.
RE: mod_ssl-2.4.x-certkeyfile and OCSPStapling
I assume that you are using (a snapshot of) OpenSSL 1.0.2, is that correct? Yes, I was using a nightly snapshot of OpenSSL 1.0.2 Falco, can you confirm that applying one of the attached patches solves the problem for you? I have tested both patches separately, each of them solves the problem.
RE: SSL_CTX_get_{first,next}_certificate
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: mod_ssl-2.4.x-certkeyfile and OCSPStapling
I've just added this though in a slightly different way. Please test the next snapshot or just pull the latest 1.0.2 branch from git. Just pulled the latest 1.0.2 branch from git and recompiled OpenSSL / httpd. I cannot get Stapling to work, though. 2014-02-05 18:52:56 foo.bar [mpm_prefork|notice] AH00169: caught SIGTERM, shutting down 2014-02-05 18:53:01 foo.bar [ssl|error] AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate! 2014-02-05 18:53:01 foo.bar [ssl|error] AH: Unable to configure certificate foo.bar:443:0 for stapling 2014-02-05 18:53:01 foo.bar [ssl|error] AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate! 2014-02-05 18:53:01 foo.bar [ssl|error] AH: Unable to configure certificate foo.bar:443:0 for stapling + if (parg == NULL larg == 0) + *(STACK_OF(X509) **)parg = ctx-cert-key-chain; In theory, I cannot find an error in your change though. Kaspar, do you have an idea?
RE: mod_ssl-2.4.x-certkeyfile and OCSPStapling
Date: Wed, 5 Feb 2014 18:59:18 + From: shen...@opensslfoundation.com Ugh, messed up. Should be fixed now. Steve. Yes, it is working now. Thank you.
mod_ssl-2.4.x-certkeyfile and OCSPStapling
After playing around a bit more with this patch, I discovered that OCSPStapling cannot get the issuer certificate if you use only the SSLCertificateFile directive. It works if you specify SSLCertificateChainFile, though. Error only using SSLCertificateFile: 2014-02-04 19:07:13 [ssl|error] AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate! 2014-02-04 19:07:13 [ssl|error] AH02567: Unable to configure certificate foo.bar:443:0 for stapling
RE: mod_ssl-2.4.x-certkeyfile and OCSPStapling
the information for OCSP stapling is in the SSLCertificateChainFile by definition http://en.wikipedia.org/wiki/OCSP_stapling I know that. It cannot however be there if one is trying to deprecate this Directive as of https://svn.apache.org/r1553824
RE: Question regarding mod_ssl-2.4.x-certkeyfile
Date: Sat, 1 Feb 2014 08:13:59 +0100 From: httpd-dev.2...@velox.ch To: dev@httpd.apache.org Subject: Re: Question regarding mod_ssl-2.4.x-certkeyfile The attached patch, to be applied on top of mod_ssl-2.4.x-certkeyfile.diff, should take care of this problem. Thank you for your quick reply. Your provided patch indeed solves the problem. Everything now works just as expected. Falco
Question regarding mod_ssl-2.4.x-certkeyfile
I tested the patch altering the SSLCertificate* directives with httpd-2.4.x and OpenSSL-1.0.2-dev: https://people.apache.org/~kbrand/mod_ssl-2.4.x-certkeyfile.diff When putting certificate, CA and encrypted private key all in one file and using only the directive SSLCertificateFile, I encountered the following: there was no prompt for the passphrase and the errorlog showed this: [ssl|debug] AH01893: Configuring TLS extension handling [ssl|emerg] AH02573: Init: No private key specified for foo.bar:443:0 [ssl:emerg] [pid 28533] AH02312: Fatal error initialising mod_ssl, exiting. [ssl|emerg] AH02564: Failed to configure encrypted (?) private key foo.bar:443:0, check /opt/apache/conf/ssl/foo.bar.enc [ssl|emerg] SSL Library Error: error:0906A068:PEM routines:PEM_do_header:bad password read -- You entered an incorrect pass phrase!? [ssl|emerg] SSL Library Error: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib AH00016: Configuration Failed It worked perfectly fine if the private key is not encrypted. Specifying the private key using SSLCertificateKeyFile also worked and prompted for the passphrase. According to updated docs it should be possible to also put an encrypted private key alongside its certificate in one file using SSLCertificateFile. Am I missing something here?
Re: Event and atomics, round II
Our company would have run into the problem, though I knew it beforehand and avoided the problem on affected servers by switching back to prefork. We have setup our servers to build all shared mpms anyways, so this wasn’t a big problem. All the affected systems were in fact 32bit SLES (10 and 11). Is your workaround started in trunk complete? I would like to test if the problem is solved by the workaround on affected systems. On 16 Dec 2013, at 16:25, Jim Jagielski j...@jagunet.com wrote: Now that 2.4.7 has been out for awhile, I would have assumed that if people were hitting the atomics not working as expected error (using unsigned as signed), we would have started hearing about it... But, afaik, we haven't. So this leads me to the following discussion: should we stay with the workaround started in http://svn.apache.org/viewvc?view=revisionrevision=1545286 where we use an zero-point offset, or go back to the old method, or do something else?
RE: [RESULT] Re: [VOTE] Release Apache httpd 2.4.7 as GA
Jim I just now found out that the atomics problem for event also happens on Linux 32 Bits using GCC. At least it does on SuSE Linux Enterprise 10 32 Bits with platform standard gcc 4.1.0. I can confirm that SLES11 SP2+3 with 32 Bit is also affected. gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)
RE: ssl_die() and pool cleanup
Date: Sat, 23 Nov 2013 13:24:53 +0100
From: httpd-dev.2...@velox.ch
To: dev@httpd.apache.org
Subject: Re: ssl_die() and pool cleanup
Thanks Jeff and Yann for your reviews. Fixed all items as suggested,
except for these ones:
The various calls to ssl_server_import_cert() in ssl_init_server_certs()
need different rc checking than before. (Now ssl_server_import_cert() can
return a fatal error instead of just a boolean.)
(same for ssl_server_import_key())
Do you suggest that we should make these checks more strict? The current
code is just checking if at least one certificate/key was configured
successfully. My change so far was the following:
- if (!(have_rsa || have_dsa
+ if ((have_rsa != APR_SUCCESS) (have_dsa != APR_SUCCESS)
#ifdef HAVE_ECC
- || have_ecc
+ (have_ecc != APR_SUCCESS)
#endif
-)) {
+) {
ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(01910)
Oops, no KEYTYPES server certificate found
for '%s:%d'?!, s-server_hostname, s-port);
- ssl_die(s);
+ return ssl_die(s);
(I have simply rewritten the condition with De Morgan's law)
I'm fine with extending these checks (i.e., fail if any of the
ssl_server_import_cert or ssl_server_import_key calls fails), but this
can result in refusing to load existing configs.
Wouldn't that essentially remove the ability to configure a _default_:443
VirtualHost with an non-existing Servername, whose only purpose is to serve a
certificate for all other VirtualHosts?
e.g.
VirtualHost _default_:443
ServerName nonexistant.domain
SSLEngine On
SSLCertificateFile conf/ssl/www.example.com.cer
SSLCertificateKeyFile conf/ssl/www.example.com.key
SSLCertificateChainFile conf/ssl/www.example.com.ca
/VirtualHost
VirtualHost *:80 *:443
ServerName www.example.com
[...]
/VirtualHost
- If one sets www.example.com as ServerName of the _default_ VirtualHost, then
all requests are served by this vhost instead of the wildcard one.
- If mod_ssl would refuse to start the server because the _default_ vhost
ServerName does not match a certificate, then you would have to use a wildcard
certificate to make use of a _default_ vhost.
So, if the sanity check is skipped for the _default_ host, or there is a better
way to set the ServerName of the _default_ host, which I don't know yet, then
this wouldn't be affected.
RE: ssl_die() and pool cleanup
Date: Sat, 23 Nov 2013 08:18:14 -0500 Subject: Re: ssl_die() and pool cleanup From: cove...@gmail.com To: dev@httpd.apache.org So, if the sanity check is skipped for the _default_ host, or there is a better way to set the ServerName of the _default_ host, which I don't know yet, then this wouldn't be affected. I don't think any behavior should be based on _default_ vs. *. Your scenario probably works the same with the first VH as * simply because it's the first listed NVH. You are right, there should be no difference between _default_ vs. *. Yet, this does not change the fact, that you have to explicitly set a ServerName for the first VH, different to the CN in the certificate. Otherwise all requests would be served by the first VH, instead of the other ones. If mod_ssl would decline VH's with a nonmatching ServerName, then a configuration with a VirtualHost :80 :443 would be impossible without a wildcard certificate, at least to my knowledge.
RE: [VOTE] Release Apache httpd 2.4.7 as GA
[x] +1: Good to go - Versions used: apr-1.5.0, apr-util-1.5.3, openssl-1.0.1e, mod_fcgid-2.3.9, subversion-1.8.4 - builds with all modules (+ ssl, ldap, cache, proxy) - builds with all mpms as shared modules - built and tested on Ubuntu 13.10 - built and tested on SLES11 SP2+3 (32 and 64bit) - tested with all mpms From: j...@jagunet.com Subject: [VOTE] Release Apache httpd 2.4.7 as GA Date: Tue, 19 Nov 2013 12:45:02 -0500 To: dev@httpd.apache.org The pre-release test tarballs for Apache httpd 2.4.7 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.7 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience.
