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 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:
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.
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.
A picture is worth a thousand words, so here is a visual look at what the new model looks like:
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.