Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certificate revocation list #20

Open
jackivanov opened this issue Apr 12, 2018 · 18 comments · May be fixed by #73
Open

Certificate revocation list #20

jackivanov opened this issue Apr 12, 2018 · 18 comments · May be fixed by #73

Comments

@jackivanov
Copy link

jackivanov commented Apr 12, 2018

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
Copy link
Contributor

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
Copy link
Author

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
Copy link

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
Copy link

pavlo commented Feb 5, 2020

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

@trebidav
Copy link

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

@invidian
Copy link
Contributor

invidian commented Feb 11, 2020

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
Copy link

trebidav commented Feb 11, 2020

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

@invidian
Copy link
Contributor

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
Copy link

Let's hope for the best!

@fllaca
Copy link

fllaca commented Mar 22, 2020

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
Copy link

@fllaca go for it!

@invidian
Copy link
Contributor

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

@fllaca fllaca linked a pull request Apr 5, 2020 that will close this issue
@fllaca
Copy link

fllaca commented Apr 5, 2020

Hi @invidian @trebidav , I crafted #73 with a first version of this CRL resource. Although I agree with the approach proposed at #20 (comment), 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
Copy link

What is the state of this issue?

@invidian
Copy link
Contributor

What is the state of this issue?

#73 needs rebase and maintainer's attention.

@detro detro added the tf-devex-triage Terraform DevEx project tracking label May 16, 2022
@bflad bflad unassigned detro Aug 1, 2022
@bookshelfdave bookshelfdave removed the tf-devex-triage Terraform DevEx project tracking label Aug 5, 2022
@debu99
Copy link

debu99 commented Sep 15, 2023

any update?

@rafael-adorna-incode
Copy link

Any update?

@amcsi
Copy link

amcsi commented Feb 14, 2024

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 :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.