Closed sed-i closed 5 months ago
Certificates generated by the charm don't include intermediates: https://github.com/canonical/httprequest-lego-k8s-operator/issues/93.
This was addressed by https://github.com/canonical/tls-certificates-interface/pull/141 in v3, but wasn't back-ported to v2, so bump to v3.
Technically the diff presents a breaking change for the .chain property, but we haven't really used it anywhere yet.
.chain
In tandem with:
Due to this diff:
-if chain := self._peer_relation.data[self.charm.unit].get("chain", []): +if chain := self._peer_relation.data[self.charm.unit].get("chain", ""):
on charm upgrade, the new charm would be expecting a str, but peer data would hold a List[str]. For this reason, first unrelate (tls_certificates), upgrade, and then relate again.
str
List[str]
Shouldn't we use TLSCertificatesRequiresV3 in cert_handler v1 too?
TLSCertificatesRequiresV3
I didn't bump cert_handler, it's still at v0.
Issue
Certificates generated by the charm don't include intermediates: https://github.com/canonical/httprequest-lego-k8s-operator/issues/93.
Solution
This was addressed by https://github.com/canonical/tls-certificates-interface/pull/141 in v3, but wasn't back-ported to v2, so bump to v3.
Technically the diff presents a breaking change for the
.chain
property, but we haven't really used it anywhere yet.In tandem with:
Upgrade notes
Due to this diff:
on charm upgrade, the new charm would be expecting a
str
, but peer data would hold aList[str]
. For this reason, first unrelate (tls_certificates), upgrade, and then relate again.