Re: subjectAltName setup
On Sat, Dec 16, 2006, David Newman wrote: For setup of a Postfix box that will serve multiple virtual domains, I would like to generate one cert for all hostnames at which this box will be able to be reached. Following an example in a post from Victor Duchovni [0], I configured the subjectAltName parameter in openssl.cnf with four hostnames and generated a cert. However, I still see only one CN in the resulting cert. You will only see one CN. CN and subjectAltName are two different things. The approved way to represent multiple host names is via subjectAltName which will appear in the extensions list when you display the certificate. If you need multiple CNs (which some software may require) then you need to prompt for multiple CNs. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: subjectAltName setup
On Sun, Dec 17, 2006 at 02:25:29PM +0100, Dr. Stephen Henson wrote: On Sat, Dec 16, 2006, David Newman wrote: For setup of a Postfix box that will serve multiple virtual domains, I would like to generate one cert for all hostnames at which this box will be able to be reached. Following an example in a post from Victor Duchovni [0], I configured the subjectAltName parameter in openssl.cnf with four hostnames and generated a cert. However, I still see only one CN in the resulting cert. You will only see one CN. CN and subjectAltName are two different things. The approved way to represent multiple host names is via subjectAltName which will appear in the extensions list when you display the certificate. If you need multiple CNs (which some software may require) then you need to prompt for multiple CNs. The OP meant multiple SubjectAlternativeName values in the signed certificate, the extensions are not by default copied into the signed certificate. The copy_extensions option described in http://www.openssl.org/docs/apps/ca.html is AFAIK the supported mechanism for importing SubjectAlternativeNames from the request into the certificate. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: subjectAltName setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/06 8:04 AM, Victor Duchovni wrote: On Sun, Dec 17, 2006 at 02:25:29PM +0100, Dr. Stephen Henson wrote: On Sat, Dec 16, 2006, David Newman wrote: For setup of a Postfix box that will serve multiple virtual domains, I would like to generate one cert for all hostnames at which this box will be able to be reached. Following an example in a post from Victor Duchovni [0], I configured the subjectAltName parameter in openssl.cnf with four hostnames and generated a cert. However, I still see only one CN in the resulting cert. You will only see one CN. CN and subjectAltName are two different things. The approved way to represent multiple host names is via subjectAltName which will appear in the extensions list when you display the certificate. If you need multiple CNs (which some software may require) then you need to prompt for multiple CNs. The OP meant multiple SubjectAlternativeName values in the signed certificate Correct. Sorry for the abuse of terminology. , the extensions are not by default copied into the signed certificate. The copy_extensions option described in http://www.openssl.org/docs/apps/ca.html is AFAIK the supported mechanism for importing SubjectAlternativeNames from the request into the certificate. - From previous posts my understanding was that for subjectAltName to work, openssl.cnf required: - - v3_req and alt_names sections - - req_extensions and x509_extensions statements in the [req] section - - subjectAltName statements in the policy section(s) The warnings in that URL above make me unsure where or how to apply copy_extensions as well. Here is a barebones config file. What else is needed to generate a cert for multiple hostnames? thanks dn [ ca ] default_ca = CA_default [ CA_default ] serial = $dir/serial database= $dir/index.txt new_certs_dir = $dir/newcerts certs = $dir/certs certificate = $dir/cacert.pem private_key = $dir/private/cakey.pem default_days= 365 default_md = md5 preserve= no email_in_dn = no nameopt = default_ca certopt = default_ca policy = policy_match [ policy_match ] countryName = match stateOrProvinceName = match organizationName= match organizationalUnitName = optional commonName = supplied emailAddress= optional subjectAltName = optional [ req ] default_bits= 1024 # Size of keys default_keyfile = key.pem # name of generated keys default_md = md5 # message digest algorithm string_mask = nombstr # permitted characters distinguished_name = req_distinguished_name req_extensions = v3_req x509_extensions = v3_req [ req_distinguished_name ] # Variable name Prompt string #-- -- 0.organizationName = Organization Name (company) organizationalUnitName = Organizational Unit Name (department, division) emailAddress= Email Address emailAddress_max= 40 localityName= Locality Name (city, district) stateOrProvinceName = State or Province Name (full name) countryName = Country Name (2 letter code) countryName_min = 2 countryName_max = 2 commonName = Common Name (hostname, IP, or your name) commonName_max = 64 # Default values for the above, for consistency and less typing. # Variable name Value #-- -- 0.organizationName_default = The Sample Company localityName_default= Metropolis stateOrProvinceName_default = New York countryName_default = US [ v3_ca ] basicConstraints= CA:TRUE subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always,issuer:always [ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment # Some CAs do not yet support subjectAltName in CSRs. # Instead the additional names are form entries on web # pages where one requests the certificate... subjectAltName = @alt_names [alt_names] DNS.1 = mail.freedonia.gov DNS.2 = mail.potrzebie.org DNS.3 = mail.furshlugginer.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFhZUryPxGVjntI4IRAhOrAKCdO7+kcPZJCUKn47kRml1OubRIiACfQ8h3 MXLzOXzlFOWtsy2ugU8Ih2A= =fAk/ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager
Re: subjectAltName setup
On Sun, Dec 17, 2006 at 11:06:20AM -0800, David Newman wrote: the extensions are not by default copied into the signed certificate. The copy_extensions option described in http://www.openssl.org/docs/apps/ca.html is AFAIK the supported mechanism for importing SubjectAlternativeNames from the request into the certificate. - From previous posts my understanding was that for subjectAltName to work, openssl.cnf required: - - v3_req and alt_names sections - - req_extensions and x509_extensions statements in the [req] section Yes. - - subjectAltName statements in the policy section(s) No, this has no effect, because the policy section is used to filter the components of the subject DN. It does not apply to v3 extensions. The warnings in that URL above make me unsure where or how to apply copy_extensions as well. http://www.openssl.org/docs/apps/ca.html#CONFIGURATION_FILE_OPTIONS The section of the configuration file containing options for ca is found as follows: If the -name command line option is used, then it names the section to be used. Otherwise the section to be used must be named in the default_ca option of the ca section of the configuration file (or in the default section of the configuration file). So list this in the section named via default_ca or command-line -name option. [ ca ] default_ca= CA_default [ CA_default ] serial= $dir/serial database = $dir/index.txt new_certs_dir = $dir/newcerts certs = $dir/certs certificate = $dir/cacert.pem private_key = $dir/private/cakey.pem default_days = 365 default_md= md5 preserve = no email_in_dn = no nameopt = default_ca certopt = default_ca policy= policy_match Add copy_extensions = copy above. Of course validate the extensions before you sign the request. [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName= optional commonName= supplied emailAddress = optional subjectAltName= optional This only checks the subject DN, so listing subjectAltName here is not useful. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: subjectAltName setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/06 11:28 AM, Victor Duchovni wrote: [ CA_default ] serial = $dir/serial database = $dir/index.txt new_certs_dir= $dir/newcerts certs= $dir/certs certificate = $dir/cacert.pem private_key = $dir/private/cakey.pem default_days = 365 default_md = md5 preserve = no email_in_dn = no nameopt = default_ca certopt = default_ca policy = policy_match Add copy_extensions = copy above. Of course validate the extensions before you sign the request. Got it, thanks! For future reference, I've pasted the entire working openssl.cnf below. One last question: Generating a cert for multiple virtual hosts is only an occasional requirement. Generally this CA will generate certs for one CN and zero alternates. Through trial and error I found that I can leave the subjectAltName stuff in openssl.cnf, and just comment out the req_extensions = v3_ext statement in the req section. Is this valid, or am I losing some other needed functionality? thanks again dn [ ca ] default_ca = CA_default [ CA_default ] dir = . serial = $dir/serial database= $dir/index.txt new_certs_dir = $dir/newcerts certs = $dir/certs certificate = $certs/cacert.pem private_key = $dir/private/cakey.pem default_days= 365 default_md = md5 preserve= no email_in_dn = no nameopt = default_ca certopt = default_ca policy = policy_match copy_extensions = copy [ policy_match ] countryName = match stateOrProvinceName = match organizationName= match organizationalUnitName = optional commonName = supplied emailAddress= optional [ req ] default_bits= 1024 # Size of keys default_keyfile = key.pem # name of generated keys default_md = md5 # message digest algorithm string_mask = nombstr # permitted characters distinguished_name = req_distinguished_name req_extensions = v3_req x509_extensions = v3_req [ req_distinguished_name ] # Variable name Prompt string #-- -- 0.organizationName = Organization Name (company) organizationalUnitName = Organizational Unit Name (department, division) emailAddress= Email Address emailAddress_max= 40 localityName= Locality Name (city, district) stateOrProvinceName = State or Province Name (full name) countryName = Country Name (2 letter code) countryName_min = 2 countryName_max = 2 commonName = Common Name (hostname, IP, or your name) commonName_max = 64 # Default values for the above, for consistency and less typing. # Variable name Value #-- -- 0.organizationName_default = The Sample Company localityName_default= Metropolis stateOrProvinceName_default = New York countryName_default = US [ v3_ca ] basicConstraints= CA:TRUE subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always,issuer:always [ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment # Some CAs do not yet support subjectAltName in CSRs. # Instead the additional names are form entries on web # pages where one requests the certificate... subjectAltName = @alt_names [alt_names] DNS.1 = mail.freedonia.gov DNS.2 = mail.potrzebie.org DNS.3 = mail.furshlugginer.org [ server ] # Make a cert with nsCertType set to server basicConstraints=CA:FALSE nsCertType = server nsComment = OpenSSL Generated Server Certificate subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always [ client ] # Make a cert with nsCertType set to client basicConstraints=CA:FALSE nsCertType = client nsComment = OpenSSL Generated Client Certificate subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD4DBQFFhfvWyPxGVjntI4IRAmYXAJUTtFXQpKkI+N6mzvuVhPdGcsWRAKCu5G7S kJUs02YmBL+/2ed9qpB5vw== =2LNV -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL
Re: subjectAltName setup
On Sun, Dec 17, 2006 at 06:24:22PM -0800, David Newman wrote: One last question: Generating a cert for multiple virtual hosts is only an occasional requirement. Generally this CA will generate certs for one CN and zero alternates. In that case don't add copy_extensions = copy to CA_default and create a CA_with_exts that is like CA_default, but enables extension copying. Use an explicit -name CA_with_exts only when you need it. Through trial and error I found that I can leave the subjectAltName stuff in openssl.cnf, and just comment out the req_extensions = v3_ext statement in the req section. Is this valid, or am I losing some other needed functionality? If you always generate the certs yourself, you can suppress the alternative names either in the request, in the CA or perhaps in both. I am fond of building .cnf files on the fly and using them via -config. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: subjectAltName setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/06 7:14 PM, Victor Duchovni wrote: On Sun, Dec 17, 2006 at 06:24:22PM -0800, David Newman wrote: One last question: Generating a cert for multiple virtual hosts is only an occasional requirement. Generally this CA will generate certs for one CN and zero alternates. In that case don't add copy_extensions = copy to CA_default and create a CA_with_exts that is like CA_default, but enables extension copying. Use an explicit -name CA_with_exts only when you need it. Through trial and error I found that I can leave the subjectAltName stuff in openssl.cnf, and just comment out the req_extensions = v3_ext statement in the req section. Is this valid, or am I losing some other needed functionality? If you always generate the certs yourself, you can suppress the alternative names either in the request, in the CA or perhaps in both. I am fond of building .cnf files on the fly and using them via -config. Hmmm. If I comment out only copy_extensions statement and generate a request, I still see the alternative names. However, the alternative names are gone if I comment out only req_extensions. This seems to contradict what you said above. But is it a valid config? thanks again dn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFhhiByPxGVjntI4IRAn1XAKC9Tiyl3ZO4I+hWJafpAJLn8eWVeQCghUvX CDAdHvqAglMUi5xKLxA6p1A= =jXYI -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: subjectAltName setup
On Sun, Dec 17, 2006 at 08:26:42PM -0800, David Newman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/06 7:14 PM, Victor Duchovni wrote: On Sun, Dec 17, 2006 at 06:24:22PM -0800, David Newman wrote: One last question: Generating a cert for multiple virtual hosts is only an occasional requirement. Generally this CA will generate certs for one CN and zero alternates. In that case don't add copy_extensions = copy to CA_default and create a CA_with_exts that is like CA_default, but enables extension copying. Use an explicit -name CA_with_exts only when you need it. Through trial and error I found that I can leave the subjectAltName stuff in openssl.cnf, and just comment out the req_extensions = v3_ext statement in the req section. Is this valid, or am I losing some other needed functionality? If you always generate the certs yourself, you can suppress the alternative names either in the request, in the CA or perhaps in both. I am fond of building .cnf files on the fly and using them via -config. Hmmm. If I comment out only copy_extensions statement and generate a request, I still see the alternative names. However, the alternative names are gone if I comment out only req_extensions. This seems to contradict what you said above. But is it a valid config? No, you comment out copy_extensions to ignore extensions in the request when generating a certificate. I did not say that this prevents the extensions from being added to the request. To suppress them in the request ommit them from the request section of the .cnf file, which I suggest you build on the fly. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: subjectAltName setup
On Sat, Dec 16, 2006 at 03:35:45PM -0800, David Newman wrote: openssl ca -out certs/lance-cyrus.pem \ -in csrs/lance-cyrus.csr -config ./openssl.cnf \ -extensions server You need to arrange for the CA to include the SubjectAlternativeName extension values in the signed cert... For a self-signed (req -x509) certificate, this is easy: req_extensions = v3_req x509_extensions = v3_req [ v3_req ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = lance.eng.networktest.com DNS.2 = mail.freedonia.gov DNS.3 = mail.potrzebie.org DNS.4 = mail.furshlugginer.org You need additional CA policy settings, you should be able to Google these... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
