reissue-certificate is not automated
Bug #1914708 reported by
Nobuto Murata
This bug affects 3 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| vault-charm |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
Let's encrypt and certbot as an example, shorter TTL can be possible only with automation. Otherwise, it's pretty easy to get those certificates expired.
We have an charm action to "reissue-
| Changed in vault-charm: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
| importance: | Medium → Wishlist |
| tags: | added: onboarding |
| tags: |
added: good-first-bug removed: onboarding |
| Changed in vault-charm: | |
| assignee: | nobody → Anna Savchenko (annsavchenko) |
| Changed in vault-charm: | |
| status: | Confirmed → Triaged |
| assignee: | Anna Savchenko (annsavchenko) → nobody |
| tags: | removed: good-first-bug |
Revision history for this message
| Aurelien Lourot (aurelien-lourot) wrote | #1 |
To post a comment you must log in.
Removing tag `good-first-bug` as on top of requiring a cronjob calling `juju run` (in order for the logic to have the juju context), which has some inherent problems, there are other concerns. For example what if some consuming charms restart their services upon receiving new certificates? We may then want to be able to define a time of the day/week/month in which this downtime is more acceptable.
For now, as a first step towards writing the logic for checking for certificate expiry, I have spun off an easier lp:1949881.