Hello!
Here are patches for OCSP stapling support. Testing and
review appreciated.
New directives:
ssl_trusted_certificate /path/to/file;
Specifies a file with CA certificates in the PEM format used for
certificate verification. In contrast to ssl_client_certificate, DNs
of these certificates aren't sent to a client in CertificateRequest.
ssl_stapling on|off;
Activates OCSP stapling.
ssl_stapling_file /path/to/file;
Use predefined OCSP response for stapling, do not query responder.
Assumes OCSP response in DER format as produced by "openssl ocsp".
ssl_stapling_responder URL;
Use specified OCSP responder instead of one found in AIA certificate
extension.
Example configuration:
server {
listen 443 ssl;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
ssl_stapling on;
ssl_trusted_certificate /path/to/ca.pem;
resolver 8.8.8.8;
}
Known limitations:
- Unless externally set OCSP response is used (via the "ssl_stapling_file"
directive), stapled response won't be sent in a first connection. This
is due to the fact that OCSP responders are currently queried by nginx
once it receives connection with certificate_status extension in ClientHello,
and due to limitations in OpenSSL API (certificate status callback is
blocking).
- Cached OCSP responses are currently stored in local process memory (thus
each worker process will query OCSP responders independently). This
shouldn't be a problem as typical number of worker processes is low, usually
set match number of CPUs.
- Various timeouts are hardcoded (connect/read/write timeouts are 60s,
response is considered to be valid for 1h after loading). Adding
configuration directives to control these would be trivial, but it may
be a better idea to actually omit them for simplicity.
- Only "http://" OCSP responders are recognized.
Patch can be found here:
http://nginx.org/patches/ocsp-stapling/
Thanks to Comodo, DigiCert and GlobalSign for sponsoring this work.
Maxim Dounin
Hello,
I have written a module to implement sFlow in nginx (nginx-sflow-module.googlecode.com). I'm simulating a 1-second timer-tick by assuming that the request handler will be called at least once per second. That's probably a safe assumption for any server that would care about sFlow monitoring, but I expect there's a better way...
I tried asking for a timer callback like this:
ngx_event_t *ev = ngx_pcalloc(pool, sizeof(ngx_event_t));
ev->hander = ngx_http_sflow_tick_event_hander;
ngx_add_timer(ev, 1000);
but (like most russian girls) the event never called me back. It looks like I might have to hang this on a file-descriptor somehow, but that's where I'm getting lost. Any pointers would be most appreciated.
Neil
Hello!
According to the current implementation of ngx_http_upstream, there is
almost no way for 3rd-party output body filters and "post_subrequest"
handlers (in the subrequest context) to know if there's any errors
while ngx_http_upstream is processing the upstream response body after
the response header is sent out (in both the buffered and non-buffered
modes).
For example, if
1. a read-timeout happens in the middle of the process of reading the
upstream response body,
2. or the upstream connection is closed prematurely in the same situation,
then ngx_http_upstream will just happily finalize the current request
with the status code 0 (i.e., NGX_OK). This issue already affects at
least our ngx_srcache and ngx_lua modules (originally reported by
Bryan Alger).
Here attaches a patch that makes ngx_http_upstream set
r->headers_out.status to a new error status code to notify the outside
world if there is a problem. Comments will be highly appreciated as
always :)
Thanks!
-agentzh
--- nginx-1.2.3/src/http/ngx_http_upstream.c 2012-08-06 10:34:08.000000000 -0700
+++ nginx-1.2.3-patched/src/http/ngx_http_upstream.c 2012-09-09
21:58:04.727761891 -0700
@@ -2383,7 +2383,7 @@
if (c->read->timedout) {
ngx_connection_error(c, NGX_ETIMEDOUT, "upstream timed out");
- ngx_http_upstream_finalize_request(r, u, 0);
+ ngx_http_upstream_finalize_request(r, u, NGX_HTTP_GATEWAY_TIME_OUT);
return;
}
@@ -2430,13 +2430,17 @@
if (u->busy_bufs == NULL) {
if (u->length == 0
- || upstream->read->eof
- || upstream->read->error)
+ || (upstream->read->eof &&
u->headers_in.content_length_n == -1))
{
ngx_http_upstream_finalize_request(r, u, 0);
return;
}
+ if (upstream->read->eof || upstream->read->error) {
+ ngx_http_upstream_finalize_request(r, u,
NGX_HTTP_BAD_GATEWAY);
+ return;
+ }
+
b->pos = b->start;
b->last = b->start;
}
@@ -2710,7 +2714,16 @@
#if 0
ngx_http_busy_unlock(u->conf->busy_lock, &u->busy_lock);
#endif
- ngx_http_upstream_finalize_request(r, u, 0);
+
+ if (p->upstream_done
+ || (p->upstream_eof && u->headers_in.content_length_n == -1))
+ {
+ ngx_http_upstream_finalize_request(r, u, 0);
+
+ } else {
+ ngx_http_upstream_finalize_request(r, u, NGX_HTTP_BAD_GATEWAY);
+ }
+
return;
}
}
@@ -3073,6 +3086,13 @@
&& rc != NGX_HTTP_REQUEST_TIME_OUT
&& (rc == NGX_ERROR || rc >= NGX_HTTP_SPECIAL_RESPONSE))
{
+ if (rc == NGX_ERROR) {
+ r->headers_out.status = NGX_HTTP_INTERNAL_SERVER_ERROR;
+
+ } else {
+ r->headers_out.status = rc;
+ }
+
rc = 0;
}
Author: mdounin
Date: 2013-03-29 17:53:47 +0000 (Fri, 29 Mar 2013)
New Revision: 5160
URL: http://trac.nginx.org/nginx/changeset/5160/nginx
Log:
Merge of r5127: language in a comment.
Fixed language in a comment preceding ngx_http_index_handler().
Modified:
branches/stable-1.2/
branches/stable-1.2/src/http/modules/ngx_http_index_module.c
Index: branches/stable-1.2
===================================================================
--- branches/stable-1.2 2013-03-29 17:51:00 UTC (rev 5159)
+++ branches/stable-1.2 2013-03-29 17:53:47 UTC (rev 5160)
Property changes on: branches/stable-1.2
___________________________________________________________________
Modified: svn:mergeinfo
## -1 +1 ##
-/trunk:4611-4632,4636-4657,4671-4672,4674-4676,4682,4684-4699,4704-4706,4713,4736-4741,4754,4756-4771,4775,4777-4780,4782-4785,4795,4811-4820,4822-4824,4828-4835,4840-4844,4865-4872,4885-4887,4890-4896,4913-4925,4933-4934,4939,4944-4949,4961-4969,4973-4974,4976-4994,4997,4999-5005,5011-5025,5027-5031,5066,5070-5071,5078,5082-5083,5098,5109,5113-5114,5117,5123,5128
+/trunk:4611-4632,4636-4657,4671-4672,4674-4676,4682,4684-4699,4704-4706,4713,4736-4741,4754,4756-4771,4775,4777-4780,4782-4785,4795,4811-4820,4822-4824,4828-4835,4840-4844,4865-4872,4885-4887,4890-4896,4913-4925,4933-4934,4939,4944-4949,4961-4969,4973-4974,4976-4994,4997,4999-5005,5011-5025,5027-5031,5066,5070-5071,5078,5082-5083,5098,5109,5113-5114,5117,5123,5127-5128
\ No newline at end of property
Modified: branches/stable-1.2/src/http/modules/ngx_http_index_module.c
===================================================================
--- branches/stable-1.2/src/http/modules/ngx_http_index_module.c 2013-03-29 17:51:00 UTC (rev 5159)
+++ branches/stable-1.2/src/http/modules/ngx_http_index_module.c 2013-03-29 17:53:47 UTC (rev 5160)
@@ -85,12 +85,12 @@
/*
* Try to open/test the first index file before the test of directory
- * existence because valid requests should be much more than invalid ones.
- * If the file open()/stat() would fail, then the directory stat() should
- * be more quickly because some data is already cached in the kernel.
+ * existence because valid requests should prevail over invalid ones.
+ * If open()/stat() of a file will fail then stat() of a directory
+ * should be faster because kernel may have already cached some data.
* Besides, Win32 may return ERROR_PATH_NOT_FOUND (NGX_ENOTDIR) at once.
- * Unix has ENOTDIR error, however, it's less helpful than Win32's one:
- * it only indicates that path contains an usual file in place of directory.
+ * Unix has ENOTDIR error; however, it's less helpful than Win32's one:
+ * it only indicates that path points to a regular file, not a directory.
*/
static ngx_int_t