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

Reply via email to