I use openssl to create certs for servers only, not for users. If I create
a key with openssl, then create a CSR with "openssl req", it would prompt me
for a subjectAltName. Openssl ca will sign CSR's from MS Exchange but not
would include the subjectAltName until I enabled "copy extensions." When I
create a CSR on MS Exchange, the key is automatically created as well.
In the PDF you suggested, there is the following examples...
____________________________________________________________________________
___________________
The following section in openssl-ext.cnf shows how extensions compatible
with the above
can be produced in a certificate generated by OpenSSL:
[ usr_id_ext ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
nsComment = "Do Not trust ID
Cert for CertiPath interop TEST purposes only"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
subjectAltName = email:$ENV::EMAILADDR
authorityInfoAccess = @aia_points
crlDistributionPoints = @crl_dist_points
certificatePolicies = ia5org, @my_medium_sw_policy
[ usr_sign_ext ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, nonRepudiation
extendedKeyUsage = emailProtection, anyExtendedKeyUsage
nsComment = "Do Not trust Signature
Cert for CertiPath interop
only"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
subjectAltName = email:$ENV::EMAILADDR
authorityInfoAccess = @aia_points
crlDistributionPoints = @crl_dist_points
certificatePolicies = ia5org, @my_medium_sw_policy
____________________________________________________________________________
___________________
To me this looks like it is configured to pick up the e-mail address from
the CSR.
Or maybe I need a separate openssl-ext.cnf file?
My openssl.cnf file includes the following (I think I put some of this in
the original post...)
____________________________________________________________________________
___________________
[ policy_anything ]
...
subjectAltName = optional
...
# req_extensions = v3_req # The extensions to add to a certificate request
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
countryName_min = 2
countryName_max = 2
...
# I added the following line
subjectAltName = Subject Alternate Name
subjectAltName_default = www.foo.com
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
____________________________________________________________________________
___________________
If I set the policy to require a SAN, "openssl ca" will reject the CSR's
from MS Exchange, but I think it will be OK with the CSR's from "openssl
req." I am not sure if this means that openssl.cnf is not configured to
have the ca create certs with v3 extensions?
Re DogTag- I don't think I have tried having DogTag sign a "SAN" CSR from
MS Exchange. It had trouble signing "SAN" CSR's that I generated with
"openssl req." My understanding had been that not all CA's supports SAN
anyway. This is probably something for the pki-us...@redhat.com forum. I
suspect that the problem may have been with openssl not DogTag.
Apart from the SAN issue, OpenSSL has been able to handle creating keys and
certs to use with MS Apps, or signing CSR's created by MS IIS or MS
Exchange. (sometimes you have to convert certs from PEM to DER or vice
versa.)
Thanks for your help.
-----Original Message-----
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Patrick Patterson
Sent: Wednesday, September 22, 2010 6:48 PM
To: openssl-users@openssl.org
Subject: Re: Confusion about subject alternative names - resolved
On 2010-09-22, at 6:38 PM, Gaiseric Vandal wrote:
> Thanks for the link.
>
> I still need the CA to load the SAN parameter from the request- it looks
like a lot of the defaults would be to copy the e-mail address into the SAN
field.
>
Why? Why not just have the CA just put the appropriate value into the end
Certificate?
> I don't use openssl at this point to generate certs for users. No one
besides me uses openssl ca on this server anyway. Of course, that doesn't
stop anyone from using openssl on their own machine to create whatever keys
and certs they want anyway- I could create CA configuration for
microsoft.com and use it to create send "Secure" e-mail from "microsoft."
>
If you don't use OpenSSL to generate certs, what tool are you using to Sign
them then (generating and signing certs are pretty much the same option -
perhaps you meant that you don't use OpenSSL to generate keypairs and
CSRs?)?
> If I start dealing with user certificates then I would probably need a
more full featured CA solution that allows web-based user requests and key
escrow. I have started tinkering with the "DogTag" (opensource version of
redhat cert server) but so far not sure if it supports the SAN extensions
properly. I may have to suck it up and just install the MS CA services to
have something that plays nice with MS Exchange and other MS services. I
try to avoid MS Solutions because they tend to "optimize" standards.
>
I'm not sure what you are talking about - DogTag (and RedHat cert server)
definitely can be configured to do just about anything you may need. And
OpenSSL has absolutely no problem generating any certs that a Microsoft
environment may need. Having OpenSSL generate certs that are usable for
Exchange is rather trivial.
Anyways - Have fun.
---
Patrick Patterson
President and Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca
tel: +1 514 485 0789
mobile: +1 514 994 8699
fax: +1 450 424 9559
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
