We are happy to announce significant updates to how TLS certificates are handled in the Chef Habitat 0.85 release. The changes simplify the process of ensuring custom enterprise certificates (self-signed, or otherwise) are utilized appropriately in the Habitat ecosystem.
While the new certificate handling model may not address every scenario, it should go a long way to making the certificate handling simpler and less error-prone.
In addition, the changes are fully backward compatible – if you have existing certificates, you can expect them to continue to work after upgrading to Habitat 0.85.
Prior TLS Certificate Handling Model
Prior to Chef Habitat 0.85, the way Habitat has dealt with certificates was restricted to using the contents of the installed `core/cacerts` package, with some exceptions.
One of these exceptions included the use of the `SSL_CERT_FILE` environment variable – if set to point to a valid cert file, it was used instead of the `core/cacerts` package.
This model exposed a number of issues:
- If there is a custom certificate already installed on the system, it is ignored unless it is pointed to specifically by either adding it to the `core/cacerts` package, or pointing to it via an environment variable
- Installed packages are supposed to be immutable – so making modifications to `core/cacerts` is an anti-pattern
- Even if the cacerts package is modified, or an environment variable used, it does not propagate inside the Studio, so the problem would re-exhibit and have to be solved all over again
- The cert handling is inconsistent across platforms – for example, on Windows, the `SSL_CERT_FILE` variable is not honored by the underlying communication library, and for Mac OS/X the Habitat client cannot connect to the Builder endpoint without having the `SSL_CERT_FILE` explicitly set up
New Chef Habitat TLS Certificate Handling Functionality
Chef Habitat 0.85 makes the certificate model more permissive and easier to use for a variety of scenarios.
The first significant change is that the Habitat client (we include the `hab` Client, Supervisor and Studio in that definition) respects the certificates that are installed on the system it is running on. So, for example, if there is a custom enterprise certificate that has already been pre-installed on the system (let’s say, in the Windows Certificate Store on a Windows OS), then that will be utilized automatically.
The second change is that the Habitat client will also start looking for certificates in a Habitat-specific SSL certificate cache location – for example, `/hab/cache/ssl` (or `~/.hab/cache/ssl`) on Linux, or `C:\hab\cache\ssl` on a Windows system. Any valid certificates in the `PEM` or `DER` formats will be added to the list of certificates that will be used when negotiating a TLS connection. This means that an admin can easily drop any certificate files that are needed into the cache folder, and have it just work.
The third change is that the `cache/ssl` folder and the `SSL_CERT_FILE` environment variable (if it exists) will get automatically propagated to a Studio environment. If the `SSL_CERT_FILE` points to a valid cert file, that file will get copied over the the `cache/ssl` folder inside the Studio, and the environment variable path will get adjusted to point to the file inside the Studio.
What about Chef Habitat Builder?
Chef Habitat Builder (specifically, on-premises Builder installations) will also benefit from the new certificate model.
The main scenarios for Habitat Builder installations are the cases where Habitat Builder services need to reach out to external endpoints – for example, an OAuth endpoint that may be set up with a custom TLS certificate.
Prior to now, if you were in such a situation, the guidance was to make a modification to the installed `core/cacerts` package to add in the custom certificates.
With the new model, you can elect to either install the needed certificates on the system, or copy them over to the `/hab/cache/ssl` directory to make them available for use by Builder.
Architecture
A picture is worth a thousand words, so here is a visual look at what the new model looks like:
Feedback and support
As always, we welcome your feedback and open issues – on our Habitat Forum, on our Slack channel, or directly at one of our Github repos.