0

When I'm creating a certificate signing request like below I have to run trough a process and need to enter several properties with individual values per certificate. (see image below)

    openssl req -config ../CA/config/openssl.custom.cnf \
        -key ./private.key.pem \
        -new -sha256 -out ./private.certificate.csr.pem

enter image description here

Now I want to put additional properties into the cert like a mac address of a device the later validated file is installed on.

I've tried to modify the customized openssl.cnf to write additional properties into the certificate signing request but without any luck and I can't find proper information if it's somehow possible (maybe using the wrong search terms)

My first thought was to use the common name to encode my additional properties in it but I guess that's not good practice — don't know.

I'm happy for any help here.

Bernhard
  • 4,855
  • 5
  • 39
  • 70

1 Answers1

0

First, req -new (without -x509) creates a CSR (Certificate Signing Request) not a certificate. Whether and which name attributes and/or extensions that you put in a CSR subsequently appear in the certificate is up to the CA that issues the certificate.

Second, if this cert is for (a device which will be) a HTTPS server, or most other SSL/TLS based protocols like SMTPS, LDAPS, etc, CommonName in Subject should be the name used by clients to connect to the server; usually this will be a fully-qualified domain name (and usually must be for a cert issued by a public CA like Verisign, GoDaddy, etc.), but for internal networks and CAs it can be a local name or address. Officially the SubjectAlternativeName extension supersedes CommonName and if your cert contains SAN (which depending on the CA you might or might not request in the CSR) clients should use SAN for name matching and ignore CommonName even if contains something else, but unless you check all the clients that will be used I wouldn't like to rely on that. If the cert is for a client or other purposes like S/MIME protocol doesn't require the communication (URL) name, but a public CA will still want to be sure it doesn't mislead reliers as to your identity; since MAC addresses are easily changed or spoofed, and can be duplicated either by mistake or intentionally, I don't know if they will be considered good identification.

If you want to stuff more or less arbitrary data in Subject, OrganizationalUnit (OU) is probably the best place. It has no really common meaning, and is the only subject-related value not required to be verified by CAs following CA/Browser Forum requirements.

Note it is possible to have more than one instance of an Attribute in a DistinguishedName i.e. you could have 2 (or 3 or 7) OUs, with a tweak to the openssl config file (and subject to approval of the CA, as always). Although if you want some software using this cert to automatically check a particular one of those values, it becomes a tiny bit more complicated.

dave_thompson_085
  • 34,712
  • 6
  • 50
  • 70
  • Thank you. As you can see in the question I start with a signing request. And Yes using a MAC address directly is not safe. But to store e.g. a hashed value makes it possible to compare on target device. The target device is an embedded system so spoofing isn't possible without a very huge effort. Too store the information in OU is the most suitable way I already thought but I'm asking me now if there's any way to use openssl to generate certificates containing fully customized properties which can be trusted the CA way. – Bernhard Nov 01 '15 at 10:37
  • Your device may be hard to spoof, but the CA has no way to know your cert and key won't be used on a device that is can spoof. I don't know what you mean by customized properties other than usual name fields. You can put any (reasonably small) text in OU. You can configure the openssl config file to put in the Subject name additional (text) attributes for which an OID is assigned such as those in A.1 of rfc5280, but whether those attributes go into the cert depends on the CA. ... – dave_thompson_085 Nov 04 '15 at 01:28
  • You can configure the openssl config file to put in the request extensions for which an OID and syntax is assigned, although encoding anything more complicated than a single string element is complicated, but whether those extensions go in the cert depends on the CA. If you are *issuing* the certs with openssl, such as the `ca` commandline utility, then you can copy name attributes by including them in the policy (either modify the existing policy, or create and use a new one) and you can copy extensions from the CSR *en bloc* with copy_extensions, or do them at issue *instead* of the CSR. – dave_thompson_085 Nov 04 '15 at 01:30