thr3ads.net - Puppet users - Warning for Fedora Core users [Oct 2007]

If this information is useful, please help other people find it:
Share via:

Alexander Taler

2007-Oct-10 09:37 UTC

Warning for Fedora Core users

Fedora Core 7 has just updated their Ruby package (was 1.8.6.36-3.fc7,
is now 1.8.6.110-3.fc7), and the upgrade broke my Puppet installation,
and there was a similar report from someone else.

Communications between the puppetmasterd and the puppetd running on
the same host broke down with the message:

   Could not retrieve configuration: Certificates were not trusted: hostname 
   not match with the server certificate

If anyone is interested in debugging this problem, I may be able to 
arrange access to a host which is exhibiting it.

Alex

David Lutterkort

2007-Oct-10 23:21 UTC

head link

Re: Warning for Fedora Core users

On Wed, 2007-10-10 at 15:07 +0530, Alexander Taler
wrote:> Fedora Core 7 has just updated their Ruby package (was 1.8.6.36-3.fc7,
> is now 1.8.6.110-3.fc7), and the upgrade broke my Puppet installation,
> and there was a similar report from someone else.
> 
> Communications between the puppetmasterd and the puppetd running on
> the same host broke down with the message:
> 
>    Could not retrieve configuration: Certificates were not trusted:
hostname
>    not match with the server certificate
> 
> If anyone is interested in debugging this problem, I may be able to 
> arrange access to a host which is exhibiting it.
It seems to all boil down to bz 313691 [1], which in turn addresses CVE
2007-5162 [2], which makes me think that this problem will hit users of
other distros sooner or later.

The bug there is that ruby didn''t verify that the common name on the
cert matched the host name to which the SSL connection was established.
In other words, you only have trouble if the CN on the cert is not the
name of the host the client connects to - often the case when your
clients connect to host ''puppet'' and that is a CNAME to
another host.

If my reading of post_connection_check
in /usr/lib/ruby/1.8/openssl/ssl.rb is correct, it should be possible to
fix this by adding ''subjectAltName'' extensions to the server
cert.
Changes are definitely needed in the way that the puppetmaster generates
the server cert.

David

[1] https://bugzilla.redhat.com/show_bug.cgi?id=313691 (the ticket has
some more useful references)
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5162

David Lutterkort

2007-Oct-11 00:03 UTC

head link

Re: Warning for Fedora Core users

On Wed, 2007-10-10 at 15:07 +0530, Alexander Taler
wrote:> If anyone is interested in debugging this problem, I may be able to 
> arrange access to a host which is exhibiting it.
Here''s one cheesy workaround, assuming your puppetmaster has a CNAME of
''puppet'' and all your clients connect to it by that name: (1)
on the
puppetmaster set ''certname = puppet'' in the puppetmasterd
section of
puppet.conf (2) restart the puppetmaster.

After that, clients should be able to connect again; though you can''t
use ''$servername'' in puppet: URL''s in your manifests,
since $servername
gets set to the hostname of the puppetmaster, and hostname verification
will fail when files are retrieved from the fileserver.

IOW, this is a short-term fix; long term, the server certificate needs
to carry subjectAltName''s.

David

<Derek.Whayman@barclayscapital.com>

2007-Oct-11 10:08 UTC

head link

Re: Warning for Fedora Core users

Hmmm.  This breaks one of my assumptions.  Given our (soon to be)
multi-Puppetmaster setup I had decided not to embrace a full PKI
hierarchy due to pressures of time.

I cloned the SSL identities of the master-master to all the other
masters.  Given I was using Apache+Mongrel I suffered no more than:

