Chef: Chef Client has no support for Self Signed SAN Certificates.

[jamesbjackson]

Versions

• Chef Standalone Server: 12.3.1 (Deb Package)
• Chef Development Kit: 0.10.0
• Chef Client: 12.5.1

Environment

• Chef Server: Ubuntu 14.04.1 LTS
• Workstation: Mac OSX v10.11.2 (Ruby 2.2.1 & OpenSSL 0.9.8zg 14 July 2015)

Issue
We have a Chef Server which has both public and private DNS names. such as chef.example.com (Public) & chef.example.cloud (Private). So with the certificates common name set to "chef.example.cloud" chef-clients on our private network work perfectly.

On our public side it is a different story onced I have fetched the certs using:

knife ssl fetch https://chef.example.com

Which give me the following expected output.

WARNING: Certificates from chef.example.com will be fetched and placed in your trusted_cert
directory (/Users/<USERNAME>/.chef/trusted_certs).

Knife has no means to verify these are the correct certificates. You should
verify the authenticity of these certificates after downloading.

Adding certificate for chef.example.cloud in /Users/<USERNAME>/.chef/trusted_certs/chef_example_cloud.crt

That works file. Then when i check the certificates using this command:

knife ssl check https://chef.example.com 

I get the following error which is not what I am expecting.

Connecting to host chef.example.com:443
ERROR: The SSL cert is signed by a trusted authority but is not valid for the given hostname
ERROR: You are attempting to connect to:   'chef.example.com'
ERROR: The server's certificate belongs to 'chef.example.cloud'

TO FIX THIS ERROR:

The solution for this issue depends on your networking configuration. If you
are able to connect to this server using the hostname chef.example.cloud
instead of chef.example.com, then you can resolve this issue by updating chef_server_url
in your configuration file.

If you are not able to connect to the server using the hostname chef.example.cloud
you will have to update the certificate on the server to use the correct hostname.

So next I verify the connection using OpenSSL s_client directly to check it not the certificate.

openssl s_client -port 443 -host chef.example.com -CAfile /Users/<USERNAME>/.chef/trusted_certs/chef_example_cloud.crt

I get a similar output to what is shown below.

CONNECTED(00000003)
depth=0 /C=US/ST=NewYork/L=NewYork/O=ExampleCompany/OU=DevOps Team/CN=chef.example.cloud/[email protected]/subjectAltName=DNS.1=chef.example.com
verify return:1

---
Certificate chain
 0 s:/C=US/ST=NewYork/L=NewYork/O=ExampleCompany/OU=DevOps Team/CN=chef.example.cloud/[email protected]/subjectAltName=DNS.1=chef.example.com
   i:/C=US/ST=NewYork/L=NewYork/O=ExampleCompany/OU=DevOps Team/CN=chef.example.cloud/[email protected]/subjectAltName=DNS.1=chef.example.com

---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEgzCCA2ugAwI .......... 1uxiodZKZQ==
-----END CERTIFICATE-----
subject=/C=US/ST=NewYork/L=NewYork/O=ExampleCompany/OU=DevOps Team/CN=chef.example.cloud/[email protected]/subjectAltName=DNS.1=chef.example.com
issuer=/C=US/ST=NewYork/L=NewYork/O=ExampleCompany/OU=DevOps Team/CN=chef.example.cloud/[email protected]/subjectAltName=DNS.1=chef.example.com

---
No client certificate CA names sent

---
SSL handshake has read 2114 bytes and written 456 bytes

---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES128-SHA
    Session-ID: 20CA00067CF071B185E30BD3CC9F42202893B2645F4BF59F12F94BB1FE3765D1
    Session-ID-ctx: 
    Master-Key: 5E3D97B1341004C4A9CE8A6A12673E608681D9F24B6D9892C84834985A2D35889AB87F37861636B2D52D01962457CD42
    Key-Arg   : None
    Start Time: 1453915540
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

---

To conclude OpenSSL is verifying my Certificate correctly but Chef only uses the common name to do SSL verification which is the issue. As I can't find a way other than SAN Certificates to have Chef Server have multiple single certificate on the same standalone server.

Any help would be most appreciated to enable this functionality.

[thommay]

Agreed, this looks like something we should fix.

[jamesbjackson]

Thanks thommay :)

[tas50]

I'm assigning this to the sustaining team to see if they can replicate this on a modern chef-client binary since the openssl ruby bindings have been significantly updated in the last few years.