SSL emailAddress interpreted as part of the CN when using puppet with an external PKI

[Andrew Wasilczuk]

Hello,

I'm currently integrating puppet with an external openssl based PKI and
I stumbled across a problem which looks like it may be a bug in puppet.

All my certificates contain an emailAddress field in the subject. Here
it is in the default format:


% openssl x509 -in mir.example.net.pem -noout -text -subject

subject= /C=UK/ST=Greater London/O=example/CN=mir.example.net/emailAddress=sys...@example.net


When I run puppet with stock auth.conf I get the following error message:


err: Could not retrieve catalog from remote server: Error 403 on SERVER:
Forbidden request: mir.example.net/emailAddress=sys...@example.net(46.4.3.59)
access to /catalog/mir.example.net [find] authenticated at line 52

If I modify my auth.conf to:


path ~ ^/catalog/([^/]+)$
method find
#allow $1
allow /$1\/email/


It works fine:


info: Caching catalog for mir.example.net
info: Applying configuration version '1338465941'
notice: Finished catalog run in 0.08 seconds


It looks like puppet is interpreting emailAddress as a part of the CN
(which it isn't). Outputting the subject in rfc2253 format makes it a
bit clearer:


% openssl x509 -in mir.example.net.pem -noout -text -subject -nameopt RFC2253

subject= emailAddress=sys...@example.net,CN=mir.example.net,O=example,ST=Greater London,C=UK


Has anyone else come across this? Shall I open a bug or am I doing
something stupid here?

As far as I'm aware OpenSSL will put email address in the subject line
by default, unless explicitly disabled.

I'm running puppet-2.7.14 on FreeBSD 9.0 behind Apache and Passenger

Cheers,

Andrew.
--
[ a...@zx23.net ]

[Jeff McCune]

There are two identities in Puppet that relate to the security model. The first identity is the certname and the second is the node name.

Puppet uses the certname to construct the certificate.

Everything else (catalogs, facts, reports, etc...) is identified by the node name.

By default the value of node name is the value of the certname.

For security, requests are only authorized if the name of the node matches the cert name.

What you're seeing is puppet denying access because your node name no longer matches the cert name.

I recommend you don't make your node names match your cert names because an email address is not a valid node name.  To get this to work you'll need to hack at auth.conf to map which cert names are authorized to request resources for certain nodes.

Hope this helps.

You might want to take a look at #2128 and the node_name_value setting.

There's also a whole section on auth.conf at docs.puppetlabs.com.

--
Jeff McCune

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To post to this group, send email to puppet...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Andrew Wasilczuk]

Hi Jeff

On Thu, May 31, 2012 at 08:55:29AM -0700, Jeff McCune wrote:
> There are two identities in Puppet that relate to the security model. The
> first identity is the certname and the second is the node name.
> Puppet uses the certname to construct the certificate.
> Everything else (catalogs, facts, reports, etc...) is identified by the
> node name.
> By default the value of node name is the value of the certname.
> For security, requests are only authorized if the name of the node matches
> the cert name.
> What you're seeing is puppet denying access because your node name no
> longer matches the cert name.
> I recommend you don't make your node names match your cert names because
> an email address is not a valid node name. To get this to work you'll
> need to hack at auth.conf to map which cert names are authorized to
> request resources for certain nodes.
> Hope this helps.
> You might want to take a look at #2128 and the node_name_value setting.

Thanks for your reply Jeff but I don't quite understand because as far
as I can tell my cert name and node name are the same:


subject=emailAddress=sys...@example.net,CN=mir.example.net,O=example,ST=Greater London,C=UK

% facter fqdn
mir.example.net


I'm assuming that by cert name you mean the common name (CN)?

I'm no SSL expert but I'm aware that having the email address in the
subject of the certificate is deprecated (although still the default in
OpenSSL for some reason). rfc3850[1] strongly suggest moving the
emailAddress to subjectAltName extension.

So, I'm going to update my PKI to the rfc3850 recommendation (or drop
the emailAddress completely as I don't think it's necessary for host
certs anyway). However, I was just wandering if it's worth for puppet
to support the legacy way since it's the default in OpenSSL and it's
likely that other people will hit this problem. I've got the luxury of
being able to re-generate my certs relatively easily but someone else
may not be as lucky, if they are trying to re-use their existing
certificates with puppet.