[Sun Sep 23 04:02:03 2007] [warn] RSA server certificate CommonName (CN)
`engpsr0000.intranetdev.barcapdev.com'' does NOT match server name!?

In the Apache ErrorLog.

Am I correct in thinking the other workaround is to use Apache as the
front-end?

Best regards,
Derek

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of David Lutterkort
Sent: 11 October 2007 00:21
To: alext@picorp.com; Puppet User Discussion
Subject: Re: [Puppet-users] Warning for Fedora Core users

On Wed, 2007-10-10 at 15:07 +0530, Alexander Taler
wrote:> Fedora Core 7 has just updated their Ruby package (was 1.8.6.36-3.fc7,
> is now 1.8.6.110-3.fc7), and the upgrade broke my Puppet installation,
> and there was a similar report from someone else.
> 
> Communications between the puppetmasterd and the puppetd running on 
> the same host broke down with the message:
> 
>    Could not retrieve configuration: Certificates were not trusted:
hostname >    not match with the server certificate
> 
> If anyone is interested in debugging this problem, I may be able to 
> arrange access to a host which is exhibiting it.
It seems to all boil down to bz 313691 [1], which in turn addresses CVE
2007-5162 [2], which makes me think that this problem will hit users of
other distros sooner or later.

The bug there is that ruby didn''t verify that the common name on the
cert matched the host name to which the SSL connection was established.
In other words, you only have trouble if the CN on the cert is not the
name of the host the client connects to - often the case when your
clients connect to host ''puppet'' and that is a CNAME to
another host.

If my reading of post_connection_check
in /usr/lib/ruby/1.8/openssl/ssl.rb is correct, it should be possible to
fix this by adding ''subjectAltName'' extensions to the server
cert.
Changes are definitely needed in the way that the puppetmaster generates
the server cert.

David

[1] https://bugzilla.redhat.com/show_bug.cgi?id=313691 (the ticket has
some more useful references) [2]
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5162

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

David Lutterkort

2007-Oct-11 21:21 UTC

head link

Re: Warning for Fedora Core users

On Thu, 2007-10-11 at 11:08 +0100, Derek.Whayman@barclayscapital.com
wrote:> Hmmm.  This breaks one of my assumptions.  Given our (soon to be)
> multi-Puppetmaster setup I had decided not to embrace a full PKI
> hierarchy due to pressures of time.
If all your clients use the same name to connect to the server (i.e.,
always ''puppet'' or always
''puppet.example.com'' but not a mix of both)
using the workaround I described should get you home free except you
can''t use URL''s like
''puppet://$servername/foo/bar/baz'' in your
manifests - if you avoid $servername and make those
''puppet:///foo/bar/baz'' everything should work, though I
haven''t tested
this last bit.
> I cloned the SSL identities of the master-master to all the other
> masters.
If they are all called ''puppet'' and you use DNS to make sure
that
resolves to the right name in each location, that should work. If not,
you''d need to set the certname in puppet.conf before starting each
individual puppetmaster.
>   Given I was using Apache+Mongrel I suffered no more than:
> 
> [Sun Sep 23 04:02:03 2007] [warn] RSA server certificate CommonName (CN)
> `engpsr0000.intranetdev.barcapdev.com'' does NOT match server
name!?
> 
> In the Apache ErrorLog.
>
> Am I correct in thinking the other workaround is to use Apache as the
> front-end?
That should work since the puppetmaster never sees an SSL request in
that setup, except for the Webrick instance that is used to sign certs -
you''d still have that issue there.

David

<Derek.Whayman@barclayscapital.com>

2007-Nov-12 14:03 UTC

head link

SSL subjectAltName (was RE: Warning for Fedora Core users)

To recap, the newest versions of Ruby (see below) check the hostname
strictly when connecting to a server.  If your $server is not exactly
what''s on the CN of the server cert, the connection is rejected.  Since
we tend to use CNAMEs and/or not use the FQDN when connecting, this is
going to sting badly when the newer Ruby filters down to our RHEL
packages.

I''ve confirmed that David L''s subjectAltName idea works for
sure.  In
sslcertificates.rb I add 

(when :server:)
ex << ef.create_extension("subjectAltName",
subject_alt_name.join(","))

Example:
subject_alt_name = %w{DNS:puppet DNS:puppet.intranet.barcapint.com
DNS:engpsr0142}

You can then see in the server cert:
# openssl x509 -noout -text -in
/var/lib/puppet/ssl/certs/engpsr0142.intranetdev.barcapdev.com.pem
...
            X509v3 Subject Alternative Name: 
                DNS:puppet, DNS:puppet.intranet.barcapint.com,
DNS:engpsr0142
...

And Lo, my Fedora 7 client verifies the certificate happily.

The unfortunate thing is that when you regenerate the cert you need to
have all your clients re-sign :-(

***************************************************
Question is, how should this be implemented?  Should there be a
configuration parameter that is a colon-separated list of DNS names for
your Puppetmaster?
***************************************************

And are there any SSL gurus out there how could suggest an architecture
that makes it easy for me to add more Puppetmasters as we keep on adding
new locations?  I suppose I should knuckle down to reading
http://reductivelabs.com/trac/puppet/wiki/MultipleCertificateAuthorities
again.

Regards,
Derek

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of David Lutterkort
Sent: 11 October 2007 00:21
To: alext@picorp.com; Puppet User Discussion
Subject: Re: [Puppet-users] Warning for Fedora Core users

On Wed, 2007-10-10 at 15:07 +0530, Alexander Taler
wrote:> Fedora Core 7 has just updated their Ruby package (was 1.8.6.36-3.fc7,
> is now 1.8.6.110-3.fc7), and the upgrade broke my Puppet installation,
> and there was a similar report from someone else.
> 
> Communications between the puppetmasterd and the puppetd running on 
> the same host broke down with the message:
> 
>    Could not retrieve configuration: Certificates were not trusted:
hostname >    not match with the server certificate
> 
> If anyone is interested in debugging this problem, I may be able to 
> arrange access to a host which is exhibiting it.
It seems to all boil down to bz 313691 [1], which in turn addresses CVE
2007-5162 [2], which makes me think that this problem will hit users of
other distros sooner or later.

The bug there is that ruby didn''t verify that the common name on the
cert matched the host name to which the SSL connection was established.
In other words, you only have trouble if the CN on the cert is not the
name of the host the client connects to - often the case when your
clients connect to host ''puppet'' and that is a CNAME to
another host.

If my reading of post_connection_check
in /usr/lib/ruby/1.8/openssl/ssl.rb is correct, it should be possible to
fix this by adding ''subjectAltName'' extensions to the server
cert.
Changes are definitely needed in the way that the puppetmaster generates
the server cert.

David

[1] https://bugzilla.redhat.com/show_bug.cgi?id=313691 (the ticket has
some more useful references) [2]
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5162

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

<Derek.Whayman@barclayscapital.com>

2007-Nov-12 16:59 UTC

head link

Re: SSL subjectAltName (was RE: Warning for Fedora Coreusers)

Just one crucial correction... You *don''t* need to re-sign client
certs,
etc. The server certificate *CAN* be regenerated without destroying the
trust relationship.  AFAICS both client and server certs are signed by
the CA certificate (which is left intact), *NOT* the Server certificate
and both client and server trust this.

What caught me out is that you need to put the FQDN - the CN - in the
subjectAltName of the Server cert, i.e. I added the last element to:
subject_alt_name = %w{DNS:puppet DNS:puppet.intranet.barcapint.com
DNS:engpsr0142 DNS:engpsr0142.intranetdev.barcapdev.com}

Otherwise you get the same old error when you remint the server cert.  I
wish I understood SSL a bit better :-/

That means, if we accept the design to have a new configuration
parameter "certaltnames" or similar (related to "certname")
leading to
subjectAltNames (as per below), we get

   * Fix to the problem for new installations
   * Server-only fix path for existing installations - just
patch/upgrade, then delete the old *SERVER* certs and restart
puppetmasterd - job done.

I am *greatly* relieved.

This also means I can avoid the MultipleCertificateAuthorities work
(sorry Jeff :-) and have a common CA, but multiple unique Server
certificates (one for each Puppetmaster) and have nodes work correctly
if the contact a different Puppetmaster by way of BigIP or migration or
whatever.  The server doesn''t care if it doesn''t have a copy
of the
client''s signed certificate!  No need even to copy files around.

Perhaps we also need a parameter certaltips too - going to IP:x.x.x.x in
the cert?  Opinions?
Do we want the Puppetmaster to add the certname to the subjectAltNames
array by default?

Derek

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of
Derek.Whayman@barclayscapital.com
Sent: 12 November 2007 14:04
To: puppet-users@madstop.com
Subject: [Puppet-users] SSL subjectAltName (was RE: Warning for Fedora
Coreusers)

