Re: Confusion about subject alternative names - resolved
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
Re: Confusion about subject alternative names - resolved
Hi there: Yes - the right way is to correctly configure the extensions 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
Re: Confusion about subject alternative names - resolved
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. 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 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. On 09/22/2010 10:31 AM, Patrick Patterson wrote: 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
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Confusion about subject alternative names - resolved
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
Re: Confusion about subject alternative names - resolved
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
Re: Confusion about subject alternative names - resolved
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=x, L=x, O=x, OU=IT, CN=server1.company.com/subjectAltName=server2.company.com/emailAddress= 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
Re: Confusion about subject alternative names - resolved
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
RE: Confusion about subject alternative names - resolved
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=x, L=x, O=x, OU=IT, CN=server1.company.com/subjectAltName=server2.company.com/emailAddress=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=x, O=x, OU=x, 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
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=x, L=x, O=x, OU=IT, CN=server1.company.com/subjectAltName=server2.company.com/emailAddress=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=x, O=x, OU=x, 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
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=x, L=x, O=x, OU=IT, CN=server1.company.com/subjectAltName=server2.company.com/emailAddress=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=x, O=x, OU=x, 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
Re: Confusion about subject alternative names
The problem is not so much with IMAP or SMTP. You can easily use IIS to create separate certificate requests so those services.In the MS Exchange2007 Management Console (GUI) it is pretty easy to select the certificate to use for IMAP SSL connection. For some very odd reason you have to use the Exchange Power Shell (command line) to specify the certificate for the SMTP TLS connection (you have to specify the thumbprint of the certificate you want to use.) Digress: if Microsoft WONT give you a GUI way to do something, wouldn't it be simpler just so stick with simple configuration files like a lot of unix/linus stuff?I realize the powershell stuff lets to script stuff, which is great for adding 500 users. Anyway, the problem is really with some of MS Exchanges web-based Client Access Services (autoconfigure service, which also handles things like scheduleing )-If you configure outlook 2007 to use exchange1 it will connect to IIS, get the mismatched certificate, and complain.This gets worse if you have multiple Exchange servers. Re: Confusion about subject alternative names Peter Sylvester Thu, 02 Sep 2010 01:53:49 -0700 Since webmail, imap, smtp(s) all operate on different ports, and you have different listeners, the correct way to me seems to use three certificates with the desired hostnames etc. Having the same IP address doesn't matter in this particular case.
RE: Confusion about subject alternative names
Hi Gaiseric, -Original Message- From: Gaiseric Vandal 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=x, L=x, O=x, OU=IT, CN=server1.company.com/subjectAltName=server2.company.com/emailaddress=xx...@company.com I've never seen a subjectAlternativeName construction like this. This is not what openssl does by default. So this behaviour is related to the changes you did in your openssl.conf file. Looks like you defined your own private RDN subjectAltName. This is not standard. And nobody else will understand this! I recommend you read up about using the openssl req and ca commands, or alternatively the x509 command if you are using this to issue your certicates, and the format of the configuration file: man req man ca man x509 man config man x509v3_config HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Confusion about subject alternative names
Since webmail, imap, smtp(s) all operate on different ports, and you have different listeners, the correct way to me seems to use three certificates with the desired hostnames etc. Having the same IP address doesn't matter in this particular case. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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=/x/, L=/x/, O=/x/, OU=IT, CN=server1.company.com/subjectAltName=server2.company.com/emailAddress=/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=/x/, O=/x/, OU=/x/, 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
