[openssl-users] [openssl]: Subject alternative names not recognized when signing certificates

[Viktor Dukhovni]

> On Sep 22, 2018, at 8:28 AM, Carsten <openssl-mailman at familie-lahme.de> wrote:
> 
> I can sign certificate requests successfully, BUT....
> if the request contains SAN attributs (subjectalternatenames) they are ignored -not visible in the signed certificate.
> 
> I found many exambles how to create a SAN-Certificate using the selfsigned mechanism, but that is not what I want.
> 
> Is there any how-to in the wild, how to set up a fully working CA including SAN (v3) attributs?

My approach is generally to dynamically generate a config file with the requisite
extensions, and use that to build the certificate.  It is possible to copy
extensions from the request (CSR) to the certificate, but not always wise
if you've not carefully checked that all the extensions in the CSR are appropriate.

  https://www.openssl.org/docs/man1.1.0/apps/ca.html

  copy_extensions

  determines how extensions in certificate requests should be handled.
  If set to none or this option is not present then extensions are
  ignored and not copied to the certificate. If set to copy then any
  extensions present in the request that are not already present are
  copied to the certificate. If set to copyall then all extensions
  in the request are copied to the certificate: if the extension is
  already present in the certificate it is deleted first. See the
  WARNINGS section before using this option.

  ...

  The copy_extensions option should be used with caution. If care is
  not taken then it can be a security risk. For example if a certificate
  request contains a basicConstraints extension with CA:TRUE and the
  copy_extensions value is set to copyall and the user does not spot
  this when the certificate is displayed then this will hand the
  requester a valid CA certificate.
  
  This situation can be avoided by setting copy_extensions to copy
  and including basicConstraints with CA:FALSE in the configuration
  file. Then if the request contains a basicConstraints extension it
  will be ignored.
  
  It is advisable to also include values for other extensions such
  as keyUsage to prevent a request supplying its own values.
  
  Additional restrictions can be placed on the CA certificate itself.
  For example if the CA certificate has:
  
   basicConstraints = CA:TRUE, pathlen:0
  
  then even if a certificate is issued with CA:TRUE it will not be
  valid.

-- 
	Viktor.