Thanks for reply.
From: Daniel DeLeo [mailto:firstname.lastname@example.org] On Behalf Of Daniel DeLeo
Sent: Monday, May 11, 2015 1:53 PM
Subject: [chef] Re: Upgrade Chef from 11.6 to 12.3
On Monday, May 11, 2015 at 10:36 AM, Mohammad Fattahian wrote:
When I upgrade Chef (on the clients) from 11.6 to 12.3 the connection to
server (Chef 11.6) broken.
Starting Chef Client, version 12.3.0
Creating a new client identity for test.domain.com
(http://test.domain.com) using the validator key.
[2015-05-07T16:46:17-04:00] ERROR: SSL Validation failure connecting
to host: xxxx.domain.com (http://xxxx.domain.com) - SSL_connect
returned=1 errno=0 state=SSLv3 read server certificate B: certificate
========== Chef encountered an error attempting to create the client "
test.domain.com (http://test.domain.com) "
[2015-05-07T16:46:17-04:00] FATAL: Stacktrace dumped to
Chef Client failed. 0 resources updated in 1.306760691 seconds
[2015-05-07T16:46:17-04:00] ERROR: SSL_connect returned=1 errno=0
state=SSLv3 read server certificate B: certificate verify failed
Chef::Exceptions::ChildConvergeError: Chef run process exited
unsuccessfully (exit code 1)
This isn’t a bug. In the past, chef-client did not verify the SSL
certificate of the server, which leaves you vulnerable to a MITM attack. If
you are sure you don’t need this protection (I would argue that
defense-in-depth means you should not turn this off, even if you’re only
connecting on a private network), then you can set the old default with
This is what I do to fix it:
- delete the node / client from Chef WEB Interface
This isn’t necessary, the client.pem is used for application-level
authentication, which is not relevant to the transport layer encryption.
- add “ssl_verify_mode :verify_peer” into client.rb (client side)
This isn’t necessary,
ssl_verify_mode :verify_peer is the default in Chef
- delete client.pm (http://client.pm) (client side)
Again, this isn’t required because the client.pem is only relevant to
application layer authentication.
- mkdir /etc/chef/trusted_certs/
- root@Cefh-server:/var/opt/chef-server/nginx/ca# scp server.crt
These two steps are all you need to do.
- knife bootstrap CLIENT --sudo -x toor
You only need this step because you’ve deleted the client/node on the
server, if you skip steps 1 and 3, then you don’t need this. FWIW, if you
have downloaded your Chef Server’s cert to your workstation and you’re
running knife 12+ on your workstation, it will copy your server’s cert to
the bootstrap node as part of the bootstrap process.
- To check the SSL configuration : knife ssl check -c
Any other workaround?
You can make knife download the certificates from the server with
knife ssl fetch. HOWEVER, this is only as good as clicking the “trust this
certificate for this server” from the security warning pop-up on a browser.
If you’re already MITM’d then you’re just trusting the MITM’s certificate.
If you use this command then you should take a SHA-256 of the cert on the
server and compare to what you downloaded.
I’ll look into having the error messages on the client provide some of this
information so it’s easier to resolve when this comes up.