Add support for setting multiple DC fields to Certificate, to allow for LDAP client authentication

[SpectralHiss]

Note entirely clear if this is a feature request or bug.

Use case:
One of the methods that LDAP allows to authenticate is X509 client authentication.
Part of the access control mandates setting multiple DC fields in the certificate as well as multiple OUs potentially.
The DC field is commonly included as of the standard definition of DN
https://www.ibm.com/docs/en/ibm-mq/7.5?topic=certificates-distinguished-names

It is also mentioned within tge RFC, but only in the context of LDAP and not under the official Subject spec
https://www.rfc-editor.org/rfc/rfc5280.txt

Problem:
In the current certificate spec it is not possible to set a single DC , yet again multiple which is needed for the LDAP client certificate.

If not mistaken, setting multiple OU or DC fields would also have this bug #3203

DC doesn't feature in subject section in spec (4.1.2.6), which is probably why it doesn't appear in pkix.Name type used for the field.
That type allows setting other extra names as a contingency for these commonly used names, it would be great if we could map DCs and multiple OUs as well.

/kind feature

[maelvls]

I always wondered why the Certificate resource only had commonName. I'd expect to be able to set the whole distinguished name, e.g. CN=example.com,DC=example,DC=com,OU=lille. To the cert-manager authors: what was the original reason behind restricting the DN to the CN? Is it because TLS requires the DN to only contain the CN?

Update: I spoke too quickly, you can already set the subject DN on the Certificate resource via the spec.subject field:

$ k explain certificate.spec.subject
FIELDS:
   countries    <[]string>
     Countries to be used on the Certificate.
   localities   <[]string>
     Cities to be used on the Certificate.
   organizationalUnits  <[]string>
     Organizational Units to be used on the Certificate.
   organizations        <[]string>
     Organizations to be used on the Certificate.
   postalCodes  <[]string>
     Postal codes to be used on the Certificate.
   provinces    <[]string>
     State/Provinces to be used on the Certificate.
   serialNumber <string>
     Serial number to be used on the Certificate.
   streetAddresses      <[]string>
     Street addresses to be used on the Certificate.

As @SpectralHiss mentioned, the DC field (domain component) is not supported on the Certificate resource:

• X.509 Name support & invalid output w/ multiple RDNs #3203

[jetstack-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[maelvls]

Reading through RFC5280, it seems like cert-manager only supports a subset of the DN attributes that X.509 implementations "must" support:

In addition, implementations of this specification MUST be prepared to receive the domainComponent attribute, as defined in RFC4519. The Domain Name System (DNS) provides a hierarchical resource labeling system. This attribute provides a convenient mechanism for organizations that wish to use DNs that parallel their DNS names. This is not a replacement for the dNSName component of the alternative name extensions. Implementations are not required to convert such names into DNS names. The syntax and associated OID for this attribute type are provided in the ASN.1 modules in Appendix A. Rules for encoding internationalized domain names for use with the domainComponent attribute type are specified in Section 7.3.

Here is a table with the supported attributes in cert-manager with regards to RFC5280:

Subject DN attribute	Source	Supported in cert-manager
country	X.520 (MUST)	✔️
organization	X.520 (MUST)	✔️
organizational unit	X.520 (MUST)	✔️
distinguished name qualifier	X.520 (MUST)	❌
state or province name	X.520 (MUST)	✔️
common name	X.520 (MUST)	✔️
serial number	X.520 (MUST)	✔️
locality	X.520 (SHOULD)	✔️
title	X.520 (SHOULD)	❌
surname	X.520 (SHOULD)	❌
given name	X.520 (SHOULD)	❌
initials	X.520 (SHOULD)	❌
pseudonym and	X.520 (SHOULD)	❌
generation qualifier	X.520 (SHOULD)	❌
unique identifier	X.520 (SHOULD)	❌
domain component	RFC4519 (MUST)	❌

[jetstack-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[BlackBsd]

Any update on the DC field?

[jetstack-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

[jetstack-bot]

@jetstack-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[irbekrm]

Ability to provide 'literal' certificate subject block has been released as an alpha feature in cert-manager v1.9 see release notes.
We'd be keen to hear feedback as to whether this feature solves the use case described in this issue!

[SpectralHiss]

Any update on the DC field?

This has been addressed in #5582 and merged, now pending release in 1.11