I managed to put the SAN in CSR and then sign it without losing them, by doing the following.
Find the openssl.cnf
And uncomment the following under the [ CA_default ] section
copy_extensions = copy
Then you have to create some files (if you don't know where, try issuing the first cert, ...
extendedKeyUsage = clientAuth
subjectAltName = @alt_names
This section is not referenced anywhere. It will not be magically be used either. You have to explicitly provide what it should be used for, same as you did for [req_distinguished_name] with distinguished_name = req_distinguished_name:
req_extensions = v3_req_client
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 ...
For security purposes, a certificate's signature must sign the entire certificate (aside from the signature itself, obviously...). Otherwise, you could take a validly-issued certificate for your own domain (and for which you hold the corresponding private key), change the "Subject" (the entity - such as a domain like "yoursite.com" - that the certificate ...
The signature covers the certificate, not only the public key. If the signature covered only the public key, you could change any parameter (expiration date, domain name, issuer) and the signature would still be valid.
Digital signatures are not encryption: https://security.stackexchange.com/a/87373/70830
It is important, when reading the link above, to ...
I'm guessing it's for OCSP.
I've had a look at the CAB forum Baseline Requirements. I did a full text search for digitalSignature and there are only two hits.
Hit 1/2 is for root CAs:
This extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign
MUST be set. If the Root CA Private Key is ...