Knife ssl check/fetch/check against a self-signed winrm ssl-transport host fails

Chef Infra (archive)
1

My goal is to securely connect to windows boxes from chef-provisioning (aws),
but I thought I’d try and connect via knife first.

I noticed that even after the knife ssl fetch, knife refuses to use
the self-signed-cert.

‘’’

  • trusted_certs_dir: "/home/hh/provisioning/.chef/trusted_certs"
    WARNING: There are invalid certificates in your trusted_certs_dir.
    OpenSSL will not use the following certificates when verifying SSL connections:

/home/hh/provisioning/.chef/trusted_certs/ip-0A7146CD.crt: self signed
certificate
’’’

knife ssl check/fetch/check followed by openssl s_client check:

‘’’
$ knife ssl check https://10.113.70.205:5986
Connecting to host 10.113.70.205:5986
ERROR: The SSL certificate of 10.113.70.205 could not be verified
Certificate issuer data: /CN=ip-0A7146CD

Configuration Info:

OpenSSL Configuration:

  • Version: OpenSSL 1.0.2a 19 Mar 2015
  • Certificate file: /etc/ssl/cert.pem
  • Certificate directory: /etc/ssl/certs
    Chef SSL Configuration:
  • ssl_ca_path: nil
  • ssl_ca_file: nil
  • trusted_certs_dir: “/home/hh/provisioning/.chef/trusted_certs”

TO FIX THIS ERROR:

If the server you are connecting to uses a self-signed certificate, you must
configure chef to trust that server’s certificate.

By default, the certificate is stored in the following location on the host
where your chef-server runs:

/var/opt/opscode/nginx/ca/SERVER_HOSTNAME.crt

Copy that file to your trusted_certs_dir (currently:
/home/hh/stratalux/lifelock/misc/provisioning/.chef/trusted_certs)
using SSH/SCP or some other secure method, then re-run this command to confirm
that the server’s certificate is now trusted.
’’’

