Whitelisting Client Side Certificates

I’m currently working on POC for my company which is looking to use
NGINX to
validate API Requests using Client Side Certificates. Presently we have
it
setup so we are self signing/generating these certificates on the local
machine and are able to use these successfully in our tests. We are also
able to use the revocation list to disable generated certificates.

Moving forward it is possible we will be using an external CA to
generate
these certificates and we are trying to determine if this is a way to
‘whitelist’ certificates so only those generated ones which we have
visibility of will be verified, rather than a ‘blacklisting’ approach to
block those which are revoked? i.e. Given a client certificate generated
by
a external CA how can we established this in a trusted list of certs to
verify?

Apologies if this question is lacking technical details/knowledge, this
is
my first hands on experience with SSL.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,247969,247969#msg-247969

Having just gone through learning about this over the last few days,
here’s
what I learned. Take it w/ a grain of salt.

There are 2 ways I’m aware of.

  1. turn on strict client verify and limit the ca list that the server
    knows
    about. this will cause the server to have a limited view of what certs
    are
    valid in the world and cause it to reject any client who’s cert doesn’t
    chain back to your ca list. I think you set that here:
    http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_trusted_certificate

  2. match subject name and subjectAlternatename to a whitelist. I don’t
    know
    if nginx can do this part natively. Haproxy can:
    http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-verifyhost

…from skimming, the way you’d do #2 is to use
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_trusted_certificateto
set a proxy header from: $ssl_client_cert and have your backend parse
and accept/deny names found in that pem structure

On Wed, Feb 26, 2014 at 9:58 AM, David Birdsong
[email protected]wrote:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_trusted_certificate

  1. match subject name and subjectAlternatename to a whitelist. I don’t
    know if nginx can do this part natively. Haproxy can:
    http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-verifyhost

i misunderstood verifyhost in haproxy, that’s something else completely.
it
doesn’t verify subjectname or subjectAlternatename on client supplied
certs.

On Wed, Feb 26, 2014 at 9:58 AM, David Birdsong
[email protected]wrote:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_trusted_certificate

  1. match subject name and subjectAlternatename to a whitelist. I don’t
    know if nginx can do this part natively. Haproxy can:
    http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-verifyhost

…from skimming, the way you’d do #2 is to use
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_trusted_certificateto
set a proxy header from: $ssl_client_cert and have your backend parse
and accept/deny names found in that pem structure

#2 sounds like a great job for:
http://wiki.nginx.org/HttpLuaModule#access_by_lua

I was wondering if caching whitelisted certificates’ thumbprints
somewhere
and then verifying against this per request would work? One approach
could
be storing these thumprints in Memcached and querying using Lua? Or is
there
a more straightforward/efficient approach?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,247969,247987#msg-247987

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs