Re: The requested URL /as was not found on this server.
Thanks a ton Mark. It worked :) On Fri, Jul 10, 2015 at 6:18 PM, Mark Taylor mtt...@gmail.com wrote: I believe the issue is here: SetHandler example_module It may be the case that the string in request_rec.handler is set to the value from SetHandler in the conf. if (!r-handler || strcmp(r-handler, example-handler)) return (DECLINED); You might try: SetHandler example-handler Seems like the name from LoadModule is the symbol name in the .so, and used to reference the module, not any code within the module. -Mark On Fri, Jul 10, 2015 at 1:20 AM, Prakash Premkumar prakash.p...@gmail.com wrote: Hi, I am writing a simple apache module following the docs in https://httpd.apache.org/docs/2.4/developer/modguide.html#snippets Here's the module code: http://pastebin.com/T1TMfLgC Here's my httpd.conf file: http://pastebin.com/aZBWyNve When I access any URL like localhost/asd I get the following error Not Found The requested URL /asd was not found on this server. Can you please help me fix this ?
Re: test base line
Hi Stefan,
Am 09.07.2015 um 13:46 schrieb Stefan Eissing:
I need some help with establishing a test baseline. I checked out the test
framework from https://svn.apache.org/repos/asf/httpd/test/framework/trunk,
followed the README and ran the tests against a freshly installed 2.4.x in
/opt/httpd/2.4-plain. It did PASS with the default httpd.conf, but many tests
were skipped due to modules missing.
I tried enable some more modules like mod_ssl or mod_rewrite and all of these
attempts led to test failures and perl errors such as
t/security/CVE-2011-3368-rewrite.t .. 1/3 # Failed test 1 in
t/security/CVE-2011-3368-rewrite.t at line 13
Can't call method print on an undefined value at
t/security/CVE-2011-3368-rewrite.t line 19.
My perl is the default Ubuntu 14.04 perl 5.18.
Is this a failure on my part or is the system supposed to operate like this? I
am a bit confused...
I typically use the default config from fresh build I do with configure
flags --enable-modules=reallyall and --enable-load-all-modules.
I don't get failures as described by you above. I typically run the perl
framework with perl plus locally installed modules. To instal modules as
a normal user separate from the system installed perl I use local::lib.
The stuff I add is Bundle::ApacheTest and recent versions of
Test::Harness, Crypt::SSLeay, Net:SSLeay, IO::Socket::SSL,
LWP::Protocol::https, HTTP::DAV (plus whatever cpan automatically adds
as further dependencies). The list probably could be shortened, but
that's the cruft I accumulated over time. When building the HTTPS/SSL
parts one must be careful to use the same OpenSSL version that one uses
to build the web server. Sometimes this is a bit tricky.
The failure in line 19 you describe happens at the end of the following
snippet:
my $sock = Apache::TestRequest::vhost_socket();
ok $sock $sock-connected;
my $req = GET @.localhost/foobar.html HTTP/1.1\r\n.
Host: . Apache::TestRequest::hostport() . \r\n.
\r\n;
ok $sock-print($req);
So it seems $sock is not defined. And indeed the failure in line 13 is
the ok check in the second code line above. So the test could not
connect to the vhost.
Using t/TEST (try help or -help or -h to see the options) you can also
just start the web server configured for the tests without immediately
running them. You can then try to connect yourself.
You can also edit LogLevel in Apache-Test/lib/Apache/TestConfig.pm and
increase it before the perl Makefile.PL and the t/TEST to get more log
output.
Not likely but maybe your system openssl is used by perl and can't
connect to a vhost powered by some other OpenSSL that you build your web
server against?
The vhost_socket() used by the test is defined in
lib/Apache/TestRequest.pm as:
sub vhost_socket {
my $module = shift;
local $Apache::TestRequest::Module = $module if $module;
my $hostport = hostport(Apache::Test::config());
my($host, $port) = split ':', $hostport;
my(%args) = (PeerAddr = $host, PeerPort = $port);
if ($module and $module =~ /ssl/) {
require Net::SSL;
local $ENV{https_proxy} ||= ; #else uninitialized value in
Net/SSL.pm
return Net::SSL-new(%args, Timeout = UA_TIMEOUT);
}
else {
require IO::Socket;
return IO::Socket::INET-new(%args);
}
}
Maybe you can add some debug output to STDOUT there to see to which
socket it tries to connect and where it fails.
Finally: any locally active pieces of security software intercepting the
connect?
Regards,
Rainer
Re: Using UPN from subjectAltName with SSLUserName
On 29.06.2015 15:14, Jan Pazdziora wrote:
How about just passing char * and doing all the mapping logic
including possible OBJ_create in parse_otherName_value? My goal here
is to have all the hard work of determining the semantics isolated
in one place.
Please see patch attached.
You're right, an ASN1_OBJECT * as an argument for modssl_X509_getSAN
makes handling of otherName entries relatively awkward. In the attached
patch, I have switched to a string for specifying the requested
otherName form (similar to what you did in your patch).
OBJ_create adds new entries to a process-wide table, so instead of
checking for the presence of a specific entry at each request (in
parse_otherName_value), I consider it more appropriate and efficient to
do this only once, in ssl_init_Module.
Barring feedback against this approach (or the observation of bugs in
the implementation), I intend to commit it to trunk in the next few days
(including mod_ssl.xml changes and a CHANGES item).
Kaspar
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1690371)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -352,6 +352,11 @@ apr_status_t ssl_init_Module(apr_pool_t *p, apr_po
init_dh_params();
+if (OBJ_txt2nid(id-on-dnsSRV) == NID_undef) {
+(void)OBJ_create(1.3.6.1.5.5.7.8.7, id-on-dnsSRV,
+ SRVName otherName form);
+}
+
return OK;
}
@@ -1902,5 +1907,7 @@ apr_status_t ssl_init_ModuleKill(void *data)
free_dh_params();
+OBJ_cleanup();
+
return APR_SUCCESS;
}
Index: modules/ssl/ssl_util_ssl.c
===
--- modules/ssl/ssl_util_ssl.c (revision 1690371)
+++ modules/ssl/ssl_util_ssl.c (working copy)
@@ -252,19 +252,48 @@ char *modssl_X509_NAME_to_string(apr_pool_t *p, X5
return result;
}
+static void parse_otherName_value(apr_pool_t *p, ASN1_TYPE *value,
+ const char *onf, apr_array_header_t
**entries)
+{
+const char *str;
+int nid = onf ? OBJ_txt2nid(onf) : NID_undef;
+
+if (!value || (nid == NID_undef) || !*entries)
+ return;
+
+/*
+ * Currently supported otherName forms (values for onf):
+ * msUPN (1.3.6.1.4.1.311.20.2.3): Microsoft User Principal Name
+ * id-on-dnsSRV (1.3.6.1.5.5.7.8.7): SRVName, as specified in RFC 4985
+ */
+if ((nid == NID_ms_upn) (value-type == V_ASN1_UTF8STRING)
+(str = asn1_string_to_utf8(p, value-value.utf8string))) {
+APR_ARRAY_PUSH(*entries, const char *) = str;
+} else if (strEQ(onf, id-on-dnsSRV)
+ (value-type == V_ASN1_IA5STRING)
+ (str = asn1_string_to_utf8(p, value-value.ia5string))) {
+APR_ARRAY_PUSH(*entries, const char *) = str;
+}
+}
+
/*
* Return an array of subjectAltName entries of type type. If idx is -1,
* return all entries of the given type, otherwise return an array consisting
* of the n-th occurrence of that type only. Currently supported types:
* GEN_EMAIL (rfc822Name)
* GEN_DNS (dNSName)
+ * GEN_OTHERNAME (requires the otherName form [onf] argument to be supplied,
+ *see parse_otherName_value for the currently supported forms)
*/
-BOOL modssl_X509_getSAN(apr_pool_t *p, X509 *x509, int type, int idx,
-apr_array_header_t **entries)
+BOOL modssl_X509_getSAN(apr_pool_t *p, X509 *x509, int type, const char *onf,
+int idx, apr_array_header_t **entries)
{
STACK_OF(GENERAL_NAME) *names;
+int nid = onf ? OBJ_txt2nid(onf) : NID_undef;
-if (!x509 || (type GEN_OTHERNAME) || (type GEN_RID) || (idx -1) ||
+if (!x509 || (type GEN_OTHERNAME) ||
+((type == GEN_OTHERNAME) (nid == NID_undef)) ||
+(type GEN_RID) || (idx -1) ||
!(*entries = apr_array_make(p, 0, sizeof(char * {
*entries = NULL;
return FALSE;
@@ -277,33 +306,43 @@ char *modssl_X509_NAME_to_string(apr_pool_t *p, X5
for (i = 0; i sk_GENERAL_NAME_num(names); i++) {
name = sk_GENERAL_NAME_value(names, i);
-if (name-type == type) {
-if ((idx == -1) || (n == idx)) {
-switch (type) {
-case GEN_EMAIL:
-case GEN_DNS:
-utf8str = asn1_string_to_utf8(p, name-d.ia5);
-if (utf8str) {
-APR_ARRAY_PUSH(*entries, const char *) = utf8str;
-}
-break;
-default:
-/*
- * Not implemented right now:
- * GEN_OTHERNAME (otherName)
- * GEN_X400 (x400Address)
- * GEN_DIRNAME (directoryName)
- * GEN_EDIPARTY (ediPartyName)
-
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 01.07.2015 14:27, Ben Laurie wrote: On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote: The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable? It's unacceptable for at least two reasons: a) by default, an HTTP server is supposed to process *incoming* requests, not make accidental outgoing connections in addition (at least not unless it's explicitly instructed to do so); b) there's no statement in our license with an explicit caveat on such a side effect (when relying on our default settings, configuring a site with an SSL server certificate may result in unsolicited outgoing HTTP requests - and no, I do not want to see our license amended by things like that). I maintain my objection to uncommenting #SSLUseStapling On in our default config in httpd-ssl.conf.in - and for the record, also to changing code, be that in ssl_engine_config.c:modssl_ctx_init() or elsewhere. Those keen on enabling it by default on behalf of the users (because we know what is good for you) are free to lobby with the OS vendors to have their package defaults changed. Kaspar
[VOTE] Release 2.2.30 as GA?
The pre-release candidate tarballs of Apache httpd 2.2.30, can be found in; http://httpd.apache.org/dev/dist/ +/-1 [ ] Release 2.2.30 GA (apr 1.5.2, apr-util 1.5.4) Win32 src to follow shortly, vote to run through 14:30 GMT Tuesday.
Re: [VOTE] Release Apache httpd 2.4.16 as GA
On Sat, Jul 11, 2015 at 3:43 PM, Eric Covener cove...@gmail.com wrote: On Fri, Jul 10, 2015 at 4:33 PM, Jim Jagielski j...@jagunet.com wrote: [ ] +1: Good to go +1, 100% pass on AIX/xlc/ppc64. (and thanks for RM'ing!)
Re: [VOTE] Release Apache httpd 2.4.16 as GA
On Fri, Jul 10, 2015 at 4:33 PM, Jim Jagielski j...@jagunet.com wrote: [ ] +1: Good to go +1, 100% pass on AIX/xlc/ppc64.
Re: [VOTE] Release 2.2.30 as GA?
On Sat, Jul 11, 2015 at 10:29 AM, William A Rowe Jr wr...@rowe-clan.net wrote: The pre-release candidate tarballs of Apache httpd 2.2.30, can be found in; http://httpd.apache.org/dev/dist/ +/-1 [ ] Release 2.2.30 GA (apr 1.5.2, apr-util 1.5.4) Thanks for RM'ing +1, AIX/xlc/ppc64 Only failures in cgi.t (55-57) which seems to have been seen by others in the past
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
We can have a dialog about the best behavior of our default config. However... On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 01.07.2015 14:27, Ben Laurie wrote: On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote: The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable? It's unacceptable for at least two reasons: a) by default, an HTTP server is supposed to process *incoming* requests, not make accidental outgoing connections in addition (at least not unless it's explicitly instructed to do so); b) there's no statement in our license with an explicit caveat on such a side effect (when relying on our default settings, configuring a site with an SSL server certificate may result in unsolicited outgoing HTTP requests - and no, I do not want to see our license amended by things like that). Our License says nothing about accepting requests, either. Licenses don't express these mechanics. They define the terms for users to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the work and its derivatives, and the corresponding patent rights as well. A number of ASF works are servers. A number are clients. A number are both clients and servers. OCSP is hardly an accidental request, any more than the proxy module requests. And in forwarding requests to https proxy servers, (another side effect) verifying the OCSP identity of the connected server is hardly an unexpected side effect, it's a characteristic of the protocol (that backend *server* advertised OCSP validation - stapled or indirect, and that the *user* configured the certificate for OCSP validation). Third party OCSP validation is so problematic that OCSP stapling is a blindly obvious enhancement that will far offset the routing configuration issues it also inspires So your premise above is, well, outright silly. I maintain my objection to uncommenting #SSLUseStapling On in our default config in httpd-ssl.conf.in - and for the record, also to changing code, be that in ssl_engine_config.c:modssl_ctx_init() or elsewhere. Those keen on enabling it by default on behalf of the users (because we know what is good for you) are free to lobby with the OS vendors to have their package defaults changed. You are welcome to object, and I think Ben's reply here to your thoughts and observations, particularly your early one, since he is advocating for this change and this would move the dialog along to a conclusion. Contrawise, httpd project can do the 'right thing' from our perspective, and the downstream distributors can correspondingly disable it. Moreso, any enterprise so affected already is configuring httpd to their own organization's standards and policies. If you are suggesting we shouldn't change the compiled-in default, I can agree, POLS (Principal Of Least Surprise). If you are suggesting the default config shouldn't reflect the ability to efficiently handle OCSP by stapling, here I think we would disagree.
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On Sat, Jul 11, 2015 at 2:55 PM, William A Rowe Jr wr...@rowe-clan.net wrote: We can have a dialog about the best behavior of our default config. However... On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 01.07.2015 14:27, Ben Laurie wrote: On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote: The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable? It's unacceptable for at least two reasons: a) by default, an HTTP server is supposed to process *incoming* requests, not make accidental outgoing connections in addition (at least not unless it's explicitly instructed to do so); b) there's no statement in our license with an explicit caveat on such a side effect (when relying on our default settings, configuring a site with an SSL server certificate may result in unsolicited outgoing HTTP requests - and no, I do not want to see our license amended by things like that). Our License says nothing about accepting requests, either. Licenses don't express these mechanics. They define the terms for users to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the work and its derivatives, and the corresponding patent rights as well. A number of ASF works are servers. A number are clients. A number are both clients and servers. OCSP is hardly an accidental request, any more than the proxy module requests. And in forwarding requests to https proxy servers, (another side effect) verifying the OCSP identity of the connected server is hardly an unexpected side effect, it's a characteristic of the protocol (that backend *server* advertised OCSP validation - stapled or indirect, and that the *user* configured the certificate for OCSP validation). Third party OCSP validation is so problematic that OCSP stapling is a blindly obvious enhancement that will far offset the routing configuration issues it also inspires So your premise above is, well, outright silly. I maintain my objection to uncommenting #SSLUseStapling On in our default config in httpd-ssl.conf.in - and for the record, also to changing code, be that in ssl_engine_config.c:modssl_ctx_init() or elsewhere. Those keen on enabling it by default on behalf of the users (because we know what is good for you) are free to lobby with the OS vendors to have their package defaults changed. You are welcome to object, and I think Ben's reply here to your thoughts and observations, particularly your early one, since he is advocating for this change and this would move the dialog along to a conclusion. Contrawise, httpd project can do the 'right thing' from our perspective, and the downstream distributors can correspondingly disable it. Moreso, any enterprise so affected already is configuring httpd to their own organization's standards and policies. If you are suggesting we shouldn't change the compiled-in default, I can agree, POLS (Principal Of Least Surprise). If you are suggesting the default config shouldn't reflect the ability to efficiently handle OCSP by stapling, here I think we would disagree. Not to anyone in particular: Contacting the OCSP responder may indeed be a surprise, and it might not even work due to to firewall rules being effectively surprised. (DNS was too once upon a time.) It does require education on the part of some administrators. But: No changes discussed actually change the behavior for any non-hypothetical configuration, since SSL is not configured by default and no existing configurations will magically start contacting the responder. (The more nuanced wording of OCSP stapling by default is IFF you're using the latest httpd default configuration files, an OCSP responder pointed to in a certificate you configure will be utilized, unless you say otherwise.). The config change does move the key decision point regarding this new concept to the basic enablement of SSL. In retrospect, it might have been wise to enable/disable stapling on the SSLCertificateFile directive, both for the more granular control as well as making the admin see the setting when performing that required bit of configuration. -- Born in Roswell... married an alien... http://emptyhammock.com/
