search

cloud-gov / cf-cdn-service-broker

A Cloud Foundry service broker for CloudFront and Let's Encrypt
Other
10 stars 13 forks source link

Revoke certificate on deprovision #99

Open dcarley opened 6 years ago

dcarley commented 6 years ago

It would be good to revoke the certificate when de-provisioning a service instance.

We (GOV.UK PaaS) get an email notification from expiry@letsencrypt.org when certificates are due to expire. These notifications are useful because they give us a final warning if cdn-cron has stopped working.

However we get quite a lot of false-positive notifications for CDN service instances which have since been de-provisioned. We think that revoking the certificate would prevent this.

I'm not sure if/when we'll get round to implementing this, but I thought it would be useful to track as an issue and for others to comment if their experience matches/differs.

bleach commented 6 years ago

A friendly bump :) We're still interested in this.

jmcarp commented 6 years ago

We'd be happy to review a patch for this but don't have time to implement just now.

konklone commented 6 years ago

I strongly recommend not using revocation for this purpose. Revocation is meant to signal that something has gone wrong, and to tell TLS clients that they should not trust the certificate when presented. This is usually for cases like key compromise, or when insufficient validation was performed during certificate issuance, or when the certificate was issued with incorrect or invalid information.

Using revocation as a routine thing could lead to inquiries about whether an organization is having undisclosed security issues, or could lead to unexpected behavior if you ever do want/need to use a certificate after it's been revoked. (There's no unrevocation.)

Revocation also adds a cost burden to certificate authorities, who must serve OCSP responses related to them, and Let's Encrypt would be likely to notice this behavior and contact you to discourage it.

This is an area where Let's Encrypt should probably expand their API offering to include manipulation of email notification settings. But until then, their documentation says:

If your certificate is already renewed, we won’t send an expiry notice. We consider a certificate to be renewed if there is a newer certificate with the exact same set of names, regardless of which account created it. If you’ve issued a new certificate that adds or removes a name relative to your old certificate, you will get expiration email about your old certificate. If you check the certificate currently running on your website, and it shows the correct date, no further action is needed.

So if certificates are being directly renewed with the same set of names, that should solve the problem in both a more efficient way and a more accurate way. I would expect that to be possible if the system issues a certificate per-distribution, but if that's not possible for some reason, then I would recommend turning the feature request energy to Let's Encrypt.

konklone commented 6 years ago

Revocation also adds a cost burden to certificate authorities, who must serve OCSP responses related to them, and Let's Encrypt would be likely to notice this behavior and contact you to discourage it.

To correct myself - Let's Encrypt operates OCSP-only, and doesn't publish CRLs, so they likely would not experience an additional burden if lots of certificates were revoked. I still would strongly not recommend it, for the other reasons I stated.