-
First of all thanks for making I'm trying to get a CSR signed from a Unifi Controller (java keystore), using the instructions in this KB article. Here's the certificate request I get from the Unifi device:
When I ask
Is there any way to get this CSR signed, short of maybe making a custom template that adds a DNS SAN from the Common Name? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hi @tashian, The use of common names only for DNS authentication is currently deprecated, and the JWK provisioner enforces the use of at least one subject alternative name SAN. We probably should relax this requirement from the CSR, and just grab the CN and add it to a SAN. Not all the provisioners have the same restrictions, for example, OIDC doesn't have that restriction, but using {
"ott": "...the oidc token...",
"csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIH.....\n-----END CERTIFICATE REQUEST-----"
} And do {
"subject": {{ toJson .Insecure.CR.Subject }},
"sans": [{"type": "auto", "value": "{{ .Insecure.CR.Subject.CommonName }}"}],
{{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }}
"keyUsage": ["keyEncipherment", "digitalSignature"],
{{- else }}
"keyUsage": ["digitalSignature"],
{{- end }}
"extKeyUsage": ["serverAuth", "clientAuth"]
} |
Beta Was this translation helpful? Give feedback.
Hi @tashian,
The use of common names only for DNS authentication is currently deprecated, and the JWK provisioner enforces the use of at least one subject alternative name SAN. We probably should relax this requirement from the CSR, and just grab the CN and add it to a SAN.
Not all the provisioners have the same restrictions, for example, OIDC doesn't have that restriction, but using
step
will complain because the CN does not match the token subject, there's already an issue for loosening the requirements ofstep
and relay just onstep-ca
(smallstep/cli#340). So right now, you can grab the OIDC token (usingstep ca token
) and build a JSON like: