Technical Differences between v3 and v4

v3

• requires users to perform multiple TLS-related operations independently
  • generate a private key
  • generate CSR
  • request a certificate
  • listen to certificate expiry events

V4

• Requires secrets! (Juju 3.0+)
• Focused on automating most of the TLS Certificate activities for the charm author.
  • The intent is for the charm developers to focus on what is in their certificates and not how to get them or manage their lifecycle.

Implications

Since v4 automates most of the TLS Certificate activities, in most cases charm authors will be using a private key generated by the charm library.

This means that, without intervention, upon upgrade of the charm the charm will use the private key generated by the charm library which will cause a certificate rotation.

However, should the charm author wish to use a specific private key, and avoid the certificate rotation, they can do so by passing the private key to the TLSCertificatesRequiresV4 class upon instantiation.

Upgrading a deployed charm from v3 to v4

No special deployment steps are required. Running juju refresh is sufficient. No relation teardown, no configuration changes, and no manual intervention.

What happens at refresh

1. The upgraded charm boots with v4, which takes over private key management. It generates a new RSA private key and stores it in a Juju secret.

2. The old CSR (signed with the v3-era key managed by the charm) no longer matches the new private key and is removed from the relation data.

3. A new CSR is sent to the provider, which issues a new certificate.

4. The certificate_available event fires and the charm receives the new certificate.

Expected downtime

There might be a brief downtime during the rotation of the certificates due to the change in the private key and therefore the requests, the length and the impact of the downtime depends on how the charm configures and handles the certificates.