Hi there: Yes - the right way is to correctly configure the extensions in the openssl.cnf used on the CA, and have the SAN and Subject NOT be used out of the request, but be input from the CA.
If you need to see how this might be done, we've got a tutorial at: http://www.carillon.ca/library/openssl_testca_howto_1.3.pdf Even within a corporate environment, you can have problems with malicious insiders, and if they can trick someone outside of your organisation to trust you as a CA, then you could get in all manner of trouble if you trust user input. (I presume you have at least a rudimentary way to tie a given private key to a Subscriber? - that is what is important, not the contents of the CSR) Best Regards, Patrick. On 2010-09-20, at 2:12 PM, Gaiseric Vandal wrote: > I am mostly using openssl to sign certificates for corporate servers for > corporate users only. So I am the only one using it to issue certificates. > As much as possible I want all certificates to have a common CA- that way > corporate end users only need to manually install the public cert for the CA > itself. I can leave the "copy_extensions = copy" option disabled by default > and just enable when specifically needed. > > > However, if there is another way to do this then I would like to know. The > only other option I can see if to configure a Microsoft CA or some other CA > that does not use openssl. > > -Thanks > > > > On 09/20/2010 12:07 PM, Patrick Patterson wrote: >> 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 >>> >> > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org --- 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 --- 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
