On Fri, Feb 7, 2020 at 4:02 PM Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx> wrote: > > > From: Michael Leone [mailto:turgon@xxxxxxxxxxxxxx] > > Sent: Friday, February 07, 2020 13:13 > > > > I've got it almost all figured out, except how to get a subjectAltName > > automatically populated by the CN of the requestor. My requests aren't > > asking for a SAN, but Chrome isn't happy without one, so I'd like to > > at least auto-populate 1 SAN by having it be the DNS:<CN> of the > > requesting CSR. > > > Not automatically, unfortunately. openssl ca recognizes a special "email:copy" token in the extension list in the configuration file, but that's only for email addresses in the Subject DN. Here's what I did. I created a file with a section name, and a SAN name: $ sudo more cert-extensions [ PHA_extensions ] subjectAltName=DNS.1:<FQDN> I then call that out, when I sign: $ sudo openssl ca -days 3650 -in requests/request.CSR.txt -out certs/2020-02-10.pem -extensions PHA_extensions -extfile cert-extensions -policy policy_anything That way, I can write up step-by-step HOWTOs, for the other folks in the department to whom using the command line is an obsolete and dinosaur way of computing (don't ask ..), and just tell them they have to create a simple text file with the specific alt name(s) wanted, and copy that, along with the CSR, over to the Linux VM for signing, and issue the above command. following the HOWTO. Eventually, I will be creating a Windows Intermediate CA, and that way I can just generate the certs that way, which is a lot easier, in an almost all Windows environment, using AD. And then I can turn off the Linux root CA, since I'll never use it again; I'll only use the intermediate CA. Thanks for all the help, everybody. It never occurred to me that I wasn't issuing certs the correct way, since the way I was issuing them, had always worked. Right up until I needed a SAN or certain extensions ...
