Hi there: See my answer inline:
On 2010-09-22, at 8:06 PM, Gaiseric Vandal wrote: > 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. > No, they get them from environment variables of the shell that you are using (ENV::EMAILADDR says to get the value for that out of a shell environment variable called "EMAILADDR". If you read the entire howto, you would see several shell scripts that help you create exactly what it is that you are trying to create (including ones for Devices, and Microsoft Communications Services (or whatever they are calling them these days) servers). > Or maybe I need a separate openssl-ext.cnf file? > If you follow the steps in the docs, you should get an OpenSSL configuration for a CA that allows you to do everything that you would want to, and more. > > 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? > Don't set the policy - set up your openssl.cnf files to correctly populate the extensions. You should NOT have any mention of SAN in either the req_distinguished_name section or the policy section. Instead, you should have the correct values being populated into the SAN in your own version of the v3_ext section. > 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. > > No - just about everything supports SAN, all you have to do is configure your CA correctly. I have yet (in over 10 years of playing around with PKI) to run into any CA that does NOT handle SAN. Most will not get it out of the Subject DN (since it is a horrible, horrible idea, and definitely not in line with best practice) of the Certificate Request, but everything will correctly handle it when building a certificate. Even ancient versions of OpenSSL could handle all of the various different kinds of values that you could put in SAN, although you had to be fairly proficient in encoding arbitrary bits of ASN.1 in DER to figure out the correct incantation. Have fun. Patrick. --- 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
