X509 Name support

[chojnack]

Is your feature request related to a problem? Please describe.

Currently Certificates only include Common name and Organization fields that identify the originator of the CSR.
During implementation of ADCS Issuer (see: ADCS Issuer) I foud this as a limitation that doesn't allow cert-manager to be used in production environment where TLS certificates must include all X509 Name fields (X509Name).

Describe the solution you'd like

The Certificate CRD could be extended like this:

type CertificateSpec struct {
        // Full X509 name specification (https://golang.org/pkg/crypto/x509/pkix/#Name).
        // If specified, overrides any other name elements below.
        // +optional
        X509Name *X509DistinguishedName `json:"x509Name,omitempty"`
        ...
}

type X509DistinguishedName struct {
        // Country/Region
        Country            []string `json:"country,omitempty"`
        Organization       []string `json:"organization,omitempty"`
        OrganizationalUnit []string `json:"organizationalUnit,omitempty"`
        // City
        Locality []string `json:"locality,omitempty"`
        // State/Province
        Province      []string `json:"province,omitempty"`
        StreetAddress []string `json:"streetAddress,omitempty"`
        PostalCode    []string `json:"postalCode,omitempty"`
        SerialNumber  string   `json:"serialNumber,omitempty"`
        CommonName    string   `json:"commonName,omitempty"`
}

Describe alternatives you've considered
Currently we're using private build of cert-manager where support for full X509 name has been locally implemented.

Additional context
ADCS Issuer implementation

Environment details (if applicable):

• cert-manager version 0.11.0

/kind feature

[munnerz]

So we can definitely expose more of these options on our Certificate resource type, first of all 😄

Based on the fields on the Name structure, it seems we still need to expose:

• Country
• OrganizationalUnit
• Locality
• Province
• StreetAddress
• PostalCode

What is the relation between SerialNumber and the *big.Int SerialNumber field on the x509.Certificate? Do we need to allow explicitly setting the subject serial number field?

/area api
/priority important-longterm

[chojnack]

I'd put all the elements of X509 name in separate sub-section of the config, just for clarity (later, the stand-alone Common name and Organization could be made obsolete).

Reg. the serial number, I couldn't find any information how it's presence in the request should be interpreted by the issuers. I think, a safe solution could be allowing to set it optionally in the request and leaving the interpretation of the presence/absence to the issuer (whether use it, ignore, overwrite or reject the request). Current cert-manager's issuers could just ignore it.

Marcin

[leifmadsen]

Not having OrganizationalUnit also affects me, so this would be a welcome addition!