Puppet users - Jul 2007 - Signing certificates with mongrel+apache puppetmaster

Hi,

Is there a way to have puppetmaster sign new clients'' certificates when
using apache+mongrel for serving, without having a separate puppetmaster
instance running webrick on a different port/IP?

I guess this does not work out of the box because apache is told to do
the verification very early in the connection process, at which point it
does not yet know that the client is going to request a certificate.

So to fix that, one should somehow tell apache to verify the certificate
but NOT to reject it straight away if the verification fails. Instead,
there should be some kind of logic a little bit further down the pipe,
working like this:
A) decide
 - if this request is for a new certificate, let it through to mongrel,
   regardless of the client''s certificate
 - otherwise:
   B) decide:
    - let the request through if the certificate verification was
      successful
    - drop the connection otherwise

..which I suspect is what puppetmasterd/webrick does.

Now, is there something in the request that we could check for
relatively easily to determine the output of decision "A"?

-- 
Marcin Owsiany
Web Systems Integrator - Guardian Unlimited

------------------------------------------------------------------
Visit Guardian Unlimited - the UK''s most popular newspaper website
http://guardian.co.uk http://observer.co.uk
------------------------------------------------------------------
The Newspaper Marketing Agency
Opening Up Newspapers
http://www.nmauk.co.uk
------------------------------------------------------------------

This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.

Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.

Guardian News & Media Limited
A member of Guardian Media Group PLC
Registered Office
Number 1 Scott Place, Manchester M3 3GG
Registered in England Number 908396

On Jul 25, 2007, at 8:01 AM, Marcin Owsiany wrote:
> So to fix that, one should somehow tell apache to verify the  
> certificate
> but NOT to reject it straight away if the verification fails. Instead,
> there should be some kind of logic a little bit further down the pipe,
> working like this:
> A) decide
>  - if this request is for a new certificate, let it through to  
> mongrel,
>    regardless of the client''s certificate
>  - otherwise:
>    B) decide:
>     - let the request through if the certificate verification was
>       successful
>     - drop the connection otherwise
>
> ..which I suspect is what puppetmasterd/webrick does.
>
> Now, is there something in the request that we could check for
> relatively easily to determine the output of decision "A"?
The Puppet code is set up to distinguish authenticated from  
unauthenticated clients.  By default, only the CA methods can be  
accessed by unauthenticated clients.  Webrick lets through any client  
at all, but authenticated clients are distinguishable by the fact  
that they have a certificate.

For the case of Apache, we need some way to maintain that distinction  
but still let all clients through; then the server-side can be  
reconfigured to support the distinction that Apache is using.  Does  
anyone know how to configure Apache in this way?

  --
  Q.  Does Usenet help stamp out ignorance?
  A.  That depends on whether by "stamp out" you mean
"eliminate" or
      "reproduce rapidly in great quantity."
                  -- From the Usenet FAQ
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Luke Kanies wrote:
> For the case of Apache, we need some way to maintain that distinction  
> but still let all clients through; then the server-side can be  
> reconfigured to support the distinction that Apache is using.  Does  
> anyone know how to configure Apache in this way?
I guess this begs the question...  Can we configure apache to set some 
header that contains who''s signed the client certificate?

In the case of a new client with a csr, the client would connect with a 
self signed certificate, and apache would pass an unknown value in the 
X-SSL-SIGNING-AUTHORITY header, or whatever...

In the case of a known client, apache would verify the signing cert and 
pass the CN of the CA certificate back to puppet, which it could check 
and verify.

I haven''t done this, but it doesn''t seem terribly far fetched.

-- 
Jeff McCune
Systems Manager
The Ohio State University
Department of Mathematics


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Looking at http://httpd.apache.org/docs/2.2/mod/mod_ssl.html under
SSLOptions Directive it appears that the ssl option StdEnvVars may do
the job, and if not ExportCertData should provide the needed
information.

Currently I don''t the setup to test these options but hopefully they
help.

Thanks
Brian

On 7/25/07, Jeff McCune <mccune@math.ohio-state.edu>
wrote:
> Luke Kanies wrote:
> > For the case of Apache, we need some way to maintain that distinction
> > but still let all clients through; then the server-side can be
> > reconfigured to support the distinction that Apache is using.  Does
> > anyone know how to configure Apache in this way?
>
> I guess this begs the question...  Can we configure apache to set some
> header that contains who''s signed the client certificate?
>
> In the case of a new client with a csr, the client would connect with a
> self signed certificate, and apache would pass an unknown value in the
> X-SSL-SIGNING-AUTHORITY header, or whatever...
>
> In the case of a known client, apache would verify the signing cert and
> pass the CN of the CA certificate back to puppet, which it could check
> and verify.
>
> I haven''t done this, but it doesn''t seem terribly far
fetched.
>
> --
> Jeff McCune
> Systems Manager
> The Ohio State University
> Department of Mathematics
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>
>
>

On Wed, Jul 25, 2007 at 08:47:49PM -0700, Brian Finney
wrote:
> Looking at http://httpd.apache.org/docs/2.2/mod/mod_ssl.html under
> SSLOptions Directive it appears that the ssl option StdEnvVars may do
> the job, and if not ExportCertData should provide the needed
> information.
> 
> Currently I don''t the setup to test these options but hopefully
they help.
We just tested it with s_client and CGI and figured out that the
following should be enough to make it work with mod_proxy_balancer
talking to mongrel:

Compared to the recipe on the wiki:
1) add this directive:
  RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e

2) change this directive:
  SSLVerifyClient require
to
  SSLVerifyClient optional

