On 25 July 2013 19:08, Dr. Stephen Henson <st...@openssl.org> wrote:
> On Thu, Jul 25, 2013, Marios Makassikis wrote:
>
>> On 26 June 2013 18:44, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
>> > On Wed, Jun 26, 2013 at 05:29:52PM +0200, Marios Makassikis wrote:
>> >
>> >> >> By enabling debug information in the program, I was able to obtain
>> >> >> these error messages:
>> >> >>
>> >> >> pppd[2236]: EAP-TLS SSL error stack:
>> >> >> pppd[2236]: error:0D0C5006:asn1 encoding
>> >> >> routines:ASN1_item_verify:EVP lib
>> >> >>
>> >> >> and
>> >> >>
>> >> >> err: 7 (certificate signature failure)
>> >
>> > The error "certificate signature failure" happens only when the
>> > public key of an issuer certificate in the chain does not generate
>> > a matching signature for its child certificate. Either the trust
>> > store (CAfile, CApath, ...) certificates are not identical in the
>> > two test cases, or one of the two parties sends a different chain,
>> > or the handshake is somehow corrupted.
>> >
>> > crypto/x509/x509_vfy.c:
>> > internal_verify():
>> > ...
>> > else if (X509_verify(xs,pkey) <= 0)
>> > {
>> > ctx->error=X509_V_ERR_CERT_SIGNATURE_FAILURE;
>> >
>> > Look closely with wireshark at the chains captured on the machine
>> > where the error is detected. Are the peer certificate chains the
>> > same in every detail between the two library versions?
>> >
>> > Are both cases using compression? Any other differences?
>> >
>>
>> I meant to reply to this earlier but I got busy with other stuff. Anyhow, I
>> took some time and redid some tests:
>>
>> - ppp with EAP-TLS patch compiled with libssl 0.9.8o-4squeeze14 works ok
>> (I had some surprises with CRL handling, but that's besides the point
>> right now)
>>
>> - ppp with EAP-TLS patch compiled with libssl 1.0.1e-2 exhibits the same
>> behaviour I originally described, i.e.: server fails to validate
>> signature and sends an alert message to the client.
>>
>> I tried two scenarios:
>> a) one root CA, generates two intermediate CAs. The first intermediate CA
>> is used to generate a certificate for the server, and the second CA
>> generates certificates for clients.
>> b) one root CA, used to generate two certificates (1 for the server and 1
>> for the client).
>>
>>
>> In both cases, only the server validates the client cert. Additionally, I
>> made
>> sure to use large key sizes (2048 bits) and SHA1 as the algorithm to use for
>> message digests as MD5 is broken.
>>
>> I noticed that the error occurs if one of the two peers is using the binary
>> linked with libssl 1.0.1.
>>
>
> Well that error is caused by a certificate chain verification failure. In
> particular the signature verification of a certificate using the key in it's
> issuer.
>
> Possibly cause of that is a failure of the cryptographic algorithm (OpenSSL
> bug or compiler bug) or for some reason OpenSSL isn't using the correct
> certificate to verify the signature.
>
>>
>>
>> Server capture with libssl0.9.8: http://pastebin.com/ndeakdnK
>> Server capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
>> Client capture with libssl0.9.8: http://pastebin.com/z9fbA7DN
>> Client capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
>>
>>
>> I can share the certs & ca files also if needed.
>>
>
> OpenSSL (among other things) does this when verifying the certificate chain:
>
> openssl verify -CAfile root.pem -untrusted allcerts.pem ee.pem
>
> where "allcerts.pem" is the complete peer chain and "ee.pem" is the peer
> certificate. I'd be interested to see what that commands produces for
> different version. If you use a directory and use -CApath instead.
OpenSSL 1.0.1e2 :
$ openssl verify -CAfile demoCA/cacert.pem client_cert/clientcert.pem
client_cert/clientcert.pem: OK
OpenSSL 0.9.8o :
$ openssl verify -CAfile demoCA/cacert.pem client_cert/clientcert.pem
client_cert/clientcert.pem: OK
I'm not sure what should go in the allcerts.pem. Since there is no intermediate
signing CA, I guess the chain is just the peer cert. In that case, I
also get a 'OK'
I should also note that I tried running s_client and s_server to
verify the certs validate:
$ openssl s_server -cert server_cert/servercert.pem -key
server_cert/server.key -Verify 5 -CAfile demoCA/cacert.pem -tls1
verify depth is 5, must return a certificate
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr
depth=1 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN =
rootca.example.com
verify return:1
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN =
client.example.com
verify return:1
$ openssl s_client -connect 10.0.1.3:4433 -cert
ca_new_test/client_cert/clientcert.pem -key
ca_new_test/client_cert/client.key -CAfile
ca_new_test/demoCA/cacert.pem -tls1
CONNECTED(00000003)
depth=1 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN =
rootca.example.com
verify return:1
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN =
server.example.com
verify return:1
---
Certificate chain
0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.example.com
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=rootca.example.com
1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=rootca.example.com
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=rootca.example.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDwjCCAqqgAwIBAgIJALnnzpooRnYiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQxGzAZBgNVBAMMEnJvb3RjYS5leGFtcGxlLmNvbTAeFw0x
MzA3MjUxNDU5MjFaFw0xNDA3MjUxNDU5MjFaMGIxCzAJBgNVBAYTAkFVMRMwEQYD
VQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBM
dGQxGzAZBgNVBAMMEnNlcnZlci5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBANTpCn9HdpqDvT8q3Nfc9mgF6gbSsXyWOeNdcyvJ5LS+
BRk11xaS76dQpnlSQHgfq8Cy8A/jcBqTofvKk9ZKH48IN9v7Y2/X4lkgw+k+2vlp
YWZcp3q1PaBsBEcJYHHUPrSBQTwSBBn2aY6/a+t0YWQCy+Cx+OqNwZxU3ONyh0bx
jsjAYBWGjlR/CUWz4nQlKFOpEMiIffcot8Ho7odz3WkDNoYzvRG6NsZ3yNdjbKZv
bwtTjkoQe3FY0ysjXb6yLzxqzr69c0gHBrP8SyaFbaWWC8aKd/lueaEVzVPVvS64
3LoD+90e91aVpzmuIC3/doDSU0ZxrqeEOGEq8XVISdECAwEAAaN7MHkwCQYDVR0T
BAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNh
dGUwHQYDVR0OBBYEFKhPuLzAlErr7DYiW7jYEz5CEhh9MB8GA1UdIwQYMBaAFFa5
scVxKseVBMyRdeiqTLzV80bUMA0GCSqGSIb3DQEBBQUAA4IBAQBkj7HE9qmTlXdk
OjsFli26zBpI+5i3RBWgJGUwp2uHXUzaRRWA7hbdabYH+jPmiFvTlkkgXmwIgzp8
9XQd0kDqEVlPnNRxd45+BDowBYo9sIYdDatsHxrCQyKGMUZtGFvAtLMaBB0HHYDJ
Bx07xmBs8t1oTdlelPPB9bmKMtSs1kPDmctb0pu0D2HPY3dtnFH0HF2rsVEqUBRX
kls3f6ImjXdjWF2pGFrpQ7wP1Q5/PhCLuptWlT/jXEeR0j1sl8kXhqn01lV0BpEf
yRAEyhCT35dAqfGyJP6SvKUgytbq3b8Q8HMmC94tmo1J3waw7jYyRgOHz/0XWxH/
qykO7kDk
-----END CERTIFICATE-----
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.example.com
issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=rootca.example.com
---
Acceptable client certificate CA names
/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=rootca.example.com
---
SSL handshake has read 3645 bytes and written 2534 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 61C18D5C2A60703A9EDF3C824407176115B37292BE3A4F88B5BA928B72AC90C3
Session-ID-ctx:
Master-Key:
B15F693A928D3202ACC1AA762455D99578F53E2ABF4A5759EFFEF0261430C8FA4C5DFCDC6F0E4CF1A67A16B267D9AD98
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
<snipped the hex part>
Compression: 1 (zlib compression)
Start Time: 1374821699
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
When I replaced openssl on the server with the 0.9.8 version, I had more output:
$ openssl s_server -cert server_cert/servercert.pem -key
server_cert/server.key -Verify 5 -CAfile demoCA/cacert.pem -tls1
verify depth is 5, must return a certificate
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr
depth=1 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=rootca.example.com
verify return:1
depth=0 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=client.example.com
verify return:1
-----BEGIN SSL SESSION PARAMETERS-----
MIIEJAIBAQICAwEEAgA5BAAEMBYWwSg7EBp4voIceh9FVkA50sBhMY6/z2/TZgcJ
H2N83pntw5i4Dfa0GLMvBb4nrqEGAgRR8iFaogQCAhwgo4IDxjCCA8IwggKqoAMC
AQICCQC5586aKEZ2ITANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJBVTETMBEG
A1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkg
THRkMRswGQYDVQQDDBJyb290Y2EuZXhhbXBsZS5jb20wHhcNMTMwNzI1MTQ1NDE0
WhcNMTQwNzI1MTQ1NDE0WjBiMQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1T
dGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMRswGQYDVQQD
DBJjbGllbnQuZXhhbXBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCeC1UU9AfgQV0QNdT4lGa6oEP9BnQnxDs9MQuMrzQ0S7K8bGgTGioYihYo
Ftr77tr7KqclImCZ+gxdNBXHzsFaesJFTamMHvS9B5Egab2K3eYVe2vjK5xVpd7p
vZnPhmMz8kKV27ZU8RswezoGIGXCKW7uSqzUgQQFMoAz5rtXmfDyF7gTJaXXjTw9
Fxc5wzmYbUyLPUdONKqq7H4AoDCpzZbIWk1iIur1MmosZvNivfL+ii/Js/43qf/f
WAGSMYpGLALDLGw/9hIKcM1s34ibYZ7Kwz6xmRo0kjWXzQzs+7ZGYFIsy14afGZo
Q56f8T7oZwqlkexfRRjUUDQi7qnJAgMBAAGjezB5MAkGA1UdEwQCMAAwLAYJYIZI
AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
BBSColgQ1KDEWtd11SDVVEhotfiYqzAfBgNVHSMEGDAWgBRWubHFcSrHlQTMkXXo
qky81fNG1DANBgkqhkiG9w0BAQUFAAOCAQEA2a8YRK2D7r0KGu3XpUDJbi3Yd1sL
vwqdCfmMx6fUAWuZnSJkNrhONDIEBBvF6158tQZwve68EbM2qNvL8J47utWhdFtD
DwpDY0c/LJu1gGAVsdun1QT0ApCuckCQf+fpXaEZ576FqC8zlcDbD53fFKbuowMY
ZpXU1UYU/643tDBBmDJn5zgzm7FW0MIP+LhjsSDUyWntISfR5WLgti23/3WCIt34
0PeSNbBrV4uGu+H570sx6pZ/Q3GinREedLq2dtTLzYpP8wj/akuhB0HVL6yP43DT
FIqldtDT3ygUJBZzRTmaFZIu/8njhzDHAQaYZT4oCaV8wt09wctlL6Z3nKQGBAQB
AAAAqwMEAQE=
-----END SSL SESSION PARAMETERS-----
Client certificate
-----BEGIN CERTIFICATE-----
MIIDwjCCAqqgAwIBAgIJALnnzpooRnYhMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQxGzAZBgNVBAMMEnJvb3RjYS5leGFtcGxlLmNvbTAeFw0x
MzA3MjUxNDU0MTRaFw0xNDA3MjUxNDU0MTRaMGIxCzAJBgNVBAYTAkFVMRMwEQYD
VQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBM
dGQxGzAZBgNVBAMMEmNsaWVudC5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAJ4LVRT0B+BBXRA11PiUZrqgQ/0GdCfEOz0xC4yvNDRL
srxsaBMaKhiKFigW2vvu2vsqpyUiYJn6DF00FcfOwVp6wkVNqYwe9L0HkSBpvYrd
5hV7a+MrnFWl3um9mc+GYzPyQpXbtlTxGzB7OgYgZcIpbu5KrNSBBAUygDPmu1eZ
8PIXuBMlpdeNPD0XFznDOZhtTIs9R040qqrsfgCgMKnNlshaTWIi6vUyaixm82K9
8v6KL8mz/jep/99YAZIxikYsAsMsbD/2EgpwzWzfiJthnsrDPrGZGjSSNZfNDOz7
tkZgUizLXhp8ZmhDnp/xPuhnCqWR7F9FGNRQNCLuqckCAwEAAaN7MHkwCQYDVR0T
BAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNh
dGUwHQYDVR0OBBYEFIKiWBDUoMRa13XVINVUSGi1+JirMB8GA1UdIwQYMBaAFFa5
scVxKseVBMyRdeiqTLzV80bUMA0GCSqGSIb3DQEBBQUAA4IBAQDZrxhErYPuvQoa
7delQMluLdh3Wwu/Cp0J+YzHp9QBa5mdImQ2uE40MgQEG8XrXny1BnC97rwRszao
28vwnju61aF0W0MPCkNjRz8sm7WAYBWx26fVBPQCkK5yQJB/5+ldoRnnvoWoLzOV
wNsPnd8Upu6jAxhmldTVRhT/rje0MEGYMmfnODObsVbQwg/4uGOxINTJae0hJ9Hl
YuC2Lbf/dYIi3fjQ95I1sGtXi4a74fnvSzHqln9DcaKdER50urZ21MvNik/zCP9q
S6EHQdUvrI/jcNMUiqV20NPfKBQkFnNFOZoVki7/yeOHMMcBBphlPigJpXzC3T3B
y2Uvpnec
-----END CERTIFICATE-----
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=client.example.com
issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=rootca.example.com
Shared
ciphers:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5
CIPHER is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
On 25 July 2013 22:43, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
>
> It should be noted that OpenSSL 1.0 changed the hashing algorithm
> used to index CApath/ directories. If the OP is using CApath with
> c_rehash generated from 0.9.8, that could failure to validate the
> client certificate, though the error would typically reflect lack
> of trust, not cryptographic integrity problems.
>
I found out about this when it wouldn't read the CRL directory. The PPP
configuration requires you to specify the exact path for the CA and peer
certs though.
> Perhaps the client sends a stale copy of one the CA certificates,
> which has the right issuer name, but the wrong public key. Or
> the client's private key and certificate are not as intended...
It looks like the private key matches the cert :
$ openssl x509 -noout -modulus -in clientcert.pem | openssl md5
18e6144a8c65bf9153e24193b978a742
$ openssl rsa -noout -modulus -in client.key | openssl md5
18e6144a8c65bf9153e24193b978a742
Except of course if PPP somehow corrupts them when reading them
in memory or sending them over the wire. (Though the packet trace suggests
this is not the case)
On 26 July 2013 01:06, Dr. Stephen Henson <st...@openssl.org> wrote:
> The hints I get imply the verify algorithm is using the wrong certificate to
> verify the chain. To the OP: do those two CA certificates you mentioned have
> the exact same subject name?
I'm not following, are we talking about the CA certificates in the two scenarios
I described ? I have kind of abandoned the first scenario at the moment. I think
it makes more sense to make it work in the easier case and then move up to
the more complex one.
>
> As for the packe captures on pastebin, it is too difficult to read
> pre-decoded packet dumps. The OP should post links to the binary
> pcap files.
>
You can download an archive containing the binary pcap files as well
as the various
certs I generated here :
https://docs.google.com/file/d/0B9oNr1i-632Ianh1bFhtdW93REE/edit?usp=sharing
(sorry for the google docs link, I don't have anything more direct
right now, and I
suspect the mailing list will strip attachment to emails)
On 26 July 2013 03:32, Dave Thompson <dthomp...@prinpay.com> wrote:
> 1.0.0 enabled ECC suites by default (in 0.9.8 had to enable
> explicitly) plus a few others. 1.0.1 enabled TLSv1.1 and v1.2
> and additional suites for the latter, but ppp is apparently
> directing only TLSv1.0 even when using openssl 1.0.1.
>
I'm not sure why that happens. I looked at the PPP code handling this, but I
couldn't see anything related to that.
If anything, it prohibits SSLv2 and SSLv3:
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
>> Certificate, Client Key Exchange, Certificate Verify, Change
>> Cipher Spec, 'x'
>
> Actually that's server Certificate, >CertReq, HelloDone,<
> then client KeyExchange, CertVerify, ChangeCipher, (Finished)
> then if successful server (something), ChangeCipher, (Finished)
>
>> * 'x' is a "TLSv1 Record Layer: Handshake Protocol: Finished" for
>> libssl1.0.1
>> * 'x' is a "TLSv1 Record Layer: Handshake Protocol:
>> Encrypted Handshake
>> Message" for libssl0.9.8
>>
>> I googled around to find more information regarding the
>> encrypted handshake
>> message and I couldn't find anything relevant. In fact,
>> RFC2246 says the
>> handshake should end with 'Finished' on both ends. I have no
>> idea where that
>> 'Encrypted Handshake Message' appeared from. Could it be some outdated
>> function that is called to setup the connection that is changing this
>> from the default ?
>>
> The Finished message is a handshake message and is encrypted, since
> it occurs (just) after ChangeCipher. If Wireshark knows the data keys,
> it decrypts the message and displays it as Finished. If Wireshark
> doesn't know the data keys, it just displays Encrypted Handshake Message
> since it doesn't know which message it is without decrypting.
>
Ah, that makes sense.
> For akRSA key-exchange, as this case, Wireshark can compute the
> data keys if it can determine the server RSA privatekey.
> Obviously it did this right in the case that displays (1.0.1).
> For normal IP connections, Wireshark chooses the server RSA key
> based on the server IP address and port; I don't know how that
> works/changes for PPP, but that's where I'd start looking.
>
Thanks for the hint, I will search for more information regarding this.
>>
>> Below the URLs for the (text) captures. Let me know if you
>> need the pcaps ..
>> though I found having the text version is easier to run diff :-)
>>
>>
>> Server capture with libssl0.9.8: http://pastebin.com/ndeakdnK
>> Server capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
>> Client capture with libssl0.9.8: http://pastebin.com/z9fbA7DN
>> Client capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
>>
> The 2nd and 4th are the same URL, but even 1st and 3rd appear
> to be two ends of the same exchange, which is redundant (unless
> there is frame loss or damage, which there isn't).
>
They are, I just included both for completeness sake.
> I don't see anything in the 2nd that would explain sig-fail.
>
> Can you try openssl commandline on the same pair(s?) of systems,
> i.e. run s_server with the same CAcert and server key&cert
> that pppd is using, and s_client to that server with the same
> CAcert and client key&cert ppd client is using, for each version
> of openssl? If that fails we have an easier case to work on.
I did this and pasted the output of the commands at the beginning of
this email.
> If it works, there must be something about the embedding in EAP
> by ppp that messes up only sometimes, which would be really nasty.
>
The connection is setup, though the server still prints
verify return:1
The verification process succeeds on the client end though. So I guess you
could say that it *kind of* works. I'll check the EAP part in PPP, perhaps I
can figure this out.
Anyhow, thank you all for your suggestions and your help.
Marios
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
