I had a couple issues with the dialog for setting the self-signed certificate and came up with some other.
The form would not let me NOT have the OU field of the DN. This IS optional. A small business may not have Units, just the Organization.
It will not let the CN be empty (ie not present in cert) per RFC 2818. CN is optional in the presence of a SAN. It was deprecated in favor of SAN when used for rfc822 or fqdn formats (and I think another or two).
So I got out my notes on displaying certificate content and looked at the certificate and saw:
# openssl x509 -noout -text -in certs/NSRV.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1539275343 (0x5bbf7a4f)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN= , O=HTT Consulting, ST=MI/emailAddress=admin@htt-consult.com/subjectAltName=homebase.htt-consult.com,*.home.htt-consult.com, OU=Main, C=US, L=Oak Park
Validity
Not Before: Oct 11 16:29:03 2018 GMT
Not After : Oct 8 16:29:03 2028 GMT
Subject: CN= , O=HTT Consulting, ST=MI/emailAddress=admin@htt-consult.com/subjectAltName=homebase.htt-consult.com,*.home.htt-consult.com, OU=Main, C=US, L=Oak Park
Subject Public Key Info:
...
SAN is NOT a subfield of DN. It is its own independent OID. I SHOULD check and there may well be an option for doing it this way, but it is not per the RFC. It IS hard to create properly with openSSL, particularly if you are using the command line format in a script. See my Internet Draft draft-moskowitz-ecdsa-pki and how I handle SAN and read sec 9.3
Of course operational experience against old implementations that continue to do things the old Netscape way can result in a few more lost hairs.
Now on to a operational question. If I create the cert from a command line (serial console or SSH), is that enough or do I still have to “upload” the certificate to get it known to other parts of Nethserver.