---
title: Charmhub | Deploy TLS Certificates Interface using Charmhub - The Open Operator
  Collection
description: Deploy the latest version of TLS Certificates Interface as a Kubernetes
  Operator on any cloud.
url: https://charmhub.io/tls-certificates-interface/docs/h-private-key-label-change
---

# TLS Certificates Interface

[Canonical Telco](https://charmhub.io/publisher/telco-charmers "View all packages from Canonical Telco")

* [Canonical Telco](https://charmhub.io/publisher/telco-charmers "View all packages from Canonical Telco")

Platform:

edge 277

```
juju deploy tls-certificates-interface --channel edge
```

[Learn to deploy on juju >](https://juju.is/docs/juju/manage-applications)

---

#### Relevant links

* [Homepage](https://charmhub.io/tls-certificates-interface/libraries/tls_certificates)

---

Share your thoughts on this charm with the community on discourse.

[Join the discussion](https://discourse.charmhub.io/)

# Important Change in TLS Certificates Interface V4.8

A change in private key labeling will allow a requirer with multiple instances of the tls-certificates relation interface to have one private key per relation.

## [What’s Changing](https://charmhub.io/tls-certificates-interface/docs/h-private-key-label-change#p-36203-whats-changing)

* The tls-certificates-interface is changing how it labels private keys for certificate request signing (Requirer side)
* Previous pattern: `{LIBID}-private-key-{unit_number}`
* New pattern: `{LIBID}-private-key-{unit_number}-{relation_name}`

## [Impact on Your Deployment](https://charmhub.io/tls-certificates-interface/docs/h-private-key-label-change#p-36203-impact-on-your-deployment)

When upgrading to V4.8:

* The library will generate new private keys that will be stored in Juju secrets with the new labels
* This will trigger a certificate rotation process, it removes the current certificate requests and certificates and requests new certificates from the provider.

## [Why This Change Was Needed](https://charmhub.io/tls-certificates-interface/docs/h-private-key-label-change#p-36203-why-this-change-was-needed)

Before V4.8, charms using multiple instances of the TLS relation interface would get one private key for all instances. This occurred because:

* The previous labeling pattern didn’t account for multiple interface instances
* Juju doesn’t create multiple secrets with the same label for the same owner
* This affected charms requiring different certificates for different purposes (e.g., internal unit communication vs. external HTTPS) and instantiate multiple instances of the interface.

---