1

A vendor's software is generating CSRs with no keyUsage or extendedKeyUsage set and in combination with this they contain commonNames that are not fully qualified domain names. If I submit them to Digicert as "Private SSL" certificates they sign them for me.

I understand that web browsers will ignore the CN and treat only the SANs as valid so it's understandable they would allow non-FQDN in the commonName. However, one certificate contains invalid characters in the commonName -- a colon -- and Digicert refuses to sign it. Previous, similar certificates without invalid characters in the commonName simply did not have that name duplicated as a SAN as Digicert typically does with certificates, and Digicert also patched in the keyUsage for an SSL certificate because that's how I requested it.

I feel like I'm making an error submitting these as SSL certificates when the vendor's software does not designate the CSRs as such. But it has been successful with previous non-FQDN commonNames so why would Digicert balk at invalid commonName characters in other CSRs? And lastly, if the CSR never specifies keyUsage isn't that the equivalent of saying that the certificate is only used for encryption and I should just be signing them with Snake Oil?

Chagrin
  • 11
  • 1
  • 1
    Do not only look what is inside the CSR but look what is inside the generated certificate. A CA will not blindly copy everything from the CSR and sign it but will take only the parts it needs and will also add additional parts and restrictions. The information in the CSR is nothing more than a request, not a mandatory requirement. – Steffen Ullrich Feb 03 '21 at 07:55
  • A colon ist not an invalid character in a common name. In PKIs i've seen it's quite common to use it when one server needs more than one certificate, so `cn=server.example.com:web` and `cn=server.example.com:mail` can be different certificates for HTTPS and SMTP/STARTTLS on the same server. – wallenborn Feb 03 '21 at 12:18
  • As noted, KeyUsage in the CSR doesn't matter, only in the cert. Both RFC5280 and CABforum Baseline Requirements require it for _CA_ certs, but make it optional for EE certs in which case the cert's key may be used for any operations it supports that are not CA operations: RSA supports digSign keyEnc dataEnc, DSA supports only digSign, DH supports only keyAgree, EC supports digSign keyAgree, etc. – dave_thompson_085 Feb 04 '21 at 05:28

1 Answers1

1

Depending on the CA you are using, the degree of flexibility will vary. All the answers specific to the CA you have selected should be present in their certificate practice statement (CPS).

Each CA has certificate policy in place, which defines what is allowed and how to handle edge cases. Having some experience with building private CAs for living I can tell you that most of the CAs will strip your CSR from everything that they can figure out on their own. For example, it is a common practice to use the CN as SAN DNS in absence of SAN DNS in the CSR. The key usages are designated based on the type of the certificate you are buying not your CSR, this is why they're always stripped from CSR and assigned by the CA. When you are signign a certificate, you basically select a preconfigured template that will make sure that your certificate can be used as intended (it is easy to forget something crucial when generating your CSR).

As for the illegal characters, this is most likely caused by the character set chosen to represent the CN in certificate. When the certificate is encoded CA has options to choose different character sets for different fields to allow more flexibility. It can be PrintableString for CN and UTF-8 for things like a Name. If the character in your CN is not in the default character set selected for the field it will throw an error and CA will refuse to sign it.

Although it is not required by modern browsers the CN is still present in web server certificates to ensure the backwards compatibility.

nethero
  • 482
  • 2
  • 6
  • I could not find any detail as to the commonName in Digicert's CPS or other vendors' CPS. Regarding the string type the CN is listed as a UTF8String and that appears to follow the X.520 standard. I'll also note that the subjectAltName is a IA5String. – Chagrin Feb 03 '21 at 10:56
  • Keep in mind that those may be different for different CA as the standard allows you to choose. – nethero Feb 04 '21 at 13:55