Problem with clients authentication to the server

Hi there,

we’ve been trying to get Chef on and going in my Company since Joshua
Sierles’ presentation at EuRuKo this month, and we’ve encountered a brick
wall which I’d like to share with you and see if anyone can help.

The problem is explained in this gist http://gist.github.com/118534

I’ve been trying all this in amazon ec2 small instances with a 9.04 ubuntu
from alestic. I’ve managed to get the server and a client working,
installing everything with chef-solo (except for couchdb in the server, but
that’s fixed installig the package manually). The client appears in the
registrations section of the admin, and I validate it successfully, both
manually and automatically with the validation_token config attribute.

After that I cannot see any nodes on the rest of the sections. The client
gives the error you can see on the gist, and the server’s merb log is there
aswell. That line seems to be where openid is trying to authenticate the
client (line 44 of openid_consumer.rb)

I’ve trying plenty of things and none has worked so far.

Any help would be most welcome, since I’m starting to understand how the
whole chef thing works, but things like these scare the hell out of us.

Thanks a lot!


Albert Llop

Hi Albert,
I'm new to chef as well and had the same issue testing chef on 2 VMs on my
laptop. I tracked it down to the SSL certs that chef generated on the server
having ``server_fqdn'' in the CN field.

To fix it, I first corrected my chef.json file so that all of the fields in
the "server_ssl_req" property were correct. Next, I had to delete the old
certs under /etc/chef/certificates/* (three files here). When I reran the
chef-solo command, it regenerated the certs with the correct FQDN and
everything started working correctly.

Basically the issue boils down to man in the middle/phishing protection in
SSL; I believe the chef server is contacting itself for OpenID stuff using
the hostname you declared in the "server_fqdn" field of the chef.json file.
When it gets back a certificate, the CN on the cert is expected to match the
hostname; if it doesn't, then something fails and you get the 400 error.

Again, I'm new to chef, so I could be wrong about where chef is getting the
configuration info, but I'm pretty solid on the SSL part.

OT for this thread, but--for the list managers: Any way the archives could
be made available to googlebot and the like? It would surely make the
combined knowlege of the list more accessible. I get the bit about spam
harvesting, but I consider being able to seach blogs, list archives, etc.
simultaneously via one search engine a bigger win than having my email
harvested is a loss.

HTH,
Dan DeLeo

On Thu, May 28, 2009 at 1:27 AM, Albert Llop mrsimo@gmail.com wrote:

Hi there,

we've been trying to get Chef on and going in my Company since Joshua
Sierles' presentation at EuRuKo this month, and we've encountered a brick
wall which I'd like to share with you and see if anyone can help.

The problem is explained in this gist client cli · GitHub

--
Albert Llop

I'll look into it, thanks!

~Nathan

On Mon, Jun 1, 2009 at 10:04 AM, Daniel DeLeo devnullian@gmail.com wrote:

OT for this thread, but--for the list managers: Any way the archives could
be made available to googlebot and the like? It would surely make the
combined knowlege of the list more accessible. I get the bit about spam
harvesting, but I consider being able to seach blogs, list archives, etc.
simultaneously via one search engine a bigger win than having my email
harvested is a loss.

HTH,
Dan DeLeo

--
Nathan Haneysmith | www.opscode.com
nathan@opscode.com | 206.508.4799

OpsCode Inc
119 1st Avenue S, Suite 100
Seattle, WA 98104

Thanks a LOT Daniel,

you were completely right, somehow I was completely ignoring the
server_ssl_req attribute and the cert wasn't getting properly generated. I
managed to get a server/client working, and installed a cookbook in the
client through the server web admin, so the world is a better place now.

This is going to make our lives easier (or so we hope), so again, thanks!

It'd be wonderful if this kind of error receives the proper notification
somehow, maybe on the cert generation step? You shouldn't let anyone
generate a cert with a CN that doesn't look like a domain.

Anyhow, awesome work guys!

2009/6/1 Nathan Haneysmith nathan@opscode.com

I'll look into it, thanks!

~Nathan

On Mon, Jun 1, 2009 at 10:04 AM, Daniel DeLeo devnullian@gmail.com
wrote:

OT for this thread, but--for the list managers: Any way the archives
could
be made available to googlebot and the like? It would surely make the
combined knowlege of the list more accessible. I get the bit about spam
harvesting, but I consider being able to seach blogs, list archives, etc.
simultaneously via one search engine a bigger win than having my email
harvested is a loss.

HTH,
Dan DeLeo

--
Nathan Haneysmith | www.opscode.com
nathan@opscode.com | 206.508.4799

OpsCode Inc
119 1st Avenue S, Suite 100
Seattle, WA 98104

--
Albert Llop

We'll file a bug and update the install process. Thanks, Albert!

Adam

On Tue, Jun 2, 2009 at 1:39 AM, Albert Llop mrsimo@gmail.com wrote:

Thanks a LOT Daniel,

you were completely right, somehow I was completely ignoring the
server_ssl_req attribute and the cert wasn't getting properly generated. I
managed to get a server/client working, and installed a cookbook in the
client through the server web admin, so the world is a better place now.

This is going to make our lives easier (or so we hope), so again, thanks!

It'd be wonderful if this kind of error receives the proper notification
somehow, maybe on the cert generation step? You shouldn't let anyone
generate a cert with a CN that doesn't look like a domain.

Anyhow, awesome work guys!

2009/6/1 Nathan Haneysmith nathan@opscode.com

I'll look into it, thanks!

~Nathan

On Mon, Jun 1, 2009 at 10:04 AM, Daniel DeLeo devnullian@gmail.com
wrote:

OT for this thread, but--for the list managers: Any way the archives
could
be made available to googlebot and the like? It would surely make the
combined knowlege of the list more accessible. I get the bit about spam
harvesting, but I consider being able to seach blogs, list archives,
etc.
simultaneously via one search engine a bigger win than having my email
harvested is a loss.

HTH,
Dan DeLeo

--
Nathan Haneysmith | www.opscode.com
nathan@opscode.com | 206.508.4799

OpsCode Inc
119 1st Avenue S, Suite 100
Seattle, WA 98104

--
Albert Llop

--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-4759 E: adam@opscode.com

On Tue, Jun 2, 2009 at 9:51 AM, Adam Jacob adam@opscode.com wrote:

We'll file a bug and update the install process. Thanks, Albert!

Adam

On Tue, Jun 2, 2009 at 1:39 AM, Albert Llop mrsimo@gmail.com wrote:

It'd be wonderful if this kind of error receives the proper notification
somehow, maybe on the cert generation step? You shouldn't let anyone
generate a cert with a CN that doesn't look like a domain.

Other responses that could be helpful:

  • Unless there are use-cases for server_fqdn != cert CN, error out if they
    don't match. Maybe a big fat warning would be more appropriate than erroring
    out.
  • Do some magic and fill in the cert CN with the value from server_fqdn
    under the right conditions (like CN=server_fqdn)
  • rescue the "name does not match" error and re-raise it with a more useful
    message. I was confused by the 400/bad request response (I now suspect that
    happened internally on the server and the response actually returned to the
    client was 500, but confusing nonetheless) which at first glance seemed to
    imply the client was in the wrong. I also spent some time wondering "name
    does not match WHAT, EXACTLY?"

Again, I'm new here, so I don't know if these are good ideas, they're just
what first came to my mind as solutions.

Thanks,
Dan