Gordon Molek
06/29/2010 8:28 AM
post58028
|
We're trying to validate TTLS and we're encountering errors when we try to use a certificate that works with our legacy
code base.
EAP: EAP entering state RECEIVED
EAP: Received EAP-Request id=4 method=21 vendor=0 vendorMethod=0
EAP: EAP entering state METHOD
SSL: Received packet(len=974) - Flags 0x00
SSL: (where=0x1001 ret=0x1)
SSL: SSL_connect:SSLv3 read server hello A
TLS: Certificate verification failed, error 9 (certificate is not yet valid) depth 1 for '/DC=test/DC=ctc-zebra/CN=
03ctctestdc01'
SSL: (where=0x4008 ret=0x22a)
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:bad certificate
SSL: (where=0x1002 ret=0xffffffff)
SSL: SSL_connect:error in SSLv3 read server certificate B
OpenSSL: tls_connection_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
SSL: 7 bytes pending from ssl_out
SSL: Failed - tls_out available to report error
SSL: 7 bytes left to be sent out (of total 7 bytes)
EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL
Does anyone have TTLS working?
Thanks,
|
|
|
Gordon Molek
06/29/2010 8:55 AM
post58030
|
I believe that the certificate in question is a self-signed certificate (since this is used for internal testing). I
can't find any documentation for settings that might be required in order to allow use of a self-signed certificate,
however.
|
|
|
Patrik Lahti
06/29/2010 9:26 AM
post58037
|
I assume you're talking about EAP-TTLS in the context of wpa_supplicant?
What version of QNX are you using?
> TLS: Certificate verification failed, error 9 (certificate is not yet valid) depth 1 for '/DC=test/DC=ctc-zebra/CN=
This indicates to me that the certificate is deemed to yet not valid.
Maybe the time on your target is not set correctly? Or the certificate
was created with validity time in the future?
> Does anyone have TTLS working?
Yes, I think I've used EAP-TTLS although not recently though... and
probably not with a self-signed certificate. Please check the documentation.
Cheers!
/P
|
|
|
Gordon Molek
06/29/2010 1:04 PM
post58100
|
Thanks for the quick response.
> I assume you're talking about EAP-TTLS in the context of wpa_supplicant?
Yes, I should have been more specific.
> What version of QNX are you using?
6.4.1 On a related note, OpenSSL 0.9.8g doesn't appear to support EAP-FAST (there seems to be a patch for 0.9.8i) are
there plans to pick up support for EAP-FAST?
> > TLS: Certificate verification failed, error 9 (certificate is not yet valid)
> depth 1 for '/DC=test/DC=ctc-zebra/CN=
>
> This indicates to me that the certificate is deemed to yet not valid.
> Maybe the time on your target is not set correctly? Or the certificate
> was created with validity time in the future?
Ah! I hadn't even thought of that! Yes, my target was using the default date of 1970. Setting the date and then
running wpa_supplicant gets me past that failure. We don't complete authentication yet, but I need to do more digging.
> > Does anyone have TTLS working?
>
> Yes, I think I've used EAP-TTLS although not recently though... and
> probably not with a self-signed certificate. Please check the documentation.
By "documentation" are you referring to the QNX, wpa_supplicant or OpenSSL documentation?
Again, thanks for the quick response.
|
|
|
Patrik Lahti
07/02/2010 12:51 PM
post58341
|
Hi Gordon,
Good news, we've actually got openssl 1.0.0 in trunk. And EAP-FAST is in
wpa_supplicant trunk too now, but untested so far due other priorities.
It would be great if you can try it out!
Please let me know if you have success or any problems with EAP-FAST.
Cheers & Good luck!
/P
On 10-06-29 01:04 PM, Gordon Molek wrote:
> Thanks for the quick response.
>
>> I assume you're talking about EAP-TTLS in the context of wpa_supplicant?
>
> Yes, I should have been more specific.
>
>> What version of QNX are you using?
>
> 6.4.1 On a related note, OpenSSL 0.9.8g doesn't appear to support EAP-FAST (there seems to be a patch for 0.9.8i) are
there plans to pick up support for EAP-FAST?
>
>>> TLS: Certificate verification failed, error 9 (certificate is not yet valid)
>> depth 1 for '/DC=test/DC=ctc-zebra/CN=
>>
>> This indicates to me that the certificate is deemed to yet not valid.
>> Maybe the time on your target is not set correctly? Or the certificate
>> was created with validity time in the future?
>
> Ah! I hadn't even thought of that! Yes, my target was using the default date of 1970. Setting the date and then
running wpa_supplicant gets me past that failure. We don't complete authentication yet, but I need to do more digging.
>
>>> Does anyone have TTLS working?
>>
>> Yes, I think I've used EAP-TTLS although not recently though... and
>> probably not with a self-signed certificate. Please check the documentation.
>
> By "documentation" are you referring to the QNX, wpa_supplicant or OpenSSL documentation?
>
> Again, thanks for the quick response.
>
>
>
> _______________________________________________
>
> Technology
> http://community.qnx.com/sf/go/post58100
>
|
|
|
Gordon Molek
07/29/2010 3:03 PM
post61097
|
The updated supplicant is not part of 6.5? We just tried building wpa_supplicant with 6.5 (and EAP-FAST enabled) and we
get similar linkage failures.
-----Original Message-----
From: Patrik Lahti [mailto:community-noreply@qnx.com]
Sent: Friday, July 02, 2010 11:52 AM
To: technology-networking
Subject: Re: TTLS failure
Hi Gordon,
Good news, we've actually got openssl 1.0.0 in trunk. And EAP-FAST is in
wpa_supplicant trunk too now, but untested so far due other priorities.
It would be great if you can try it out!
Please let me know if you have success or any problems with EAP-FAST.
Cheers & Good luck!
/P
On 10-06-29 01:04 PM, Gordon Molek wrote:
> Thanks for the quick response.
>
>> I assume you're talking about EAP-TTLS in the context of wpa_supplicant?
>
> Yes, I should have been more specific.
>
>> What version of QNX are you using?
>
> 6.4.1 On a related note, OpenSSL 0.9.8g doesn't appear to support EAP-FAST (there seems to be a patch for 0.9.8i) are
there plans to pick up support for EAP-FAST?
>
>>> TLS: Certificate verification failed, error 9 (certificate is not yet valid)
>> depth 1 for '/DC=test/DC=ctc-zebra/CN=
>>
>> This indicates to me that the certificate is deemed to yet not valid.
>> Maybe the time on your target is not set correctly? Or the certificate
>> was created with validity time in the future?
>
> Ah! I hadn't even thought of that! Yes, my target was using the default date of 1970. Setting the date and then
running wpa_supplicant gets me past that failure. We don't complete authentication yet, but I need to do more digging.
>
>>> Does anyone have TTLS working?
>>
>> Yes, I think I've used EAP-TTLS although not recently though... and
>> probably not with a self-signed certificate. Please check the documentation.
>
> By "documentation" are you referring to the QNX, wpa_supplicant or OpenSSL documentation?
>
> Again, thanks for the quick response.
>
>
>
> _______________________________________________
>
> Technology
> http://community.qnx.com/sf/go/post58100
>
_______________________________________________
Technology
http://community.qnx.com/sf/go/post58341
- CONFIDENTIAL-
This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the
intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error,
please notify the sender immediately by reply email and then delete this email.
|
|
|
Sean Boudreau(deleted)
07/29/2010 3:39 PM
post61102
|
On Thu, Jul 29, 2010 at 03:03:10PM -0400, Gordon Molek wrote:
> The updated supplicant is not part of 6.5? We just tried building wpa_supplicant with 6.5 (and EAP-FAST enabled) and
we get similar linkage failures.
No, not 6.5. The updated openssl and supplicant are
on the foundry.
Regards,
-seanb
|
|
|
Patrik Lahti
07/29/2010 4:02 PM
post61108
|
No it's not part of 6.5. It's on trunk only. So you need to get the
latests source code from SVN.
/P
On 10-07-29 03:03 PM, Gordon Molek wrote:
> The updated supplicant is not part of 6.5? We just tried building wpa_supplicant with 6.5 (and EAP-FAST enabled) and
we get similar linkage failures.
>
> -----Original Message-----
> From: Patrik Lahti [mailto:community-noreply@qnx.com]
> Sent: Friday, July 02, 2010 11:52 AM
> To: technology-networking
> Subject: Re: TTLS failure
>
> Hi Gordon,
>
> Good news, we've actually got openssl 1.0.0 in trunk. And EAP-FAST is in
> wpa_supplicant trunk too now, but untested so far due other priorities.
> It would be great if you can try it out!
>
> Please let me know if you have success or any problems with EAP-FAST.
>
> Cheers& Good luck!
> /P
>
> On 10-06-29 01:04 PM, Gordon Molek wrote:
>> Thanks for the quick response.
>>
>>> I assume you're talking about EAP-TTLS in the context of wpa_supplicant?
>>
>> Yes, I should have been more specific.
>>
>>> What version of QNX are you using?
>>
>> 6.4.1 On a related note, OpenSSL 0.9.8g doesn't appear to support EAP-FAST (there seems to be a patch for 0.9.8i)
are there plans to pick up support for EAP-FAST?
>>
>>>> TLS: Certificate verification failed, error 9 (certificate is not yet valid)
>>> depth 1 for '/DC=test/DC=ctc-zebra/CN=
>>>
>>> This indicates to me that the certificate is deemed to yet not valid.
>>> Maybe the time on your target is not set correctly? Or the certificate
>>> was created with validity time in the future?
>>
>> Ah! I hadn't even thought of that! Yes, my target was using the default date of 1970. Setting the date and then
running wpa_supplicant gets me past that failure. We don't complete authentication yet, but I need to do more digging.
>>
>>>> Does anyone have TTLS working?
>>>
>>> Yes, I think I've used EAP-TTLS although not recently though... and
>>> probably not with a self-signed certificate. Please check the documentation.
>>
>> By "documentation" are you referring to the QNX, wpa_supplicant or OpenSSL documentation?
>>
>> Again, thanks for the quick response.
>>
>>
>>
>> _______________________________________________
>>
>> Technology
>> http://community.qnx.com/sf/go/post58100
>>
>
>
>
> _______________________________________________
>
> Technology
> http://community.qnx.com/sf/go/post58341
>
>
>
> - CONFIDENTIAL-
>
> This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the
intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error,
please notify the sender immediately by reply email and then delete this email.
>
>
>
> _______________________________________________
>
> Technology
> http://community.qnx.com/sf/go/post61097
>
|
|
|
Gordon Molek
08/04/2010 9:18 AM
post61541
|
I have tried following the instructions on the foundry for building the networking source to no avail, using the DOS
command window method and through the Momentics IDE.
Can the networking source be complied without first compiling the os source?
Does hide-gnu.mk need to be run for the networking source, or just for the os source? If so, does it take a DOS-style
path (e.g., E:/core_networking)?
Should the INSTALL_ROOT_nto line of qconf-override.mk use a DOS-style path (e.g., E:/core_networking/stage)?
Does the QCONF_OVERRIDE environment variable need a DOS-style path (e.g., "set QCONF_OVERRIDE=E:/core_networking/qconf-
override.mk")?
When attempting to build the OS, when I run "make OSLIST=nto hinstall" I get errors of the form:
/usr/bin/cp: cannot stat 'e:/QNX641/host/win32/x86/usr/cygdrive/e/qnx/trunk/lib/c/public/x86/string.h': No such file or
directory
Do I need to run "make OSLIST=nto hinstall" to build the networking source, or go straight to "make CPULIST=arm install"
?
-----Original Message-----
From: Patrik Lahti [mailto:community-noreply@qnx.com]
Sent: Thursday, July 29, 2010 3:03 PM
To: technology-networking
Subject: Re: TTLS failure
No it's not part of 6.5. It's on trunk only. So you need to get the
latests source code from SVN.
/P
On 10-07-29 03:03 PM, Gordon Molek wrote:
> The updated supplicant is not part of 6.5? We just tried building wpa_supplicant with 6.5 (and EAP-FAST enabled) and
we get similar linkage failures.
>
> -----Original Message-----
> From: Patrik Lahti [mailto:community-noreply@qnx.com]
> Sent: Friday, July 02, 2010 11:52 AM
> To: technology-networking
> Subject: Re: TTLS failure
>
> Hi Gordon,
>
> Good news, we've actually got openssl 1.0.0 in trunk. And EAP-FAST is in
> wpa_supplicant trunk too now, but untested so far due other priorities.
> It would be great if you can try it out!
>
> Please let me know if you have success or any problems with EAP-FAST.
>
> Cheers& Good luck!
> /P
>
> On 10-06-29 01:04 PM, Gordon Molek wrote:
>> Thanks for the quick response.
>>
>>> I assume you're talking about EAP-TTLS in the context of wpa_supplicant?
>>
>> Yes, I should have been more specific.
>>
>>> What version of QNX are you using?
>>
>> 6.4.1 On a related note, OpenSSL 0.9.8g doesn't appear to support EAP-FAST (there seems to be a patch for 0.9.8i)
are there plans to pick up support for EAP-FAST?
>>
>>>> TLS: Certificate verification failed, error 9 (certificate is not yet valid)
>>> depth 1 for '/DC=test/DC=ctc-zebra/CN=
>>>
>>> This indicates to me that the certificate is deemed to yet not valid.
>>> Maybe the time on your target is not set correctly? Or the certificate
>>> was created with validity time in the future?
>>
>> Ah! I hadn't even thought of that! Yes, my target was using the default date of 1970. Setting the date and then
running wpa_supplicant gets me past that failure. We don't complete authentication yet, but I need to do more digging.
>>
>>>> Does anyone have TTLS working?
>>>
>>> Yes, I think I've used EAP-TTLS although not recently though... and
>>> probably not with a self-signed certificate. Please check the documentation.
>>
>> By "documentation" are you referring to the QNX, wpa_supplicant or OpenSSL documentation?
>>
>> Again, thanks for the quick response.
>>
>>
>>
>> _______________________________________________
>>
>> Technology
>> http://community.qnx.com/sf/go/post58100
>>
>
>
>
> _______________________________________________
>
> Technology
> http://community.qnx.com/sf/go/post58341
>
>
>
> -...
View Full Message
|
|
|
|