Re: subjectAltName setup

2006-12-17 Thread Dr. Stephen Henson
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

2006-12-17 Thread Victor Duchovni
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

2006-12-17 Thread David Newman
-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

2006-12-17 Thread Victor Duchovni
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

2006-12-17 Thread David Newman
-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

2006-12-17 Thread Victor Duchovni
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

2006-12-17 Thread David Newman
-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

2006-12-17 Thread Victor Duchovni
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: Creating CA problem

2006-12-17 Thread Jeppe Bundsgaard

Hi
I have the same problem. I have tried to deinstall and reinstall openssl
(and manually deleting misc where CA.pl is located) - but I still get the
error. What shall I do to get the newer version of CA.pl?
Regards
Jeppe 

MaciekZ wrote:
 
 Thx it works pretty fine now.
 Thx for your help
 
 Best regards 
 
 Maciek
 
 MaciekZ wrote:
 
 Hello everyone :)
 
 I have a problem with creating CA with CA.pl script
 
 Whenever I run ./CA-.pl -newca everything works fine until the script
 displays  unknown option -create_serial 
 
 %cd /usr/local/openssl/misc/
 %./CA.pl -newca
 
 CA certificate filename (or enter to create)
 
 Making CA certificate ...
 Generating a 1024 bit RSA private key
 .++
 ++
 writing new private key to './demoCA/private/cakey.pem'
 Enter PEM pass phrase:
 Verifying - Enter PEM pass phrase:
 -
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a
 DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 -
 Country Name (2 letter code) [AU]:PL
 State or Province Name (full name) [Some-State]:Slaskie
 Locality Name (eg, city) []:Katowice
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Dom
 Organizational Unit Name (eg, section) []:WR
 Common Name (eg, YOUR name) []:Maciek
 Email Address []:[EMAIL PROTECTED]
 
 Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:
 unknown option -create_serial
 usage: ca args
 
  -verbose- Talk alot while doing things
  -config file- A config file
  -name arg   - The particular CA definition to use
  -gencrl - Generate a new CRL
  -crldays days   - Days is when the next CRL is due
  -crlhours hours - Hours is when the next CRL is due
  -startdate YYMMDDHHMMSSZ  - certificate validity notBefore
  -enddate YYMMDDHHMMSSZ- certificate validity notAfter (overrides
 -days)
  -days arg   - number of days to certify the certificate for
  -md arg - md to use, one of md2, md5, sha or sha1
  -policy arg - The CA 'policy' to support
  -keyfile arg- private key file
  -keyform arg- private key file format (PEM or ENGINE)
  -key arg- key to decode the private key if it is encrypted
  -cert file  - The CA certificate
  -in file- The input PEM encoded certificate request(s)
  -out file   - Where to put the output file(s)
  -outdir dir - Where to put output certificates
  -infiles    - The last argument, requests to process
  -spkac file - File contains DN and signed public key and challenge
  -ss_cert file   - File contains a self signed cert to sign
  -preserveDN - Don't re-order the DN
  -noemailDN  - Don't add the EMAIL field into certificate' subject
  -batch  - Don't ask questions
  -msie_hack  - msie modifications to handle all those universal
 strings
  -revoke file- Revoke a certificate (given in file)
  -subj arg   - Use arg instead of request's subject
  -extensions ..  - Extension section (override value in config file)
  -extfile file   - Configuration file with X509v3 extentions to add
  -crlexts .. - CRL extension section (override value in config file)
  -engine e   - use engine e, possibly a hardware device.
  -status serial  - Shows certificate status given the serial number
  -updatedb   - Updates db for expired certificates
 
 when I used CA.sh -newca the script insted of unknown option
 -create_serial  dislayed unknown options -selfsign
 
 I didn't make any changes in files CA.pl CA.sh and openssl.cnf. What
 should I change in order to cretate CA ??
 Should I modify something?
 
 I'm using FreeBSD 6.0 RELASE #p15 with custom kernel and openssl-0.9.8d
 instaled form ports
 
 Thx for your time and help
 
 With regards
 
 Maciek
 
  
 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Creating-CA-problem-tf2723833.html#a7920047
Sent from the OpenSSL - User mailing list archive at Nabble.com.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]