Works for me (so far): map $query_string $bad_query { "~[^&;]+([&;][^&;]*){1,}" 1; # deny two or more parameters "~emailaddress=[^@]+%40[^@]+" 0; # allow Thunderbird autoconf "~.+=.+" 1; # deny any other query default 0; #by 173279834462 - Nginx Mailing List - English
Hello, Our local policy demands the rejection of any query; we do this as follows: if ($is_args) { return 301 /; } The introduction of Thunderbird autoconfiguration demands an exception to the above policy, because of "GET /.well-known/autoconfig/mail/config-v1.1.xml?emailaddre=uname%40example.com". The resulting rule would be if (($is_args) && ($args !~ emailaddrby 173279834462 - Nginx Mailing List - English
> They are currently struggling with their nginx module, > allowing a certificate to be automatically installed on nginx. Would you really use that script? 1. It requires python. --- I do not have python on my server, and I have no intention to install it. You can kick and scream, but that will not change my decision. If nginx will demand python to run, I will drop nginx for soby 173279834462 - Nginx Mailing List - English
#!/bin/ksh -e # # The purpose of this script is to prime the OCSP cache of nginx. # # Ideally, nginx would prime its worker processes ahead of any client request. # There are two events that ought to trigger this behaviour: # the server start-up, and each time a cache expires. # # In reality, nginx stands still until a client hits a worker process, # then the specific worker processby 173279834462 - Nginx Mailing List - English
The files are correct as they are: ssl_trusted_certificate includes the intermediate and the root ca, ssl_certificate includes the server's own and the intermediate. The error was ... in a missing ssl_trusted_certificate directive in one of the server clauses. A human error, undetected by nginx. To prevent such errors from happening, considering the complexity of certain configurationsby 173279834462 - Nginx Mailing List - English
Will adjust the files, and see what happens...by 173279834462 - Nginx Mailing List - English
Hold on... ssl_dhparam [...]/ssl/dh2048.pem; ssl_certificate_key [...]/ssl/www.key; ssl_certificate [...]/ssl/www-bundle.pem; ssl_trusted_certificate [...]/ssl/ca-bundle.pem; The intermediate and the server's own are in www-bundle.pem. The local trust store is in ca-bundle.pem;by 173279834462 - Nginx Mailing List - English
After all, the root certificate is part of the local trust store (/etc/ssl/ca-bundle.pem), and nginx knows it (ssl_trusted_certificate points to it).by 173279834462 - Nginx Mailing List - English
> Simpliest solution would be to switch off OCSP response verification. I have just tried it. It takes two hits from a client to fill the cache of its worker process. There are two problems with this: - the other worker processes are not primed on restart, and therefore clients that require ocsp stapling wil print an error instead of rendering the page (my FF does it). - the sby 173279834462 - Nginx Mailing List - English
I see this: ==> stderr.log <== 2015/09/23 18:33:00 41509#0: OCSP_basic_verify() failed (SSL: error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:Verify error:unable to get local issuer certificate) while requesting certificate status, responder: ocsp.startssl.comby 173279834462 - Nginx Mailing List - English
Patch applied to zlib... Zero errors and zero warnings compiling nginx 1.9.5 with clang/llvm 3.7.0. Well done... --- inflate.c.orig 2015-09-23 18:22:54.000000000 +0200 +++ inflate.c 2015-09-23 18:23:45.000000000 +0200 @@ -1504,9 +1504,10 @@ { struct inflate_state FAR *state; - if (strm == Z_NULL || strm->state == Z_NULL) return -1L << 16; + if (strm == Z_NULL ||by 173279834462 - Nginx Mailing List - English
Hot from the oven... Thanks!by 173279834462 - Nginx Mailing List - English
From my seat, the CA works and NGINX is not returning the OCSP response. In fact, I can generate the stapling manually. Barred the various considerations of what is or is not possible, I think that a more robust solution is in order, for example, nginx could (should at this point?) log the stapling progress, so that sysadmin knows that the process is being executed, possibly with releby 173279834462 - Nginx Mailing List - English
> Though not providing an OCSP response isn't a problem at all > as OCSP stapling is just an optimization, and Well. it *is* a problem. Without stapling, each client that hits our server also hits the ocsp server. In our case, the ocsp server is overloaded (StartSSL), and therefore we can help by caching the response and delivering it ouselves. There is another, more generalby 173279834462 - Nginx Mailing List - English
I hate this editor... The warning points at the "<< 16" part.by 173279834462 - Nginx Mailing List - English
inflate.c:1507:61: warning: shifting a negative signed value is undefined [-Wshift-negative-value] if (strm == Z_NULL || strm->state == Z_NULL) return -1L << 16; ~~~ ^by 173279834462 - Nginx Mailing List - English
cannot delete - please ignore this threadby 173279834462 - Nginx Mailing List - English
inflate.c:1507:61: warning: shifting a negative signed value is undefined [-Wshift-negative-value] if (strm == Z_NULL || strm->state == Z_NULL) return -1L << 16; ~~~ ^by 173279834462 - Nginx Mailing List - English
The purpose of the ssl_stapling_file was to prime the cache. Without that file, openssl says "OCSP response: no response sent". For nginx to load the cache by itself, clients have to hit the same worker process a few times. I currently have 8 worker processes, which means that the server needs at least 8 simultaneous client who are knowledgeable and patient enough to hit the server a fewby 173279834462 - Nginx Mailing List - English
Hello, nginx is not updating the OCSP response cache. openssl says: [...] Cert Status: good This Update: Sep 9 09:59:46 2015 GMT Next Update: Sep 11 09:59:46 2015 GMT gnutls says "There is a newer OCSP response but was not provided by the server". The configuration says: [...] ssl_stapling on; ssl_stapling_verify on; ssl_stapling_fileby 173279834462 - Nginx Mailing List - English
Hello, nginx is not updating the ocsp response cache: This Update: Sep 5 08:36:32 2015 GMT Next Update: Sep 7 08:36:32 2015 GMT It is 16:09, so the cache is 8h behind. How would you diagnose and solve this problem? A related question is the duration of the cache. The local server uses 2 days, as shown above. How would you change this duration to, say, 8 days? Thby 173279834462 - Nginx Mailing List - English
> This depends on how your certificate is issued. If your certificate is issued directly by root CA certificate, then you don't need any extra certs here. If there are some intermediate certs, then you'll have to put them also. > When this directive was introduced, almost all certificates were issued directly by roots. No in most cases intermediate certificates are additionally required. Eiby 173279834462 - Nginx Mailing List - English
> Note that this isn't really indicate anything: there are two forms of OCSP requests, POST and GET. And Firefox uses POST, while nginx uses GET. Given the fact that the responder was completely broken just a few days ago - it's quite possible that it's still broken for GETs in some cases. To comply with local security policy, we disabled POST globally on all public-facing servers. This haby 173279834462 - Nginx Mailing List - English
>When I request http://example.com/?Open, what response do you want to send me? 301 to /: this would do the canonicalization, > location = / { if ($is_args) { return 301 /; } } 404: this would correspond to reality, > location = / { if ($is_args) { return 404; } } However, if one compiled nginx without the scripting engines, shouldn't it return 404 by default, instead ofby 173279834462 - Nginx Mailing List - English
The last security audit revealed the following: V:Wed Apr 15 20:58:19 2015 - 200 for GET: /?mod=node&nid=some_thing&op=view V:Wed Apr 15 20:58:43 2015 - 200 for GET: /?Open V:Wed Apr 15 20:58:43 2015 - 200 for GET: /?OpenServer V:Wed Apr 15 20:59:16 2015 - 200 for GET: /?sql_debug=1 V:Wed Apr 15 20:59:40 2015 - 200 for GET: /?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 V:Wed Apr 15 2by 173279834462 - Nginx Mailing List - English
Update: The original error "SSL3_CTX_CTRL:called a function you should not cal" is no longer on the logs. The last occurrence dates back to early february: 2015/02/03 20:23:30 69020#0: *16 ignoring stale global SSL error (SSL: error:14085042:SSL routines:SSL3_CTX_CTRL:called a function you should not call) while SSL handshaking, client: , server: 0.0.0.0:443 From my seat thby 173279834462 - Nginx Mailing List - English
"fix" applied. This is what I see when running ssllabs again: 2015/03/17 18:08:33 14508#0: *478 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early) while SSL handshaking, client: 64.41.200.104, server: 0.0.0.0:443 2015/03/17 18:08:34 14506#0: *479 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:SSL3_READ_BYTES:ccs receiveby 173279834462 - Nginx Mailing List - English
The *feeling* that the problem is related to SNI is getting stronger. This is the error log when running ssllabs.com on the server: ==> stderr.log <== 2015/03/17 17:12:45 40733#0: *925 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early) while SSL handshaking, client: 64.41.200.104, server: 0.0.0.0:443 2015/03/17 17:12:46 40733#0: *926 Sby 173279834462 - Nginx Mailing List - English
Will try it.by 173279834462 - Nginx Mailing List - English
I am on nginx 1.7.10 with LibreSSL 2.1.5. This is what I see in the error log: 2015/02/03 20:23:30 69020#0: *16 ignoring stale global SSL error (SSL: error:14085042:SSL routines:SSL3_CTX_CTRL:called a function you should not call) while SSL handshaking, client: [...IP...], server: 0.0.0.0:443 I *feel* that the above is related to the following, because the two have occurred together:by 173279834462 - Nginx Mailing List - English