You should probably read chapter 4 of RFC 3280
http://www.ietf.org/rfc/rfc3280
particularly 4.2.1.3 Key Usage and 4.2.1.13 Extended Key Usage
Also the text file openssl.txt in the doc directory of the
openssl distribution.
I don't use CA (I use x509 instead) so maybe that has something
to do with the way you're framing the question, but your term
"include extensions" as some sort of binary thing is difficult
to understand. In general, the documentation supplies suggested
defaults for dealing with a certificate that does not have the
Key Usage or Extended Key Usage extensions (either from being
an old-format cert without any extensions or from being a new
format cert with either no actual extensions or with extensions
of types other than Key Usage/Extended Key Usage).
However, the verifying party software (in this case your client)
does what its software has been programmed to do, and if this
differs from the suggested default behaviour, your only recourse
is to put the extensions in and hope that the software at least
does the right thing when it had been told explicitly to do so.
From rfc3279 Algorithms and Identifiers for the Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile:
...
2.3.1 RSA Keys
...
If the keyUsage extension is present in an end entity certificate
which conveys an RSA public key, any combination of the following
values MAY be present:
digitalSignature;
nonRepudiation;
keyEncipherment; and
dataEncipherment.
If the keyUsage extension is present in a CA or CRL issuer
certificate which conveys an RSA public key, any combination of the
following values MAY be present:
digitalSignature;
nonRepudiation;
keyEncipherment;
dataEncipherment;
keyCertSign; and
cRLSign.
However, this specification RECOMMENDS that if keyCertSign or cRLSign
is present, both keyEncipherment and dataEncipherment SHOULD NOT be
present.
...
From this I would suspect CA certificates should have keyCertSign
and end-user certificates should have keyEncipherment, since what
the certificate is being used for is to transfer a symmetric key
from the client to the server for SSL usage.
As for the extended key usage, I would suspect that clientAuth
would be right for both CA and end-user certificates.
As for the critical bit, I did have to back off the critical bit
on Extended Key Usage but I do have it set for Basic Constraints
and Key Usage. See paragraph 3 of http://cert.umd.edu/cadoc?ssign
At the time I cared about Netscape 4x...
> 1- I noticed that the cerificates generated with the "extensions"
> (extended key usage filed) enabled, do not have other basic key usages
> like DigitalSignature, Key Rupidiation and Key Encipherment. I mean to
> say that either the certificate can have an extended key usage OR it
> can have Digital Signature, Key Rupidiation etc. Is this the correct
> behavior?
Again, I cannot understand your usage of "extensions enabled".
Perhaps an "openssl x509 -noout -text -in <cert>" would shed
some more light on what certificate is actually being generated?
> 2- Is the extended key usage field necessary when we are trying to
> authenticate a Client to a Server in the 802.1X environment? OR we can
> authenticate a client to the Server without this extension field
> as well.
As stated, the documentation suggests default behavior if the
extension is not present, and for backwards-compatability's sake
the behaviour should be to succeed not fail. Thus, unless the
Server is being persnickety about requiring the extension, or the
extension is marked critical so the server has no choice, the
server should honor the certificate without the extension.
Your mileage may vary. Offer not valid in sector R or S.
Bilal Shahid wrote:
Hi,
I am a newbie at using openssl and facing numerous problems right now. I
am using OpenSSL, FreeRADIUS Server and a DOT1X Supplicant. Basically
trying to get the Supplicant to authenticate to the FreeRADIUS Server
using EAP-TLS.
I used a script (CA.All) to generate the three certificates for root,
server and the supplicant. Now here is the problem.
If I include "extensions" (extended key usage field) in my certificates
(Client Authenticatio/Server Authentication), my Client always
(Supplicant) fails in the following call in the file s3_clnt.c:
ssl3_get_server_certificate()
|
------> verify_cert_chain()
|
-------> check_chain_purpose()
|
------->X509_check_purpose()
|
-------> ku_reject()
Basically, the error that is returned here is
X509_V_ERR_INVALID_PURPOSE. I explored till the very lowest level and
found out that field x->ex_xkusage is set 0x00 EVEN THOUGH the
certificate does have "extension" enabled in it.
On the other hand when I generate all the certificates without the flag
"extension", I do not see this error. But then, when the Client does
finally send its own certificate to the Server, the Server complains of
BAD SIGNATURE.
I would relly really appreciate if someone can help me with this issue.
Following are my questions:
1- I noticed that the cerificates generated with the "extensions"
(extended key usage filed) enabled, do not have other basic key usages
like DigitalSignature, Key Rupidiation and Key Encipherment. I mean to
say that either the certificate can have an extended key usage OR it can
have Digital Signature, Key Rupidiation etc. Is this the correct behavior?
2- Is the extended key usage field necessary when we are trying to
authenticate a Client to a Server in the 802.1X environment? OR we can
authenticate a client to the Server without this extension field as well.
Thanks,
Bilal
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.com/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
--
Charles B (Ben) Cranston
mailto: [EMAIL PROTECTED]
http://www.wam.umd.edu/~zben
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
