Add `auto_renew` kwarg to TLSCertificatesRequiresV1? about tls-certificates-interface

[gruyaume]

I like the idea, however with the current implementation it wouldn't be that easy to implement. Renewing certificates involves creating a new CSR which are created by providing the private key and various key/values.

That said, I think this feature would be great but would require a bit of a redesign of the lib.

[sed-i]

I wonder if, from a user perspective, it could be as simple as the following.
cc @sanchezfdezjavier

diff --git a/src/charm.py b/src/charm.py
index eb2d0ec..bb10ecd 100755
--- a/src/charm.py
+++ b/src/charm.py
@@ -157,9 +157,13 @@ class TraefikIngressCharm(CharmBase):
             ],
         )
 
-        self.certificates = TLSCertificatesRequiresV2(self, "certificates")
-        # TODO update init params once auto-renew is implemented
-        # https://github.com/canonical/tls-certificates-interface/issues/24
+        self.certificates = TLSCertificatesRequiresV2(
+            self,
+            "certificates",
+            auto_renew=True,
+            cert_subject_callable=lambda: TraefikIngressCharm.cert_subject.fget(self),
+        )
+
         self.framework.observe(self.on.install, self._on_install)
         self.framework.observe(
             self.on.certificates_relation_joined, self._on_certificates_relation_joined
@@ -167,9 +171,6 @@ class TraefikIngressCharm(CharmBase):
         self.framework.observe(
             self.certificates.on.certificate_available, self._on_certificate_available
         )
-        self.framework.observe(
-            self.certificates.on.certificate_expiring, self._on_certificate_expiring
-        )
         self.framework.observe(
             self.certificates.on.certificate_invalidated, self._on_certificate_invalidated
         )
@@ -254,35 +255,13 @@ class TraefikIngressCharm(CharmBase):
         self._stored.certificate = event.certificate
         self._stored.ca = event.ca
         self._stored.chain = event.chain
+        self._stored.csr = event.csr
         # TODO: Store files in container and modify config file
         self.container.push(_CERTIFICATE_PATH, self._stored.certificate, make_dirs=True)
         self.container.push(_CERTIFICATE_KEY_PATH, self._stored.private_key, make_dirs=True)
         self._push_config()
         self._process_status_and_configurations()
 
-    def _on_certificate_expiring(self, event: CertificateExpiringEvent) -> None:
-        old_csr = self._stored.csr
-        private_key = self._stored.private_key
-
-        if not (subject := self.cert_subject):
-            # TODO: use compound status
-            logging.error(
-                "Cannot generate CSR: invalid cert subject '%s' (is external hostname defined?)",
-                subject,
-            )
-            event.defer()
-            return
-
-        new_csr = generate_csr(
-            private_key=private_key.encode(),
-            subject=subject,
-        )
-        self.certificates.request_certificate_renewal(
-            old_certificate_signing_request=old_csr,
-            new_certificate_signing_request=new_csr,
-        )
-        self._stored.csr = new_csr.decode()
-
     def _on_show_proxied_endpoints(self, event: ActionEvent):
         if not self.ready:
             return

[ghislainbourgeois]

I like the idea, but the callable passed to the library would need to be for generating the CSR, and not only getting the subject. Until we can target exclusively Juju>=3 and use secrets, we cannot directly create the CSR as this requires the private key. There is not easy and safe way to store this sensitive piece of information from inside the library as far as I am aware.

Would that solution of a callable generating the CSR simplify your code enough?