‘’’
$ knife ssl fetch https://10.113.70.205:5986
WARNING: Certificates from 10.113.70.205 will be fetched and placed in
your trusted_cert
directory (/home/hh/provisioning/.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 ip-0A7146CD in
/home/hh/provisioning/.chef/trusted_certs/ip-0A7146CD.crt
’’’

‘’’
$ knife ssl check https://10.113.70.205:5986

Configuration Info:

OpenSSL Configuration:

  • Version: OpenSSL 1.0.2a 19 Mar 2015
  • Certificate file: /etc/ssl/cert.pem
  • Certificate directory: /etc/ssl/certs
    Chef SSL Configuration:
  • ssl_ca_path: nil
  • ssl_ca_file: nil
  • trusted_certs_dir: "/home/hh/provisioning/.chef/trusted_certs"
    WARNING: There are invalid certificates in your trusted_certs_dir.
    OpenSSL will not use the following certificates when verifying SSL connections:

/home/hh/provisioning/.chef/trusted_certs/ip-0A7146CD.crt: self signed
certificate

TO FIX THESE WARNINGS:

We are working on documentation for resolving common issues uncovered here.

  • If the certificate is generated by the server, you may try redownloading the
    server’s certificate. By default, the certificate is stored in the following
    location on the host where your chef-server runs:

    /var/opt/opscode/nginx/ca/SERVER_HOSTNAME.crt

Copy that file to your trusted_certs_dir (currently:
/home/hh/misc/provisioning/.chef/trusted_certs)
using SSH/SCP or some other secure method, then re-run this command to confirm
that the server’s certificate is now trusted.

Connecting to host 10.113.70.205:5986
ERROR: The SSL certificate of 10.113.70.205 could not be verified
Certificate issuer data: /CN=ip-0A7146CD
Configuration Info:

OpenSSL Configuration:

  • Version: OpenSSL 1.0.2a 19 Mar 2015
  • Certificate file: /etc/ssl/cert.pem
  • Certificate directory: /etc/ssl/certs
    Chef SSL Configuration:
  • ssl_ca_path: nil
  • ssl_ca_file: nil
  • trusted_certs_dir: “/home/hh/provisioning/.chef/trusted_certs”

TO FIX THIS ERROR:

If the server you are connecting to uses a self-signed certificate, you must
configure chef to trust that server’s certificate.

By default, the certificate is stored in the following location on the host
where your chef-server runs:

/var/opt/opscode/nginx/ca/SERVER_HOSTNAME.crt

Copy that file to your trusted_certs_dir (currently:
/home/hh/provisioning/.chef/trusted_certs)
using SSH/SCP or some other secure method, then re-run this command to confirm
that the server’s certificate is now trusted.
’’’

‘’’
$ openssl s_client -connect 10.113.70.205:5986 -CAfile
.chef/trusted_certs/ip-0A7146CD.crt -verify_return_error
CONNECTED(00000003)
depth=0 CN = ip-0A7146CD
verify error:num=18:self signed certificate

Certificate chain
0 s:/CN=ip-0A7146CD
i:/CN=ip-0A7146CD

Server certificate
-----BEGIN CERTIFICATE-----
MIIC2jCCAcKgAwIBAgIQYoe1RTcKKbZBnf3F2D8uKTANBgkqhkiG9w0BAQUFADAW
MRQwEgYDVQQDEwtpcC0wQTcxNDZDRDAeFw0xNTA5MjgwOTQxMDZaFw0xNjAzMjkw
OTQxMDZaMBYxFDASBgNVBAMTC2lwLTBBNzE0NkNEMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA3wXVQvW7WMeFyMSG0rW6cKHNLcmrgGENYT7AqLZeAGGk
8DELNAOJ69/4OBuJy79WLapEXhkSvp4W1IvrV44tkYPh427thuuaYMJdETrTtoFy
x+RxON1DWyfxQmXeDt/DKQH5V7S96IJ/5CylqR5+nVYwVQRXq0PkVfZmoJgZGgCT
e84bbdvGc/TZk9iuuMT+Y483tRRY+OtpPWjm+WB3ReJq88p+e2PASqknowHhv9Jk
1M2IRFbDMe9QpPCnb/Ysv/v6wxJlgVAxk5DYcuzH4sjRxbsyIxtcTah/qHZu6y9l
+Wu6o9rGaVb/Zn2zugpU8LQbJCC4qecUT2bNLDJ+2wIDAQABoyQwIjATBgNVHSUE
DDAKBggrBgEFBQcDATALBgNVHQ8EBAMCBDAwDQYJKoZIhvcNAQEFBQADggEBAGUk
aZ6rrVF71QYnY9eKrLH4N/an+UokUf2uroIzioebOskgBmBwgbCHxMf4q2QvFtUw
DTH2J3kc1l7sYIAbOcmbTjCXf+w0jxx0IkNtyGCcXNLCnnjHfGuKM4YAMWHlGyU1
SPm3LmSm5pQUtaw/SULJ7kq0jGmoN3e4OefonNFXWDYMznvq8l7DQgGip2xo8B9O
fb9s1XDxNE7NMBq8YSWvmZMUa7WRuNZ0xP0N25chjkVTE85ZV15Gpsa3MSTMpKby
uPL/1RjalhU0gmFBelHWl2HrLNZ+08V9Y/9NY54CwbgmRn3mMYjeRVKRVR4qeuR0
tDRU7VSnkOWTmCeFR5c=
-----END CERTIFICATE-----
subject=/CN=ip-0A7146CD
issuer=/CN=ip-0A7146CD

No client certificate CA names sent
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits

SSL handshake has read 1274 bytes and written 500 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
Session-ID: 233700001E82A6DBE277D444B7BA326E8F228A5E23C083CB4477C57FBE72EFCF
Session-ID-ctx:
Master-Key:
6F5A06DF8BB1E271D078C7BFDFDC04AEAE6914808F305A3876277B89067E5325BFF11ECDE0AC3ECAB977DADAE17AA139
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1443521077
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)

‘’’

2

On Tuesday, September 29, 2015 at 3:09 AM, Chris McClimans wrote:

My goal is to securely connect to windows boxes from chef-provisioning (aws),
but I thought I'd try and connect via knife first.

I noticed that even after the knife ssl fetch, knife refuses to use
the self-signed-cert.

Ugh, so at least part of the problem you’re seeing is that knife rescues all OpenSSL certificate errors, and assumes they happened when contacting the Chef Server over HTTPS. Using that assumption, it suggests that you run knife ssl fetch, which pulls down the certs and stores them so they’ll be added to the trust store for Chef’s HTTP stack. In your case, it appears that the issue is with the WinRM transport, which doesn’t know anything about the trusted_certs_dir, therefore the remediation steps that knife tells you to run are incorrect.

Unfortunately, we would need to make a lot of changes in order to fix this in the most correct way. Probably the best solution is for knife-windows to catch errors from winrm and wrap them in a different error class so they don’t hit knife’s top-level error handling code.

'''

  • trusted_certs_dir: "/home/hh/provisioning/.chef/trusted_certs"
    WARNING: There are invalid certificates in your trusted_certs_dir.
    OpenSSL will not use the following certificates when verifying SSL connections:

/home/hh/provisioning/.chef/trusted_certs/ip-0A7146CD.crt: self signed
certificate
'''

This happens when a self-signed certificate doesn’t have the correct extended attributes to be able to trust itself. For HTTPS, this is a problem, but might not be for WinRM connections. However, as I said above, the ruby winrm library won’t use this cert anyway.

I’m not very familiar with bootstrapping windows instances with WinRM, so I can’t say what the recommended way to actually fix the root issue would be.

--
Daniel DeLeo