Closed christhompson closed 4 years ago
@lgarron Does this look good to you? Thanks!
Ahh hmm, I hadn't considered that some use cases might be relying on it being relatively static. Do you know of specific use cases that are affected by churn? The cases I'd considered (mainly remembering cert interstitial decisions) are equally covered by other invalid certificates like the expired cert.
If there are use cases for only rotating it every so often, I can instead check in a new self-signed cert and think about adding tooling to the deploy process to warn if it's expired.
(Abandoning this -- we'll just track the expiration and regenerate in-tree when needed.)
Ahh hmm, I hadn't considered that some use cases might be relying on it being relatively static. Do you know of specific use cases that are affected by churn? The cases I'd considered (mainly remembering cert interstitial decisions) are equally covered by other invalid certificates like the expired cert.
Well, one case is if you've marked it as trusted it for testing. If we deploy while someone is testing like this, they'll unexpectedly see new failures.
Edit: On second reading, it seems like you've somewhat considered this. But certainly could be useful for this cert to be a tad more persistent.
This removes the checked-in pre-generated self-signed certificate chain. This was preventing the self-signed cert from being re-generated during the
make certs-prod
step of deploying the site. After removing, it will be re-created (with a new validity period) on every deploy.Fixes #359 (hopefully for good)