Certificate revocation list

[jackivanov]

Use case is the following: If you have a server which requires a valid certificate to log in, you would also want to keep the CRL of the revoked certificates in order to prevent the deleted users get authorized.

When you iterate over a list with users, you need to create new certificates for new users and revoke the certificates for the deleted users, which have disappeared from the list.

I'm not sure whether the current architecture of the terraform states allows us to keep the history of changes, but we need to think about generating the CRL somehow. In theory, we may use some kind of index file to keep the history of certificates.

Currently, when you iterate over a list with users, terraform will destroy resources for disappeared users. As a solution we might iterate over a map instead and do something like this (some kind of the index file in a variable)

users = {
  "1"  = "user1"
  "2"  = "user2"
  "3"  = false # user3 retired
}

resource "tls_locally_signed_cert" "client" {
  count                 = "${length(var.users)}"
  ...
  is_valid              = "${lookup(var.users, count.index+1) == 0 ? 0 : 1}"
}

If is_valid true, CRL will be generated in a new attribute

[SpencerBrown]

Thanks for the detailed response. As a user of the TLS provider, do you have a need for CRL functionality at this time? Just trying to understand priorities.

[jackivanov]

Yes, it would be cool to get it soon. btw, if the schema I suggested is OK for you, I can try to implement it.

[denibertovic]

Is there any news on this feature. I'm using terraform to provision client (as well as server) certificates for OpenVPN access. It would be neat if there was way to create a CRL from terraform as well at which point I could import that CRL into the VPN and it would reject the revoked certificates.

[pavlo]

I'd like to add a vote to this request as well. Maintaining CRLs would be a great thing to have in terraform.

[trebidav]

this would be really useful! especially useful in combination with AWS Client VPN

[invidian]

I was thinking about how the user interface for that could look like.

What about:

resource "tls_x509_certificate_revocation_list" "clients" {
  certificates = tls_locally_signed_cert.client.*.public_cert_pem
}

output "crl" {
  value = tls_x509_certificate_revocation_list.clients.crl_pem
}

So, whenever new certificate is created, it will be added to Computed: true field of CRL. If the certificate is removed, CRL will be able to find which certificate has been removed (by comparing computed field and user input) and will add such certificate to the CRL, by modifying it.

At the creation time of tls_x509_certificate_revocation_list, empty CRL object will be created and stored as well.

EDIT: (of course I omitted fields actually require for building CRL, like private key for signing it etc.)

[trebidav]

@invidian Sounds great! Are you willing to implement it? :)

[invidian]

I can't promise anything, but I'm playing around with Terraform SDK right now, so if I find some time, I can try.

Though I'm a bit concerned whether it's worth doing it, as this provider doesn't seem to be very well maintained, so I guess it will take ages to get it merged and released...

[trebidav]

Let's hope for the best!

[fllaca]

hi @invidian! Could you finally make some code for this? If you couldn't find the time, I also need this at my company, I also would be happy to give a try to the implementation :)

[trebidav]

@fllaca go for it!

[invidian]

@fllaca no, I didn't, so indeed go for it ;) feel free to pull me in for reviews etc :)

[fllaca]

Hi @invidian @trebidav , I crafted #73 with a first version of this CRL resource. Although I agree with the approach proposed at https://github.com/hashicorp/terraform-provider-tls/issues/20#issuecomment-584572841, this first version is a simpler implementation in which you specify explicitly the list of certificates (in PEM format) to be revoked, which is also closer to how the information is generated and stored inside a CRL. I think anyway that this initial implementation can be fully compatible in the future with that feature by @invidian of expressing the revocation list in a "reverse" fashion (especifying the certificates accepted in addition to the revoked ones, and then maintaining a kind of "history" of revoked certs in a computed field).

[hvhaugwitz]

What is the state of this issue?

[invidian]

What is the state of this issue?

#73 needs rebase and maintainer's attention.

[debu99]

any update?

[rafael-adorna-incode]

Any update?

[amcsi]

I have a high-level solution to this in the meantime, as a workaround:

There should be some place (e.g. an AWS bucket) where you store a list of all certificates that you generated (in the form of e.g. an object each), referencing the certificate's fingerprint. You make sure that whenever a certificate is generated, it is added to the list of generated certficates. The secret sauce: you make sure that if you destroy a certificate (or replace a certificate), you do not delete the certificate fingerprint from the list of generated certificates.

Why is this good? Because now with a list of all certificates (their fingerprints) you ever generated along with your current list of active certificates from your TF state, you can new derive the list of certificates you want to revoke by taking the list of all certificates, removing from that list the active ones, and you're left with the inactive ones that you want to revoke.

You can then associate that list of inactive certificates as the revoke list for your resource.

How best to do make this list of all certificates I'm not sure about. By default when you create an S3 object with TF, if you were to then destroy/replace it, the object also gets destroyed, so that wouldn't work. You may need to write a custom script that always only adds object to the bucket, but never removes any, even on destroy. I would appreciate any ideas on how do this in an easier way.

EDIT: I really can't find any easy way to automatically maintain a list of all certificates ever created :(