`common_name` field should be optional

[sed-i]

Currently, we must provide a common_name,

tls-certificates-interface/lib/charms/tls_certificates_interface/v4/tls_certificates.py

Lines 563 to 572 in 3e32a23

	@dataclass(frozen=True)
	class CertificateRequestAttributes:
	"""A representation of the certificate request attributes.
	This class should be used inside the requirer charm to specify the requested
	attributes for the certificate.
	"""
	common_name: str
	sans_dns: Optional[FrozenSet[str]] = frozenset()

However, that field is deprecated and the best practice is to not have it included.
https://github.com/cabforum/servercert/blob/90a98dc7c1131eaab01af411968aa7330d315b9b/docs/BR.md#71272-domain-validated

If it is included, it must be derived from the SANs, but CN is limited to 64 chars,
https://community.letsencrypt.org/t/simplifying-issuance-for-very-long-domain-names/207924

Seems like we have two options:

1. Allow for it to be excluded, or automatically exclude it from the CSR if set to an empty string ("") in the dataclass.
2. Keep it as is, but pass a wildcard such as *.svc.cluster.local.

[DanielArndt]

Further context:

• https://discourse.charmhub.io/t/getting-started-with-the-tls-certificates-library-v4/15537/2
• https://warthogs.atlassian.net/browse/TLSENG-720?focusedCommentId=741604

[DanielArndt]

I'll reproduce my comment from our internal ticketing system here:

---

25 April 2025 at 12:59

I’m going to add some thoughts here for whoever picks this up:

I think we should move away from common name being our de-facto (and required) certificate identification field.

tls-certificates-interface/lib/charms/tls_certificates_interface/v4/tls_certificates.py

Line 245 in c11d0d4

common_name: str

tls-certificates-interface/lib/charms/tls_certificates_interface/v4/tls_certificates.py

Line 370 in c11d0d4

common_name: str

tls-certificates-interface/lib/charms/tls_certificates_interface/v4/tls_certificates.py

Line 751 in c11d0d4

common_name: str,

tls-certificates-interface/lib/charms/tls_certificates_interface/v4/tls_certificates.py

Line 676 in c11d0d4

common_name: str,

Common name was once the standard, but it is now considered deprecated. Some older implementations may still require it, but those legacy implementations should be the exception.

Instead,

• We should probably have some default value in the SAN – one that makes sense in the Juju ecosystem for internal communications
  • The SAN functions in a similar way to the common name, but doesn’t have a restriction of 64 characters and is the new “standard”
• We should not include a default common name at all
  • The common name is restricted to 64 characters. This makes it difficult in the Juju ecosystem to create a deterministic and unique common name that is addressable.
• allow charms to override and/or extend the SAN values
• allow charms to manually set a common name, if necessary

[james-garner-canonical]

This sounds very reasonable from a TLS perspective (though I'm no expert there).

I just want to note that we need to be careful with the interface definition here -- making a required/guaranteed databag field optional is backwards compatible for old version readers of that databag. This would presumably need to be a major version bump of the interface, and I believe the library would need to support both the current version and the new version of the interface until we're confident that the old version isn't in use anymore (when?).

We're planning to move the tls_certificates library to the charmlibs monorepo in the near future, where it will be distributed as a Python package rather than a Charmhub-hosted library. It would be nice if the initial migration had a simple story: exact port of the latest v4 lib code, supports the latest v1 of the interface.

[DanielArndt]

@james-garner-canonical I'm not sure I follow how this would affect the interface. The CSR fields and resulting certificate fields do not appear in the interface definition. They are just base64 string blobs.

[james-garner-canonical]

Following some discussion with @DanielArndt, I now realise that the discussed common_name attribute isn't part of the interface itself, which only specifies that the certificate_signing_request is a string. I understand that the common_name attribute under discussion here is part of a (base64 encoded) certificate signing request, and part of the library code, where it's assumed to be a required field.

I haven't looked into the specific details of where and how this assumptions is made, but I do want to reiterate that it seems like there's a backwards compatibility concern here if a requirer using a new version of the library makes a request to a provider on an old version of the library. If the current version of the library relies on the common_name field being provided, then the new version will need to be compatible with this, for example by not requiring the user to specify it, but including a default value in the request instead (as I think @DanielArndt is suggesting above).