Add an Id in the SSL certificate subject field

Question

I wonder if there is an easy way to auto-generate a "globally" unique Id while creating an SSL certificate and add it to the subject field? It will be helpful to see the OpenSSL bash command/example.

something along the lines of this:

Answer 1

First, the Subject field and the Subject Alt[ernative] Name extension (abbreviated SAN) are different and separate things, although they are both designed to relate to the same real-world entity; your title and text refers only to the first, and your example only to the second.

Technically, the Subject field is very flexible. It (like Issuer) is an X.501 'distinguished name' (DN; do not confuse with Domain Name) which consists of a sequence of (potentially sets of) type-value pairs where each type is defined by an ASN.1 Object Identifier (abbreviated OID); there are several standardized OIDs like 'country', 'locality', 'organization' and 'commonName' that are very widely used, but the format allows any OID, and the OID scheme is extensible -- anyone can get an 'arc' allocated and create an almost unlimited number of new OIDs, with the important limitation that only programs you write and systems you operate will know about new OIDs you create unless and until you get other people or organizations to adopt them. All of the standard DN OIDs require their values to be strings, although exactly which of the several strings ASN.1 supports varies depending on which standard(s) you read and try to follow; specifically see the type definition for DirectoryString; other OIDs are not required to follow this practice, but probably should to make implemenation and use easier. SAN is somewhat less general; it supports several choices of type for its value(s), two of which use an extensible OID+value scheme similar to Subject and Issuer, but the other (and more common) choices for SAN are more specific and constrained. The technical requirements were originally defined by X.509v3, but for use on the Internet (which is not the only place certificates are used) and to an extent on Internet-compatible networks (i.e. intranets) or systems, the controlling definition is now primarily RFC 5280 (plus related bits in some other RFCs). For HTTPS RFC2818 specifies that if SAN is present the client (browser) must use it and ignore Subject; some other protocols have similar (but not always identical) rules and RFC6125 recommends it for any new protocols.

However, the purpose of a publickey certificate is to convey trust to a key for an identifiable subject (and with various conditions and constraints); this requires that an actual certificate identify the subject accurately enough for the entities that use the certificate, who are generically called relying parties; for example for HTTPS websites the relying parties are the browsers acting on behalf of people accessing the websites. For the public web (HTTPS and WSS), and in practice for most other SSL/TLS protocols on the public network, these standards are set by the CA/Browser Forum. See 7.1.4 of the Baseline Requirements, and the referenced sections in 3.2.2 especially 3.2.2.4 and 3.2.2.5; they generally require subject and SAN to contain, in addition to DNS name(s) and possibly IP address(es) validated as belonging to the applicant (see next), only human-understandable and non-misleading identifiers like the company name. (But see below.) CAs not used/trusted publicly, such as private CAs within a business, agency, society, or workgroup, do not necessarily have to follow these rules, although violating them may cause issues with software that was designed on the expectation or assumption they are followed.

DNS names are globally unique. More exactly, Fully Qualified Domain Names (FQDNs) that are configured in the applicable 'authoritative' DNS server(s), which are the only kind you are permitted to get a cert for from a CABforum CA, are constructed to be unique across the entire public Internet. In fact this was one of the purposes and major design goals of DNS since it was created in the Reagan era. They are however usually chosen by people, and mnemonic (for some value of mnemonic), although they can be autogenerated; for example malware authors and botnet operators often use autogenerated and rapidly changing domain names for their 'command and control' systems to try to prevent law enforcement finding them and shutting them down. Some (legitimate) people also use long random or at least random-like subdomain names to try to keep their sites or parts of them 'hidden', but it's debatable how effective this is; I've seen a number of Qs (IIRC security.SX and maybe webmasters.SX) to the effect of 'I used this random domain name I believe no one could ever guess but it's still getting attacked/DoSed/found in searches?!'

IP addresses are also globally unique, at least 'real' assignable ones (not multicast, anycast, private-use, link-local, loopback and similar). (Again you can get a CABforum cert only for an assignable address, if any.) IPv4 addresses are assigned based primarily on the ISP you connect to, which is sort of automatic; IPv6 addresses are based partly on the ISP, with the rest usually automatic (either pseudorandom or arbitrary, such as your interface's MAC address). They are mostly non-mnemonic, except to experienced network engineers. However, they are generally not long-term stable, and for mobile/cell/wireless or some clouds not even short-term stable.

You haven't explained why you think an 'auto-generated' id would be of any benefit. Would some or all people be able to find out what the id of a particular person, entity or site should be? How would they do this, and how would you ensure that information cannot be falsified or tampered with, and does not become out of date? Would some or all people be able to verify that a given id is some person, entity or site they wish(ed) to communicate with? How is this better than the id we have now?

One approach that sort of vaguely resembles your question is that CABforum allows issuing EV = Extended Validation certs (which are more costly) to TOR 'hidden service' addresses, aka '.onion' addresses; see EV Guidelines Appendix F. (wikipedia incorrectly describes ballot 144 as adding this to Baseline, but the Baseline change is only to revoke .onion certs; the changes to issue them are in EV.) Because a TOR service is active (a program can communicate with it) and permanently bound to a publickey, the CA can validate that you 'own' it, and because a special TLD '.onion' is reserved, the CA can create a DNS-format name to put in CommonName and/or SAN.dnsName, even though it isn't strictly speaking a real DNS name (you can't look it up in an authoritative server). This address is auto-generated, not at all mnemonic, and statistically unique (because v3 uses a good crypto hash on data that is already fairly random).

As far as using OpenSSL commandline, that's not a programming Q and should be offtopic; there are many Qs mostly in other Stacks covering using OpenSSL to generate CSRs (certificate signing requests) and certificates, including self-signed (i.e. root or pseudo-root) certificates, and certs you sign with your own CA (which are signed by you, but NOT self-signed). Start with
How can I generate a self-signed certificate with SubjectAltName using OpenSSL?
How do you sign a Certificate Signing Request with your Certification Authority?
Add SAN with private CA
https://security.stackexchange.com/questions/44251/openssl-generate-different-type-of-self-signed-certificate
https://security.stackexchange.com/questions/150078/missing-x509-extensions-with-an-openssl-generated-certificate
https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-command-line
https://security.stackexchange.com/questions/190905/subject-alternative-name-in-certificate-signing-request-
https://serverfault.com/questions/845766/generating-a-self-signed-cert-with-openssl-that-works-in-chrome-58
https://serverfault.com/questions/845806/how-to-generate-ssl-certificate-having-ca-keys

But any cert you sign yourself (including self-signed) will probably not be trusted by anybody else. And if you submit a CSR to a CA, at least a public CA, and ask for arbitrary subject and/or SAN information, they will either reject or ignore it and only put in the cert what they (understand and) validate.