To recap, the newest versions of Ruby (see below) check the hostname
strictly when connecting to a server.  If your $server is not exactly
what''s on the CN of the server cert, the connection is rejected.  Since
we tend to use CNAMEs and/or not use the FQDN when connecting, this is
going to sting badly when the newer Ruby filters down to our RHEL
packages.

I''ve confirmed that David L''s subjectAltName idea works for
sure.  In
sslcertificates.rb I add 

(when :server:)
ex << ef.create_extension("subjectAltName",
subject_alt_name.join(","))

Example:
subject_alt_name = %w{DNS:puppet DNS:puppet.intranet.barcapint.com
DNS:engpsr0142}

You can then see in the server cert:
# openssl x509 -noout -text -in
/var/lib/puppet/ssl/certs/engpsr0142.intranetdev.barcapdev.com.pem
...
            X509v3 Subject Alternative Name: 
                DNS:puppet, DNS:puppet.intranet.barcapint.com,
DNS:engpsr0142
...

And Lo, my Fedora 7 client verifies the certificate happily.

The unfortunate thing is that when you regenerate the cert you need to
have all your clients re-sign :-(

***************************************************
Question is, how should this be implemented?  Should there be a
configuration parameter that is a colon-separated list of DNS names for
your Puppetmaster?
***************************************************

And are there any SSL gurus out there how could suggest an architecture
that makes it easy for me to add more Puppetmasters as we keep on adding
new locations?  I suppose I should knuckle down to reading
http://reductivelabs.com/trac/puppet/wiki/MultipleCertificateAuthorities
again.

Regards,
Derek

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of David Lutterkort
Sent: 11 October 2007 00:21
To: alext@picorp.com; Puppet User Discussion
Subject: Re: [Puppet-users] Warning for Fedora Core users

On Wed, 2007-10-10 at 15:07 +0530, Alexander Taler
wrote:> Fedora Core 7 has just updated their Ruby package (was 1.8.6.36-3.fc7,
> is now 1.8.6.110-3.fc7), and the upgrade broke my Puppet installation,
> and there was a similar report from someone else.
> 
> Communications between the puppetmasterd and the puppetd running on 
> the same host broke down with the message:
> 
>    Could not retrieve configuration: Certificates were not trusted:
hostname >    not match with the server certificate
> 
> If anyone is interested in debugging this problem, I may be able to 
> arrange access to a host which is exhibiting it.
It seems to all boil down to bz 313691 [1], which in turn addresses CVE
2007-5162 [2], which makes me think that this problem will hit users of
other distros sooner or later.

The bug there is that ruby didn''t verify that the common name on the
cert matched the host name to which the SSL connection was established.
In other words, you only have trouble if the CN on the cert is not the
name of the host the client connects to - often the case when your
clients connect to host ''puppet'' and that is a CNAME to
another host.

If my reading of post_connection_check
in /usr/lib/ruby/1.8/openssl/ssl.rb is correct, it should be possible to
fix this by adding ''subjectAltName'' extensions to the server
cert.
Changes are definitely needed in the way that the puppetmaster generates
the server cert.

David

[1] https://bugzilla.redhat.com/show_bug.cgi?id=313691 (the ticket has
some more useful references) [2]
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5162

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information
about Barclays Capital, please visit our web site at
http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group
does not accept legal responsibility for the contents of this message.
Although the Barclays Group operates anti-virus programmes, it does not
accept responsibility for any damage whatsoever that is caused by
viruses being passed.  Any views or opinions presented are solely those
of the author and do not necessarily represent those of the Barclays
Group.  Replies to this email may be monitored by the Barclays Group for
operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank
PLC, a company registered in England (number 1026167) with its
registered office at 1 Churchill Place, London, E14 5HP. This email may
relate to or be sent from other members of the Barclays Group.
------------------------------------------------------------------------
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Luke Kanies

2007-Nov-12 17:33 UTC

head link

Re: SSL subjectAltName (was RE: Warning for Fedora Coreusers)

