TLS utility provider

[apparentlymart]

The TLS provider has general utility resources for TLS provisioning.

In this first implementation it contains only logical resources to aid in the creation of private keys (for testing/development only), self-signed certificates and certificate requests. These can then be used with other providers to create TLS-enabled resources.

• tls_private_key resource
• tls_self_signed_cert resource
• tls_cert_request resource
• Tests
• Docs

This provider could also be a reasonable home for an implementation of the new LetsEncrypt ACME protocol once it stabilizes, allowing "real" CA-issued certificates to be created too. However, I won't add that at least until LetsEncrypt has released a first stable version of its own client in Python.

[phinze]

Wow. This is great work, @apparentlymart. Wow.

Will get one of us to circle back for a more detailed review, but on first pass this looks darn near perfect.

Thank you!

[apparentlymart]

Over in #3599 I wrote a little about how this might be extended to work with Let's Encrypt and ACME, though I'd still like to merge this logical-only patch first and then we can build on it in separate changesets to add the ACME support.

@phinze Is this looking ready to merge to you? If possible I'd like to get this merged before Let's Encrypt becomes generally available, so these building blocks are available for me or someone else to work on additional resources for issuing "real" certificates using the ACME protocol.

[phinze]

This thing is beautiful. Landing it! ✈️

[silas]

Curious if there was a reason for not implementing tls_signed_cert as part of this PR? Being able to create a CA and creating/signing a bunch of certs would be useful for spinning up dev clusters (consul, kubernetes, etc...).

If not would you consider accepting a PR?

[apparentlymart]

@silas I was planning to implement the ACME protocol to get signed certs from registrars (some design notes in #3599) and so this set of stuff was basically intended as the building blocks for that, plus the self-signed cert just because it was easy once I'd done the other parts and handy for quick development environment stuff.

If I'm understanding correctly, what you want to do is take a CA cert and its associated private key and use those in conjunction with a CSR to produce a cert that is signed by that CA cert.

In which case, a resource for that seems reasonable and a logical extension building on the existing tls_private_key, tls_self_signed_cert and tls_cert_request resources to produce an ad-hoc, low-security PKI for development environments. I think it'd be great as long as its documentation carries all of the appropriate disclaimers and warnings. 😀

The only thing I'm kinda concerned about is making sure we have things named nicely so it's easy for users to understand the three different cases and how they differ:

• Certificates from an upstream CA (via ACME): tls_certificate
• Self-signed certificates: tls_self_signed_cert
• Certificates from a local CA managed within Terraform: tls_locally_signed_cert ???

I think the ACME-issued certs deserve to get the most straightforward and "primary-sounding" name tls_certificate because that's the resource people ought to be using by default for production systems. That leaves the other two cases needing extra adjectives to explain how they are different. "Locally-signed" was the best discriminator I could come up with for the "signed by a local CA" case, but perhaps we can do better!

[silas]

@apparentlymart Yup, you understood me correctly, and I agree on all points.

tls_locally_signed_cert sounds fine to me (couldn't come up with anything better).

[silas]

@apparentlymart I'd love any feedback you might have on #3930

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.