Hey there: It should be noted that this is an EXCEEDINGLY BAD thing to do, since it more or less removes any control that the CA has over the certificates that it issues, and unless the Registration Authority is VERY careful about examining all of the requests in detail, all manner of evil and bad things could happen, including:
- The CA could inadvertantly create a SubCA, if the request has "basicConstraints: CA:TRUE" and the appropriate keyUsage fields set. - The CA could sign for SAN values that it has not proofed. - The CA could sign for keyUsage and ExtendedKeyUsage values which it may not grant or wish to grant the Subscriber Certificate - The CA could sign asserting that the end-entity certificate conforms to a policy that it does not (leading to potentially serious legal implications for the CA including charges of fraud and misrepresentation). All that the attacker has to do with this option enabled is supply the CA with an request with each or all of those extensions present and appropriately configured. All in all, unless this is a test CA that is clearly marked as non- trustworthy, then this is probably not at all what you want to do, and could have potentially serious implications not only at a technical level, but at a liability and organisational level. Best Regards, Patrick. On September 19, 2010 09:20:51 pm Gaiseric Vandal wrote: > FYI, enabling the following line in openssl.cnf has resolved the problem. > > > > copy_extensions = copy > > > > > > > > From: Gaiseric Vandal [mailto:gaiseric.van...@gmail.com] > Sent: Saturday, September 18, 2010 7:09 PM > To: openssl-users@openssl.org > Subject: RE: Confusion about subject alternative names > > > > Some additional info: > > > > My openssl.cnf file includes the following > > > > --------------------------------------------------------------------------- > - ----------------------------------------------------------- > > policy = policy_anything > > > > [ policy_anything ] > > countryName = optional > > stateOrProvinceName = optional > > localityName = optional > > organizationName = optional > > organizationalUnitName = optional > > commonName = supplied > > emailAddress = optional > > subjectAltName = optional > > .. > > > > # req_extensions = v3_req # The extensions to add to a certificate request > > > > [ req_distinguished_name ].. > > subjectAltName = Subject Alternate Name > > subjectAltName_default = www.foo.com > > > > --------------------------------------------------------------------------- > - ----------------------------------------------------------- > > > > > > Openssl is configured as a CA. > > > > I had added the entries for subjectAltName. I do get prompted for this > when creating a certificate signing request (CSR.). > > > > When I submit a CSR created by MS Exchange shell, the policy can NOT > include "subjectAltName = required"- So clearly MS Exchange is not > using the same structure for this as openssl. > > > > > > I am pretty sure I have the correct syntax for subjectAltName in > openssl.cnf. > > > > If I try adding a field in for "planet" it is just ignored. So it seams > clear that openssl is treating "subjectAltName" as a valid entry. > > > > > > The default openssl.cnf included > > > > --------------------------------------------------------------------------- > - ----------------------------------------------------------- > > [ usr_cert ] > > .. > > # This stuff is for subjectAltName and issuerAltname. > > # Import the email address. > > # subjectAltName=email:copy > > # An alternative to produce certificates that aren't > > # deprecated according to PKIX. > > # subjectAltName=email:move > > .. > > --------------------------------------------------------------------------- > - ----------------------------------------------------------- > > > > > > So it looks like openssl.cnf could optionally automatically copy the e-mail > address to subjectAltName. > > > > -Thanks > > > > > > > > > > From: Gaiseric Vandal [mailto:gaiseric.van...@gmail.com] > Sent: Saturday, September 18, 2010 5:08 PM > To: openssl-users@openssl.org > Subject: Confusion about subject alternative names > > > > Hi > > I am using various version of openssl-0.9.x (including > openssl-0.9.8k-1.fc11.i686 on my linux machine altho the cusotmized > openssl.cnf file is probably inherited from a slightly earlier version.) > > When I create a certificate signing request with openssl, I have an option > to specify an Subject Alternative Name (SAN.) The request file (csr) as > well as the resulting certificate includes the SAN as a value in the in the > subject field. > > > Subject: C=US, ST=xxxxx, L=xxxxx, O=xxxxx, OU=IT, > CN=server1.company.com/subjectAltName=server2.company.com/emailAddress=xxxx > x @company.com > > > > With MS Exchange2007, you can use a command from the powershell to generate > a certificate request, which includes optional DNS servers. The csr is > still signed with OpenSSL (I have one openssl machine designated as the > primary CA.) As you can see, the resulting certificate has a separate > Subject Alternative Name field. > > > Subject: C=US, ST=xxxxx, O=xxxxx, OU=xxxxx, CN=server1.company.com > > > X509v3 Subject Alternative Name: > DNS:server1.company.comm, DNS:server2.company.com > > > I need to use a SAN with my Exchange server certificate since the same > certificate is used for several related services, on the same IP address, > but different host names are used to make client access simpler (e.g. > "mail.company.com" for e-mail clients and "webmail.company.com" for those > accessing web-based mail.) > > I am not sure which certificate format is the correct one. And it would be > much easier to use openssl instead of the exchange power shell. > > (Most things in Microsoft can be done via the the GUI, but a few "advanced" > certificate functions require the exchange power shell.) > > > > Thanks -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