On Nov 12, 2007, at 10:59 AM, <Derek.Whayman@barclayscapital.com> wrote:
> That means, if we accept the design to have a new configuration
> parameter "certaltnames" or similar (related to
"certname") leading to
> subjectAltNames (as per below), we get
>
>    * Fix to the problem for new installations
>    * Server-only fix path for existing installations - just
> patch/upgrade, then delete the old *SERVER* certs and restart
> puppetmasterd - job done.
>
> I am *greatly* relieved.
This is good news.  I''ll make sure this makes it into the next  
release, but patches are heartily appreciated.

  --
  The trouble with the world is that the stupid are cocksure and the
  intelligent are full of doubt.    -- Bertrand Russell
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Matt Palmer

2007-Nov-12 22:12 UTC

head link

Re: SSL subjectAltName

On Mon, Nov 12, 2007 at 02:03:38PM -0000, Derek.Whayman@barclayscapital.com
wrote:> To recap, the newest versions of Ruby (see below) check the hostname
> strictly when connecting to a server.  If your $server is not exactly
> what''s on the CN of the server cert, the connection is rejected. 
Since
> we tend to use CNAMEs and/or not use the FQDN when connecting, this is
> going to sting badly when the newer Ruby filters down to our RHEL
> packages.
> 
> I''ve confirmed that David L''s subjectAltName idea works
for sure.  In
> sslcertificates.rb I add 
> 
> (when :server:)
> ex << ef.create_extension("subjectAltName",
subject_alt_name.join(","))
> 
> Example:
> subject_alt_name = %w{DNS:puppet DNS:puppet.intranet.barcapint.com
> DNS:engpsr0142}
What''s wrong with a wildcard altName?  It''s no less secure
than when Ruby
wasn''t checking the names at all, and let''s be honest -- the
number of
people who have been caught by SSL-related stuff-ups already (is there
*anyone* who hasn''t at some stage?) suggests that adding the complexity
of
specifying (and understanding) altNames is just going to make an already
painful situation a whole hell of a lot worse.

- Matt

-- 
Logan Shaw''s Zen of ASR Computing: free yourself of the desire to have
computers work properly for this is the root of all suffering.

<Derek.Whayman@barclayscapital.com>

2007-Nov-13 09:10 UTC

head link

Re: SSL subjectAltName

DNS:* certainly works.  As I say, I''m not familiar with the intricacies
of SSL so I missed this while trawling for doco.

The only downside is a theoretical security vulnerability.  Someone
could steal the server cert (but *not* the CA cert, yus) and impersonate
the Puppetmaster.  Given the layout of $ssldir this is highly unlikely.
And as you say, it''s what we had before.

Perhaps certaltnames, (or perhaps better "certdnsnames" along with
"certipaddresses") should default to * ?

Derek

N.B.  I''ve noticed many docs on t''interweb noting explicity
that that CN
is *NOT* matched against if the cert contains a subjectAltName.

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of Matt Palmer
Sent: 12 November 2007 22:13
To: puppet-users@madstop.com
Subject: Re: [Puppet-users] SSL subjectAltName

On Mon, Nov 12, 2007 at 02:03:38PM -0000,
Derek.Whayman@barclayscapital.com wrote:> To recap, the newest versions of Ruby (see below) check the hostname 
> strictly when connecting to a server.  If your $server is not exactly 
> what''s on the CN of the server cert, the connection is rejected.  
> Since we tend to use CNAMEs and/or not use the FQDN when connecting, 
> this is going to sting badly when the newer Ruby filters down to our 
> RHEL packages.
> 
> I''ve confirmed that David L''s subjectAltName idea works
for sure.  In
> sslcertificates.rb I add
> 
> (when :server:)
> ex << ef.create_extension("subjectAltName", 
> subject_alt_name.join(","))
> 
> Example:
> subject_alt_name = %w{DNS:puppet DNS:puppet.intranet.barcapint.com 
> DNS:engpsr0142}
What''s wrong with a wildcard altName?  It''s no less secure
than when
Ruby wasn''t checking the names at all, and let''s be honest --
the number
of people who have been caught by SSL-related stuff-ups already (is
there
*anyone* who hasn''t at some stage?) suggests that adding the complexity
of specifying (and understanding) altNames is just going to make an
already painful situation a whole hell of a lot worse.

- Matt

