terraform-provider-tls Implemented tls_x509

Hi, I added here a first version of a x509 CRL resource, resolving #20 . The way of using it is using a field certs_to_revoke, that contains the certificates (in PEM format) that will be revoked.

Resolves #20

PS: also updated Golang version to currently latest 1.14

Apr 05 '20 11:04 fllaca

Hi @invidian , thanks a lot for hour review! I addressed most of your comments, please take a look again when you have a minute. For some other comments I had some doubts, responded with some thoughts about them.

Apr 09 '20 12:04 fllaca

Hi @invidian , sorry for the delayed response, I was really busy the last two weeks.

Thank you so much for the thoughtful feedback! Yeah... I see the points in your argumentation: as you say, with the current approach in this PR if you revoke a certificate and add it to the CRL you need to keep it forever in the terraform code and state (either hardcoded PEM or keeping its certificate resource definition). If you taint a certificate, the old version of it is not going to be in the list of serial numbers of the newly regenerated CRL.

But on the other hand, if you taint it, from the crypto point of view it is going to be actually a completely new certificate different from the previous one you had in tf state. I'm not that sure that the Terraform resource should handle this usecase internally by maintaining an "history" of revoked certificates in the state that don't appear in the resource definition in the terraform code. Normally, what I expect from terraform is that the code, the state, and the actual real resources are three views of the same thing, and Terraform's goal is to reconcile all three. Anyway I can be wrong here, I don't know if there's any other existing provider/resource that does something similar 🤔 , it could serve as inspiration to implement this as well.

These are just some thoughts, but I don't have a strong opinion... I agree with you, it would be good having some more input feedback on this. In any case I will give it a try to implement a version that keeps the history of revoked certs, maybe in another branch, at least just to see how it looks.

Apr 25 '20 10:04 fllaca

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}