OCSP, CRL, LUA and Nginx

314 views
Skip to first unread message

Ryan Hurst

unread,
Nov 27, 2013, 4:37:45 PM11/27/13
to openre...@googlegroups.com

Hello, I may in left field here but maybe you can point me in the right direction.

I would like to configure Nginx as a forward proxy for a server that is serving binary encoded objects/files used in PKI; specifically CRLs and X509.

These objects have “next update” periods in them that can be used as “cache” periods or atleast the input to them (basically clients/intermediates should never cache beyond those validity periods).

I was wondering if there was any way to leverage Nginx the work done by this project’s addition of LUA to Nginx to accomplish this.

For example I would want to extract the This update or Next update from a OCSP response:

openssl ocsp -respin ocspglobalsignca.resp -text

OCSP Response Data:

    OCSP Response Status: successful (0x0)

    Response Type: Basic OCSP Response

    Version: 1 (0x0)

    Responder Id: 70F9ACAFEFAF9D345FC498793CA452BB9D87EF72

    Produced At: Oct  9 07:31:09 2013 GMT

    Responses:

    Certificate ID:

      Hash Algorithm: sha1

      Issuer Name Hash: A0720EA06A7C620254F2A8F59DD27BA4F3B72FA4

      Issuer Key Hash: B0B04AFD1C7528F81C61AA13F6FAC1903D6B16A3

      Serial Number: 1121A88BBF3F2260E5988C734C9F86E08C91

    Cert Status: good

    Next Update: Oct  9 07:31:09 2014 GMT

    This Update: Oct  9 07:31:09 2013 GMT

 

And compute what the expires header should be based on those values; is this something can can be done with this project?

 

Thanks in advance,

 

Ryan

Matthieu Tourne

unread,
Nov 27, 2013, 6:59:43 PM11/27/13
to openre...@googlegroups.com
Hello Ryan,

I assume you mean Nginx as a reverse proxy here.

It is certainly conceivable. 
But the main problem you're going to run into, is that you have to defer sending back *any* response to the client, till the end of the response body, since the content of interest is located towards the end of the response.
Usually HTTP headers are sent as fast as possible when proxying, otherwise there will be a lot of buffering and delays in your reverse proxy.

It seems that it would make more sense to generate those expiration headers directly at the source if possible, instead of in a proxy.

If you still wanted to do that you would need :

1. filter out the original headers, to prevent them from going out. 

2. filter the body of the response
in there aggregate all of the cert, possibly coming in chunks.

3. make sense of the cert in the response
for that you can either parse the fields of your cert "manually", or try to feed it to openssl
using one of the lua-openssl wrappers for instance :

4. finally craft a response with the modified headers and the cert.

Hope that helps,
Matthieu.


--
You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

杨阳

unread,
Jul 22, 2016, 3:31:28 AM7/22/16
to openresty-en

I think you wonder the cached ocsp status response expire, so if you want to use the ocsp stapling, you should use validate_ocsp_response function to check    it before use ocsp stapling.


在 2013年11月28日星期四 UTC+8上午5:37:45,Ryan Hurst写道:
Reply all
Reply to author
Forward
0 new messages