This way all requests should be forwarded to mongrel and the
X-Client-Verify header will contain "SUCCESS" if the client is already
holding a properly signed certificate, and "NONE" if it''s a
temporary
self-signed (or other) certificate.

We are now about to try to hack the mongrel/puppetmasterd code to check
this additional header as needed. I''m not sure if we''re going
to succeed
with this one, though :)

-- 
Marcin Owsiany
Web Systems Integrator - Guardian Unlimited

------------------------------------------------------------------
Visit Guardian Unlimited - the UK''s most popular newspaper website
http://guardian.co.uk http://observer.co.uk
------------------------------------------------------------------
The Newspaper Marketing Agency
Opening Up Newspapers
http://www.nmauk.co.uk
------------------------------------------------------------------

This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.

Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.

Guardian News & Media Limited
A member of Guardian Media Group PLC
Registered Office
Number 1 Scott Place, Manchester M3 3GG
Registered in England Number 908396

On Thu, Jul 26, 2007 at 11:21:31AM +0100, Marcin Owsiany
wrote:
> We are now about to try to hack the mongrel/puppetmasterd code to check
> this additional header as needed. I''m not sure if we''re
going to succeed
> with this one, though :)
It seems we did.

Actually it looks like the ''optional'' setting in apache
prevents it from
accepting connections from any client other than:
 - one holding a valid certificate signed by the puppet CA
 - one _without_ a certificate

So to prevent puppetmasterd from giving anything other than a new
certificate to a client who connects without a certificate, we need the
following change to puppet/network/server/mongrel.rb

--- mongrel.rb	2007-06-17 23:06:39.000000000 +0100
+++ mongrel.rb	2007-07-26 14:47:31.000000000 +0100
@@ -116,7 +118,11 @@
             ip = params["REMOTE_ADDR"]
             if dn = params[Puppet[:ssl_client_header]]
                 client = dn.sub("/CN=", '''')
-                valid = true
+		if params["HTTP_X_CLIENT_VERIFY"] == ''SUCCESS''
+	                valid = true
+		else
+			valid = false
+		end
             else
                 client = Resolv.getname(ip)
                 valid = false

A different, but related issue with it is that if the client connects
without a certificate and asks for configuration (we tested that using
openssl s_client and pasting what a puppet client would send when asking
for the configuration), then the X-Client-DN: header contains a literal
"(null)", which probably makes puppetmasterd fail parsing the DN in a
nasty way. A symptom of that is that apache returns a 502 Proxy Error:

<p>The proxy server received an invalid response from an upstream
server.<br /> The proxy server could not handle the request
<em><a
href="/RPC2">POST&nbsp;/RPC2</a></em>.<p>
Reason: <strong>Error reading from remote
server</strong></p></p>

A tcpdump on the apache-mongrel connection suggests that mongrel simply
closes the connection instead of politely refusing access.

-- 
Marcin Owsiany
Web Systems Integrator - Guardian Unlimited

------------------------------------------------------------------
Visit Guardian Unlimited - the UK''s most popular newspaper website
http://guardian.co.uk http://observer.co.uk
------------------------------------------------------------------
The Newspaper Marketing Agency
Opening Up Newspapers
http://www.nmauk.co.uk
------------------------------------------------------------------

This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.

Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.

Guardian News & Media Limited
A member of Guardian Media Group PLC
Registered Office
Number 1 Scott Place, Manchester M3 3GG
Registered in England Number 908396

On Jul 26, 2007, at 9:21 AM, Marcin Owsiany wrote:
> It seems we did.
I had confidence. :)
> Actually it looks like the ''optional'' setting in apache
prevents it
> from
> accepting connections from any client other than:
>  - one holding a valid certificate signed by the puppet CA
>  - one _without_ a certificate
>
> So to prevent puppetmasterd from giving anything other than a new
> certificate to a client who connects without a certificate, we need  
> the
> following change to puppet/network/server/mongrel.rb
>
> --- mongrel.rb	2007-06-17 23:06:39.000000000 +0100
> +++ mongrel.rb	2007-07-26 14:47:31.000000000 +0100
> @@ -116,7 +118,11 @@
>              ip = params["REMOTE_ADDR"]
>              if dn = params[Puppet[:ssl_client_header]]
>                  client = dn.sub("/CN=", '''')
> -                valid = true
> +		if params["HTTP_X_CLIENT_VERIFY"] ==
''SUCCESS''
> +	                valid = true
> +		else
> +			valid = false
> +		end
>              else
>                  client = Resolv.getname(ip)
>                  valid = false
Patch applied 2727.
> A different, but related issue with it is that if the client connects
> without a certificate and asks for configuration (we tested that using
> openssl s_client and pasting what a puppet client would send when  
> asking
> for the configuration), then the X-Client-DN: header contains a  
> literal
> "(null)", which probably makes puppetmasterd fail parsing the DN
in a
> nasty way. A symptom of that is that apache returns a 502 Proxy Error:
>
> <p>The proxy server received an invalid response from an upstream
> server.<br /> The proxy server could not handle the request
<em><a
>
href="/RPC2">POST&nbsp;/RPC2</a></em>.<p>
> Reason: <strong>Error reading from remote
server</strong></p></p>
>
> A tcpdump on the apache-mongrel connection suggests that mongrel  
> simply
> closes the connection instead of politely refusing access.
I''ve added an additional patch to make sure that the DN looks valid.

Please let me know if things are now working out, and it''d be great  
if someone would update the UsingMongrel page with your extra  
information.

  --
  In our civilization, and under our republican form of government,
  intelligence is so highly honored that it is rewarded by exemption  
from
  the cares of office.  --Ambrose Bierce
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com