--
Logan Shaw''s Zen of ASR Computing: free yourself of the desire to have
computers work properly for this is the root of all suffering.
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

Luke Kanies

2007-Nov-13 21:03 UTC

head link

Re: SSL subjectAltName

On Nov 13, 2007, at 3:10 AM, <Derek.Whayman@barclayscapital.com>  
<Derek.Whayman@barclayscapital.com> wrote:
> DNS:* certainly works.  As I say, I''m not familiar with the  
> intricacies
> of SSL so I missed this while trawling for doco.
>
> The only downside is a theoretical security vulnerability.  Someone
> could steal the server cert (but *not* the CA cert, yus) and  
> impersonate
> the Puppetmaster.  Given the layout of $ssldir this is highly  
> unlikely.
> And as you say, it''s what we had before.
>
> Perhaps certaltnames, (or perhaps better "certdnsnames" along
with
> "certipaddresses") should default to * ?
I certainly find that pinning authentication to DNS is a recipe for  
long nights and lots of wasted effort.

I like the idea of defaulting to * and maybe providing an override  
that requires it if people are interested.

  --
  Meeting, n.:
          An assembly of people coming together to decide what person or
          department not represented in the room must solve a problem.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Frank Sweetser

2007-Nov-13 21:20 UTC

head link

Re: SSL subjectAltName

Luke Kanies wrote:> I like the idea of defaulting to * and maybe providing an override  
> that requires it if people are interested.
Personally, I wouldn''t feel that comfortable in doing this.  At a bare
minimum, this sounds to me like any one puppet node would be able to access
all resources that belong to all other nodes, making the fileserver ACLs
pretty meaningless.  At a minimum, I would much rather that the default
continue to be to require that the certname and hostname match, and then add a
"don''t care who connects to who" option instead.

In every other SSL enabled application I''ve used, it was a hard
requirement
that the names configured in the application and the names appearing in the
certificates lined up.  I was able to easily make that happen in puppet by
doing two things:

 - setting the certname parameter in the puppetmasterd section of the config
file to an FQDN (a service based CNAME in my case)
 - always point clients at that FQDN

I stuck to these requirements, and haven''t had any issue with the
certificate
rejection issue at all.

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
    GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC

Luke Kanies

2007-Nov-13 22:51 UTC

head link

Re: SSL subjectAltName

On Nov 13, 2007, at 3:20 PM, Frank Sweetser wrote:>
> Personally, I wouldn''t feel that comfortable in doing this.  At a
bare
> minimum, this sounds to me like any one puppet node would be able  
> to access
> all resources that belong to all other nodes, making the fileserver  
> ACLs
> pretty meaningless.  At a minimum, I would much rather that the  
> default
> continue to be to require that the certname and hostname match, and  
> then add a
> "don''t care who connects to who" option instead.
The only thing this does is remove the requirement that DNS names  
match certificate names, and even then it only affects authentication  
itself, not later uses of the certificate CN.

Requiring this linkage between cert names and DNS is a big pain in  
most environments and is even more painful to maintain over time.   
I''ve seen DNS breakages take out Cfengine networks more than just  
about anything else, and Cfengine''s authentication caused some of the  
biggest support nightmares, largely because it required DNS to match  
keys (I wrote the FAQ on this stuff for Cfengine).
> In every other SSL enabled application I''ve used, it was a hard  
> requirement
> that the names configured in the application and the names  
> appearing in the
> certificates lined up.  I was able to easily make that happen in  
> puppet by
> doing two things:
>
>  - setting the certname parameter in the puppetmasterd section of  
> the config
> file to an FQDN (a service based CNAME in my case)
>  - always point clients at that FQDN
>
> I stuck to these requirements, and haven''t had any issue with the
> certificate
> rejection issue at all.
Many Puppet users are currently using UUIDs for their certificate  
names, rather than hostnames, so this wouldn''t work for them.

Also, even though it will generally work, those cases where it  
doesn''t will come up far more often than you''d think.  Yes,
it''s
always possible to make it work, but that''s a far cry from it being  
consistent, easy, and supportable.

I''m all for making it so people can require hostnames to match cert  
names, but I''m not comfortable requiring it.

  --
  ''Tis better to be silent and be thought a fool, than to speak and
  remove all doubt.              --Abraham Lincoln
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Frank Sweetser

