Puppet users - Dec 2010 - Using Puppet's client certificates for Apache, SSLVerifyClient

Hi -

I read up on this subject quite a bit, and was able to find a few
posts on the mailing list, even found a wiki article.  Unfortunately
it doesn''t quite address what I''m looking to do.

From what I understand, Puppet''s client/server authentication system -
using SSL - is portable.  I believe that I should be able to use the
same SSL certificates and keys (and even the same CA) with regard to
other SSL/TLS connections, as well.

In particular, I want to use Apache''s ''SSLVerifyClient
require''
option, but not in my Mongrel setup, but for an entirely different SSL
site which also happens to be on the same machine as my Puppet master.
 Assuming both my Puppet master and my Puppet agent represent the
server and client in this connection, respectively, then I believe I
should be able to use that already-established and signed and trusted
SSL relationship to implement this additional site.  I do expect
problems with CN mismatches, but I can live with that.

I''ve gone through the process of configuring an additional SSL site in
Apache to use ''SSLVerifyClient require'', and mimicked a
request from a
Puppet node (previously signed, enrolled, and working) using curl.  I
used the Puppet generated cert and key from this Puppet node in the
argument, looking something like this:

curl -k -v --cert certs/job01.vmserver02.dev.az.domain.local.pem --key
private_keys/job01.vmserver02.dev.az.toolbox.local.pem
https://10.1.0.165/test.htm

I got a little smile that the request did in fact work without error
(save having the client use the CA certificiate - I''ll re-visit that
later), but also concerned because I understand this should not have
worked.  I ran puppetca --clean against this particular Puppet node''s
certificate, and expected it to just plain not work any more, and
thereby updating my Puppet master''s key store.

Here''s that Apache configuration I was talking about:

<VirtualHost 10.1.0.165:443>
        SSLEngine On
        SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
        SSLCertificateFile
/var/lib/puppet/ssl/certs/puppet01.ops.az.domain.local.pem
        SSLCertificateKeyFile
/var/lib/puppet/ssl/private_keys/puppet01.ops.az.domain.local.pem
        SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
        SSLVerifyClient require
        SSLVerifyDepth 1
        SSLOptions +StdEnvVars
        ErrorLog /var/log/httpd/ssltest-error.log
        CustomLog /var/log/httpd/ssltest-access.log combined
</VirtualHost>

Pretty simple, right?  Am I doing this properly?

A little background:  I am in the process of building AMIs for
Amazon''s EC2, which will eventually have VPN connections back to a
secure scope/pool on our internal network.  I do not want to
distribute the VPN profiles, complete with usernames and passwords,
with the AMIs.  I want Puppet to run once, generate those certs on
both the agent and master, and make those available for a curl request
in my EC2 bootstrap script to download this VPN profile in a secure
manner.  I only want a signed client accessing this VPN profile (pcf
file) which is going to be live on the Internet (protected, of course,
by client certificate verification).

I''m not sure why this doesn''t work as I expect it to.  I was
hoping to
get some feedback from someone who has gone down this route before, as
this is all pretty new to me.  If nothing more, I''m hoping to be able
to get this working in this situation, so that I can reuse this
functionality for other projects.  If Puppet is already doing a good
job of maintaining a nice keystore, why not use it for other things,
too?

Thanks!
-dant

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 22 December 2010 21:43, Dan Trainor <dan.trainor@gmail.com>
wrote:
> Hi -
>
[snip]
> From what I understand, Puppet''s client/server authentication
system -
> using SSL - is portable.  I believe that I should be able to use the
> same SSL certificates and keys (and even the same CA) with regard to
> other SSL/TLS connections, as well.
[snip]

I''ve used SSL and x509 certificates a fair bit, but I''m new to
puppet
and away from my install at the moment - so you should check what I''m
saying in case puppet uses a x509 feature I''ve forgotten about or
didn''t know in the first place -  x509 is not a small standard.
> curl -k -v --cert certs/job01.vmserver02.dev.az.domain.local.pem --key
> private_keys/job01.vmserver02.dev.az.toolbox.local.pem
> https://10.1.0.165/test.htm
First, the "-k" will cause curl to ignore any cert problems on the
server, so you probably want to try again without this to make sure.
> I got a little smile that the request did in fact work without error
> (save having the client use the CA certificiate - I''ll re-visit
that
> later), but also concerned because I understand this should not have
> worked.  I ran puppetca --clean against this particular Puppet
node''s
> certificate, and expected it to just plain not work any more, and
> thereby updating my Puppet master''s key store.
This is expected behavior.

