Re: Some OpenSSL certificate and key questions

[Bilal Shahid]

Hi Charles,
Thanks for your reply. I guess I did frame my question in a confusing 
manner.

Basically, I would like to find out how the two extensions "Key Usage" and 
"Extended Key Usage" behave if both are present in the same certificate. 
Documentation mentions that "Extended Key Usage" may used "in addition to" 
OR "in place of" the "Key Usage".

Now what I understand is that using the "extensions" is a way of LIMITING 
the possible uses of a Certificate. I am not sure whether I am correct in 
this understanding.

Please take a look at the following two different (partial) script fragments 
that I am using to generate "end user certificates".

Case 1:
openssl req -new -keyout newreqkey.pem -out newreq.pem -days 730 -passin 
pass:whatever -passout pass:whatever
openssl ca  -policy policy_anything -out newcert.pem -passin pass:whatever 
-key whatever -extensions xpclient_ext -extfile xp
extensions -infiles newreq.pem

openssl pkcs12 -export -in newcert.pem -inkey newreqkey.pem -out 
cert-clt.p12 -clcerts -passin pass:whatever -passout pass:wh
atever
openssl pkcs12 -in cert-clt.p12 -out cert-clt.pem -passin pass:whatever 
-passout pass:whatever
openssl x509 -inform PEM -outform DER -in cert-clt.pem -out cert-clt.der

openssl rsa -in newreqkey.pem -outform DER -out newreqkey.der
As you can see from this (partial) script that I am including the 
xpclient_ext extension (which I think is an Extended Key Usage key 
extension; xpserver_ext while generating the Server side certificate) while 
generating this script. The output of the command (openssl x509 -noout -text 
-in cert-clt.pem) is the following (again partial output only):

X509v3 extensions:
           X509v3 Extended Key Usage:
               TLS Web Client Authentication
AS you can see from this output, the certificate ony has "Extended Key 
Uasge" field included and no "Key Usage" field.

Case 2:
Following script takes out the "-extensions" flag:
openssl req -new -keyout newreqkey.pem -out newreq.pem -days 730 -passin 
pass:whatever -passout pass:whatever
openssl ca  -policy policy_anything -out newcert.pem -passin pass:whatever 
-key whatever -infiles newreq.pem

openssl pkcs12 -export -in newcert.pem -inkey newreqkey.pem -out 
cert-clt.p12 -clcerts -passin pass:whatever -passout pass:wh
atever
openssl pkcs12 -in cert-clt.p12 -out cert-clt.pem -passin pass:whatever 
-passout pass:whatever
openssl x509 -inform PEM -outform DER -in cert-clt.pem -out cert-clt.der

openssl rsa -in newreqkey.pem -outform DER -out newreqkey.der
The output of the command (openssl x509 -noout -text -in cert-clt.pem) is 
the following (again partial output only):

X509v3 extensions:
           X509v3 Basic Constraints:
               CA:FALSE
           X509v3 Key Usage:
               Digital Signature, Non Repudiation, Key Encipherment
           Netscape Comment:
               OpenSSL Generated Certificate
           X509v3 Subject Key Identifier:
               E7:6A:A2:3F:01:96:AB:D2:86:5E:F0:CB:33:A8:15:79:77:7E:BD:D6
           X509v3 Authority Key Identifier:
               
keyid:A7:D4:69:D4:9C:9C:7E:25:C6:C8:B0:A6:BC:B6:5C:01:CC:15:E5:9A
               DirName:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
               serial:00

Now this shows us various "Key Usage" extensions.
So basically, I have two different sets of certificates. For Case 1, when 
the Server sends its certificate to the Client for verification, it fails in 
the following code:

ssl3_get_server_certificate()
|
------> verify_cert_chain()
         |
         -------> check_chain_purpose()
                   |
                   ------->X509_check_purpose()
                            |
                            -------> ku_reject()
citing the error "Invalid Purpose".
For Case 2, no such error happens and Client successfully verfiies the 
Server certificate nad in reply sends its own (which the Server is currently 
refusing to verify on the pretext of "Bad Signature but that is another 
story).

From the comparision of these two cases of certificate generation it seems 
to me that "Extended Usage Key" cannot co-exist with "Key Usage" field. Of 
course I am wrong according to the documentation but I haven't yet figured 
out a way out of this.

What I am trying to do is mutual authentication between a 802.1X Supplicant 
and the FreeRADIUS Server using EAP-TLS. Most of the HOW-TOs that I have 
read on the internet for carrying out this task mention that 
ClientAuth/ServerAuth "Extended Key Usage" MUST be enabled for this 
authentication to occur. I am not sure whether Case 1 is more appropriate 
for my task or case 2.

Please, do let me know of your comments and any way out of this situation.
Thanks,
Bilal
From: Charles B Cranston <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Some OpenSSL certificate and key questions
Date: Tue, 02 Nov 2004 09:10:22 -0500
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]
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.com/

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]