2007-Nov-13 23:11 UTC

head link

Re: SSL subjectAltName

Luke Kanies wrote:> Requiring this linkage between cert names and DNS is a big pain in  
> most environments and is even more painful to maintain over time.   
I guess that''s not an issue for me since I already have to deal with
that
requirement for other packages.
> I''ve seen DNS breakages take out Cfengine networks more than just
> about anything else, and Cfengine''s authentication caused some of
the
> biggest support nightmares, largely because it required DNS to match  
> keys (I wrote the FAQ on this stuff for Cfengine).
I''ll add that to the list of reasons I''m glad I
didn''t pick Cfengine =)
> Many Puppet users are currently using UUIDs for their certificate  
> names, rather than hostnames, so this wouldn''t work for them.
This would certainly make using a common set of certificates, as opposed to a
different cert for each SSL enabled service on the system, much more difficult.
> Also, even though it will generally work, those cases where it  
> doesn''t will come up far more often than you''d think. 
Yes, it''s
> always possible to make it work, but that''s a far cry from it
being
> consistent, easy, and supportable.
> 
> I''m all for making it so people can require hostnames to match
cert
> names, but I''m not comfortable requiring it.
I suppose that in the end, as long as it''s configurable, there really
isn''t
any reason to complain from either side.

	thanks

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
    GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC

Jeff McCune

2007-Nov-14 15:48 UTC

head link

Re: SSL subjectAltName

On Nov 13, 2007, at 5:51 PM, Luke Kanies wrote:
> I''m all for making it so people can require hostnames to match
cert
> names, but I''m not comfortable requiring it.

As a site using UUID''s for the certificate name, I support you fully  
in this decision.

Read on for the why...

To provide a bit of background, my motivation for UUID''s in  
certificate naming is that I view certificates in puppet differently  
than I view certificates in most other SSL applications.  Admittedly,  
the certificates are technically the same thing, but logically the  
difference to me is:

Traditional SSL tackles the problem of a client not being able to  
trust an arbitrary remote site is who they claim to be.  To this end,  
it''s important to verify that when I ask for (type in)  
"www.google.com" I am actually talking to a certified google server,  
and that server is in fact the one I requested to talk to.

With puppet, there still is the problem of verifying, in both  
directions, the client and server are who they claim to be, but we  
need not worry about typing in arbitrary DNS entries.  In fact, there  
isn''t really a need for DNS naming at all.

I make the fundamental assumption that my server private key remains  
private, and the CA private key remains private.  So long as that  
assumption holds, it doesn''t really matter if the certificate name  
matches DNS, as it''s just an arbitrary piece of information that  
provides little benefit and lots of headaches.

I don''t need to assume the client private key remains private, as  
puppet has a revocation infrastructure in place which handles the end  
of a clients life cycle.

If the possibility of facter "lying" exists, then perhaps additional  
attributes should be embedded into the certificate, but the choice of  
what those attributes are is arbitrary in my opinion, and DNS is just  
one of many possibilities.

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

<Derek.Whayman@barclayscapital.com>

2007-Nov-20 09:00 UTC

head link

Re: SSL subjectAltName

One last (I hope issue) to do with wildcards

* does *not* match puppet.domain.com
*.*.* does

*.*.*.* does *not* match puppet
* does

So you''re going to need something like
*:*.*:*.*.*:*.*.*.*:*.*.*.*.*:*.*.*.*.*.* and so on ad nauseum.  I''m
sure some of us have looong domains.

http://reductivelabs.com/trac/puppet/ticket/896 currently has a default
of just *

I''m for changing it to up to 6 component-domains as per the example.
Opinions?  It is starting to look ugly.

Must''ve missed this during testing - sorry!

Cheers,
Derek

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of Jeff McCune
Sent: 14 November 2007 15:48
To: Puppet User Discussion
Subject: Re: [Puppet-users] SSL subjectAltName

On Nov 13, 2007, at 5:51 PM, Luke Kanies wrote:
> I''m all for making it so people can require hostnames to match
cert
> names, but I''m not comfortable requiring it.

As a site using UUID''s for the certificate name, I support you fully in
this decision.