If you clean the puppetd''s certificate, AFAIK all it does is delete it
from the puppetca. It doesn''t alter either the CA certificate (on the
puppetmaster) or the client certificate. To an external party (like
apache) nothing has changed. The puppetmaster will no-longer talk to
the client, but only because it no longer knows anything about the
certificate in it''s cert repository.

The feature of x509 that you will need to investigate is certificate
revocation and certificate revocation lists - CRL''s. CRLs are lists of
certificates that are no longer considered valid by the CA - even
though the certificate subject or other data is still valid. This
gives the CA a way of blacklisting certificates which may have been
compromised or otherwise judged to be no longer acceptable.

If you *have* to reject the clients on the basis of their
certificates, I think you will have to generate a CRL of the client
certificates as you clean them from the puppetmaster.

From the apache side of things, I think the SSLCARevocationPath
directive is what you need:
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#SSLCARevocationPath

Hope that helps.
> Thanks!
> -dant
-- 
Jonathan Barber <jonathan.barber@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

with recent versions of puppet, when you clean a certificate, you also
revoke it, you apache is simply not configured to look at the CRL
(certificate revocation list).

Ohad

On Wed, Dec 22, 2010 at 11:43 PM, Dan Trainor <dan.trainor@gmail.com>
wrote:
> Hi -
>
> I read up on this subject quite a bit, and was able to find a few
> posts on the mailing list, even found a wiki article.  Unfortunately
> it doesn''t quite address what I''m looking to do.
>
> From what I understand, Puppet''s client/server authentication
system -
> using SSL - is portable.  I believe that I should be able to use the
> same SSL certificates and keys (and even the same CA) with regard to
> other SSL/TLS connections, as well.
>
> In particular, I want to use Apache''s ''SSLVerifyClient
require''
> option, but not in my Mongrel setup, but for an entirely different SSL
> site which also happens to be on the same machine as my Puppet master.
>  Assuming both my Puppet master and my Puppet agent represent the
> server and client in this connection, respectively, then I believe I
> should be able to use that already-established and signed and trusted
> SSL relationship to implement this additional site.  I do expect
> problems with CN mismatches, but I can live with that.
>
> I''ve gone through the process of configuring an additional SSL
site in
> Apache to use ''SSLVerifyClient require'', and mimicked a
request from a
> Puppet node (previously signed, enrolled, and working) using curl.  I
> used the Puppet generated cert and key from this Puppet node in the
> argument, looking something like this:
>
> curl -k -v --cert certs/job01.vmserver02.dev.az.domain.local.pem --key
> private_keys/job01.vmserver02.dev.az.toolbox.local.pem
> https://10.1.0.165/test.htm
>
> I got a little smile that the request did in fact work without error
> (save having the client use the CA certificiate - I''ll re-visit
that
> later), but also concerned because I understand this should not have
> worked.  I ran puppetca --clean against this particular Puppet
node''s
> certificate, and expected it to just plain not work any more, and
> thereby updating my Puppet master''s key store.
>
> Here''s that Apache configuration I was talking about:
>
> <VirtualHost 10.1.0.165:443>
>        SSLEngine On
>        SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
>        SSLCertificateFile
> /var/lib/puppet/ssl/certs/puppet01.ops.az.domain.local.pem
>        SSLCertificateKeyFile
> /var/lib/puppet/ssl/private_keys/puppet01.ops.az.domain.local.pem
>        SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
>        SSLVerifyClient require
>        SSLVerifyDepth 1
>        SSLOptions +StdEnvVars
>        ErrorLog /var/log/httpd/ssltest-error.log
>        CustomLog /var/log/httpd/ssltest-access.log combined
> </VirtualHost>
>
> Pretty simple, right?  Am I doing this properly?
>
> A little background:  I am in the process of building AMIs for
> Amazon''s EC2, which will eventually have VPN connections back to a
> secure scope/pool on our internal network.  I do not want to
> distribute the VPN profiles, complete with usernames and passwords,
> with the AMIs.  I want Puppet to run once, generate those certs on
> both the agent and master, and make those available for a curl request
> in my EC2 bootstrap script to download this VPN profile in a secure
> manner.  I only want a signed client accessing this VPN profile (pcf
> file) which is going to be live on the Internet (protected, of course,
> by client certificate verification).
>
> I''m not sure why this doesn''t work as I expect it to.  I
was hoping to
> get some feedback from someone who has gone down this route before, as
> this is all pretty new to me.  If nothing more, I''m hoping to be
able
> to get this working in this situation, so that I can reuse this
> functionality for other projects.  If Puppet is already doing a good
> job of maintaining a nice keystore, why not use it for other things,
> too?
>
> Thanks!
> -dant
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Jonathan, Ohad -

