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?
cn=server.example.com:mailcan be different certificates for HTTPS and SMTP/STARTTLS on the same server.