Read on for the why...

To provide a bit of background, my motivation for UUID''s in certificate
naming is that I view certificates in puppet differently than I view
certificates in most other SSL applications.  Admittedly, the
certificates are technically the same thing, but logically the
difference to me is:

Traditional SSL tackles the problem of a client not being able to trust
an arbitrary remote site is who they claim to be.  To this end, it''s
important to verify that when I ask for (type in) "www.google.com" I
am
actually talking to a certified google server, and that server is in
fact the one I requested to talk to.

With puppet, there still is the problem of verifying, in both
directions, the client and server are who they claim to be, but we need
not worry about typing in arbitrary DNS entries.  In fact, there isn''t
really a need for DNS naming at all.

I make the fundamental assumption that my server private key remains
private, and the CA private key remains private.  So long as that
assumption holds, it doesn''t really matter if the certificate name
matches DNS, as it''s just an arbitrary piece of information that
provides little benefit and lots of headaches.

I don''t need to assume the client private key remains private, as
puppet
has a revocation infrastructure in place which handles the end of a
clients life cycle.

If the possibility of facter "lying" exists, then perhaps additional
attributes should be embedded into the certificate, but the choice of
what those attributes are is arbitrary in my opinion, and DNS is just
one of many possibilities.

Cheers,
--
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
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

Luke Kanies

2007-Nov-20 16:05 UTC

head link

Re: SSL subjectAltName

On Nov 20, 2007, at 3:00 AM, <Derek.Whayman@barclayscapital.com> wrote:
> One last (I hope issue) to do with wildcards
>
> * does *not* match puppet.domain.com
> *.*.* does
>
> *.*.*.* does *not* match puppet
> * does
>
> So you''re going to need something like
> *:*.*:*.*.*:*.*.*.*:*.*.*.*.*:*.*.*.*.*.* and so on ad nauseum. 
I''m
> sure some of us have looong domains.
>
> http://reductivelabs.com/trac/puppet/ticket/896 currently has a  
> default
> of just *
>
> I''m for changing it to up to 6 component-domains as per the
example.
> Opinions?  It is starting to look ugly.
>
> Must''ve missed this during testing - sorry!
Anyone have any idea who we can mail bomb to help assuage this pain?

Gah.

Yeah, I think the six-part domains are sufficient, and if people have  
more than that, they''ll just have to configure it themselves.

Patch?

  --
  I went to a restaurant that serves "breakfast at anytime".  So I
  ordered French Toast during the Renaissance.     -- Stephen Wright
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Jeff McCune

2007-Nov-20 20:35 UTC

head link

Re: SSL subjectAltName

> Anyone have any idea who we can mail bomb to help assuage this pain?
>
> Gah.
>
> Yeah, I think the six-part domains are sufficient, and if people have
> more than that, they''ll just have to configure it themselves.
This isn''t biting me yet, but it will very soon...  So here goes.
> Patch?
I haven''t tested it yet...  I''m compiling the
"fixed" version of Ruby
now, but could someone who''s experiencing this problem please try:

http://reductivelabs.com/trac/puppet/attachment/ticket/896/fix-896-ssl_verify_fix.patch

Against 0.23.2, not against the git trunk.  I''ll publish my git  
repository shortly after I verify that patch actually fixes the problem.

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

Maybe Matching Threads

Search for more maybe matching threads

Puppet users - Oct 2007 - Warning for Fedora Core users

Warning for Fedora Core users

Re: Warning for Fedora Core users

Re: Warning for Fedora Core users

Re: Warning for Fedora Core users

Re: Warning for Fedora Core users

SSL subjectAltName (was RE: Warning for Fedora Core users)

Re: SSL subjectAltName (was RE: Warning for Fedora Coreusers)

Re: SSL subjectAltName (was RE: Warning for Fedora Coreusers)

Re: SSL subjectAltName

Re: SSL subjectAltName

Re: SSL subjectAltName

Re: SSL subjectAltName

Re: SSL subjectAltName

Re: SSL subjectAltName

Re: SSL subjectAltName

Re: SSL subjectAltName

Re: SSL subjectAltName

Re: SSL subjectAltName

Maybe Matching Threads