Jonathan, I was using the -k option on purpose in an effort to reduce
noise during testing.

I''m familiar with CRLs, sure - just didn''t realize that Puppet
might
use one.  Thanks for letting me know, Ohad.

I''ve implemented the CRL that Puppet maintains, inside of this Apache
host, and things seem to work fine now:

Error code: ssl_error_handshake_failure_alert

This is good news.  Exactly what I was looking for.

Thanks again
-dant


On Thu, Dec 23, 2010 at 12:08 AM, Ohad Levy <ohadlevy@gmail.com>
wrote:
> with recent versions of puppet, when you clean a certificate, you also
> revoke it, you apache is simply not configured to look at the CRL
> (certificate revocation list).
> Ohad
>
> On Wed, Dec 22, 2010 at 11:43 PM, Dan Trainor <dan.trainor@gmail.com>
wrote:
>>
>> Hi -
>>
>> I read up on this subject quite a bit, and was able to find a few
>> posts on the mailing list, even found a wiki article.  Unfortunately
>> it doesn''t quite address what I''m looking to do.
>>
>> From what I understand, Puppet''s client/server authentication
system -
>> using SSL - is portable.  I believe that I should be able to use the
>> same SSL certificates and keys (and even the same CA) with regard to
>> other SSL/TLS connections, as well.
>>
>> In particular, I want to use Apache''s
''SSLVerifyClient require''
>> option, but not in my Mongrel setup, but for an entirely different SSL
>> site which also happens to be on the same machine as my Puppet master.
>>  Assuming both my Puppet master and my Puppet agent represent the
>> server and client in this connection, respectively, then I believe I
>> should be able to use that already-established and signed and trusted
>> SSL relationship to implement this additional site.  I do expect
>> problems with CN mismatches, but I can live with that.
>>
>> I''ve gone through the process of configuring an additional SSL
site in
>> Apache to use ''SSLVerifyClient require'', and mimicked
a request from a
>> Puppet node (previously signed, enrolled, and working) using curl.  I
>> used the Puppet generated cert and key from this Puppet node in the
>> argument, looking something like this:
>>
>> curl -k -v --cert certs/job01.vmserver02.dev.az.domain.local.pem --key
>> private_keys/job01.vmserver02.dev.az.toolbox.local.pem
>> https://10.1.0.165/test.htm
>>
>> I got a little smile that the request did in fact work without error
>> (save having the client use the CA certificiate - I''ll
re-visit that
>> later), but also concerned because I understand this should not have
>> worked.  I ran puppetca --clean against this particular Puppet
node''s
>> certificate, and expected it to just plain not work any more, and
>> thereby updating my Puppet master''s key store.
>>
>> Here''s that Apache configuration I was talking about:
>>
>> <VirtualHost 10.1.0.165:443>
>>        SSLEngine On
>>        SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
>>        SSLCertificateFile
>> /var/lib/puppet/ssl/certs/puppet01.ops.az.domain.local.pem
>>        SSLCertificateKeyFile
>> /var/lib/puppet/ssl/private_keys/puppet01.ops.az.domain.local.pem
>>        SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
>>        SSLVerifyClient require
>>        SSLVerifyDepth 1
>>        SSLOptions +StdEnvVars
>>        ErrorLog /var/log/httpd/ssltest-error.log
>>        CustomLog /var/log/httpd/ssltest-access.log combined
>> </VirtualHost>
>>
>> Pretty simple, right?  Am I doing this properly?
>>
>> A little background:  I am in the process of building AMIs for
>> Amazon''s EC2, which will eventually have VPN connections back
to a
>> secure scope/pool on our internal network.  I do not want to
>> distribute the VPN profiles, complete with usernames and passwords,
>> with the AMIs.  I want Puppet to run once, generate those certs on
>> both the agent and master, and make those available for a curl request
>> in my EC2 bootstrap script to download this VPN profile in a secure
>> manner.  I only want a signed client accessing this VPN profile (pcf
>> file) which is going to be live on the Internet (protected, of course,
>> by client certificate verification).
>>
>> I''m not sure why this doesn''t work as I expect it to.
 I was hoping to
>> get some feedback from someone who has gone down this route before, as
>> this is all pretty new to me.  If nothing more, I''m hoping to
be able
>> to get this working in this situation, so that I can reuse this
>> functionality for other projects.  If Puppet is already doing a good
>> job of maintaining a nice keystore, why not use it for other things,
>> too?
>>
>> Thanks!
>> -dant
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.