6

What are the naming conventions when buying certificates, if any?

When buying a cert for TLS/HTTPS for a particular Server, naturally I will default to the server's name. For example, if the server is called MOONSERVER I would set the Subject of the x509 Certificate to MOONSERVER.

Additionally, I need to use another cert for message signing. What should I call this? What are the rules for valid names? E.g. are hyphens, underscores, etc. ok? Are the names case sensitive?

chwarr
  • 105
  • 6
joedotnot
  • 161
  • 4
  • I think, this question has nothing to do with certificates. The question is about DNS names. – Crypt32 May 21 '20 at 06:54
  • @Crypt32 I'm surprised you would say this has nothing to do with certificates, that's exactly what I am trying to do, buy a Certificate for message signing. You know what that is, don't you ?! – joedotnot May 21 '20 at 07:28
  • I'm not aware of any globally adopted naming convention. The only requirement is the name must be meaningful to you and consist of valid character set. You can start with RFC 1178: https://tools.ietf.org/html/rfc1178 – Crypt32 May 21 '20 at 07:35
  • @Crypt32 ok, thanks for the RFC link – joedotnot May 21 '20 at 07:39

1 Answers1

5

As you are purchasing these certificates, the contents of these fields will probably be governed by the user interface of the certificate seller which will hopefully carry out some sanity check on the values you enter.

The information you should place in the Subject field depends on the application amongst other things.

HTTPS, which is just an implementation of HTTP over TLS is governed by RFC 2818 which stipulates that server identification must use the Subject Alternative Name(SAN) extension's dnsName field if present.

The CA/Browser forum, which is a consortium of commercial CAs and browser vendors, adds even stricter constraints and expects server identification to only use the SAN extension (i.e. any server DNS names in the Subject field aren't checked). Therefore, if you have a web application where the end user uses a common web-browser (that's nearly all of us) then you will need to follow the CA/B Forum requirements and have the DNS names of your hosts in the SAN.

Note that TLS itself doesn't define any restrictions on names, therefore other applications which use TLS may have different requirements. The same goes for non TLS usage of X.509 certificates, such as code signing. There is guidance on the interpretation of DNS names in RFC 6125.

The rules governing what's acceptable in terms of characters etc. are in the documents which define these certificates. That's RFC 5280 for certificates used on the Internet and X.509 for all certificates (including those used on the Internet). The latter refers to a multitude of documents, such as X.500,X.501,X.520,X.521 and X.680.

X.520 section 6 defines many of the attributes which you can use in the Subject field. It's a thrilling bedtime read, so if you can't spare the time, stick to the basic characters of the PrintableString type of:

A..Z a..z 0..9 (space)'()+,-./:=?

This may not be politically correct as most non-English languages won't be covered. The alternative is to use the utf8String type which includes most characters in the world.

garethTheRed
  • 4,539
  • 14
  • 22
  • your answer seems to suggest Subject CN is a free-for-all, almost anything goes string, and since I am trying to do Message Signing I will use something like myname@MOONSERVER or myname.MOONSERVER. Hope both ampersand or dot . are ok? [Aside - At least you know there can be non-TLS uses, everyone else i ask wants to turn this into a problem of DNS, Domains, Servers, etc, which is probably because securing web servers is all they've done. I want to use it for message signing a SOAP payload, even the tech support chat at a big cert vendor had no clue what I was saying, pathetic] – joedotnot May 21 '20 at 10:35
  • Although Unicode _homographs_ (characters that look the same but are in fact different) can be mis-used to deceive people and cause security failures. – dave_thompson_085 May 22 '20 at 01:32