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
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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