I guess it all boils down to how much work it would take to support this
in puppet and if it's puppet or the Ruby OpenSSL bindings that need the
work.


Cheers,

Andrew.
--
[ a...@zx23.net ]

[Jeff McCune]

On Fri, Jun 1, 2012 at 5:23 AM, Andrew Wasilczuk <a...@zx23.net> wrote:

Hi Jeff

On Thu, May 31, 2012 at 08:55:29AM -0700, Jeff McCune wrote:
>    There are two identities in Puppet that relate to the security model. The
>    first identity is the certname and the second is the node name.
>    Puppet uses the certname to construct the certificate.
>    Everything else (catalogs, facts, reports, etc...) is identified by the
>    node name.
>    By default the value of node name is the value of the certname.
>    For security, requests are only authorized if the name of the node matches
>    the cert name.
>    What you're seeing is puppet denying access because your node name no
>    longer matches the cert name.
>    I recommend you don't make your node names match your cert names because
>    an email address is not a valid node name.  To get this to work you'll
>    need to hack at auth.conf to map which cert names are authorized to
>    request resources for certain nodes.
>    Hope this helps.
>    You might want to take a look at #2128 and the node_name_value setting.

Thanks for your reply Jeff but I don't quite understand because as far
as I can tell my cert name and node name are the same:

The "certname" in Puppet is actually the x.509 common name field in the certificate.

You may be running into a bug in Puppet but I'm not entirely sure yet...

What web server are you using to terminate the SSL connection from the agent to the master?  Is it simply the built in one provided by `puppet master` or are you using Apache or something?

It appears that we're not correctly parsing out the emailAddress field inside the subject and instead we're treating it as part of the common name (CN).

-Jeff

[Andrew Wasilczuk]

Hi Jeff,

> You may be running into a bug in Puppet but I'm not entirely sure yet...
> What web server are you using to terminate the SSL connection from the
> agent to the master? Is it simply the built in one provided by `puppet
> master` or are you using Apache or something?

SSL is terminated by Apache. My Apache config is similar to what comes with
puppet in ext/rack/files/apache2.conf, and contains:

RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e

My puppet.conf contains:

ssl_client_header = SSL_CLIENT_S_DN_
ssl_client_verify_header = SSL_CLIENT_VERIFY

in the [master] section.

> It appears that we're not correctly parsing out the emailAddress field
> inside the subject and instead we're treating it as part of the common
> name (CN).

Yup, that's what it looks like.


Cheers,

Andrew.
--
[ a...@zx23.net ]

[Jeff McCune]

Andrew,

This is definitely a bug. The regular expression we're using to
extract the common name (CN) from the distinguished name (DN) is
/^.*?CN\s*=\s*(.*)/ [1]

This is a greedy regular expression which explains why it's also
grabbing the email address. I think we need to fix this to only match
up to the next / character or the end of the string.

Before I go fix this right now, are we sure this is a valid encoding
for the fields in the DN? What software are you using to produce
these certificates?

I've filed the bug here and added you as a watcher Andrew:
http://projects.puppetlabs.com/issues/14852

[1] https://github.com/puppetlabs/puppet/blob/master/lib/puppet/network/http/rack/rest.rb#L89

-Jeff

[Andrew Wasilczuk]

Hi Jeff,

> This is definitely a bug. The regular expression we're using to
> extract the common name (CN) from the distinguished name (DN) is
> /^.*?CN\s*=\s*(.*)/ [1]
>
> This is a greedy regular expression which explains why it's also
> grabbing the email address. I think we need to fix this to only match
> up to the next / character or the end of the string.
>
> Before I go fix this right now, are we sure this is a valid encoding
> for the fields in the DN? What software are you using to produce
> these certificates?

I made those certs with OpenSSL (0.9.8q) and that's the default encoding
it'll use, unless explicitly configured to move emailAddress to
subjectAltName[1] (as recommended in RFC 3850) or if one sets -noemailDN
option[2].

> I've filed the bug here and added you as a watcher Andrew:
> http://projects.puppetlabs.com/issues/14852
>
> [1] https://github.com/puppetlabs/puppet/blob/master/lib/puppet/network/http/rack/rest.rb#L89

Great, thanks.

Andrew.

[1] http://www.macfreek.nl/memory/Email_in_certificates
[2] http://www.mail-archive.com/opens...@openssl.org/msg10075.html
--
[ a...@zx23.net ]