openssl 0.8.9h sha256 - Openssl

This is a discussion on openssl 0.8.9h sha256 - Openssl ; I see an error like below when trying to use EAP_TLS/TTLS authentication with Certs that has Signature Algorithm: sha256WithRSAEncryption . Can anybody tell me why SSL does not like the TLS session ? I would appreciate your help. here is ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: openssl 0.8.9h sha256

  1. openssl 0.8.9h sha256

    I see an error like below when trying to use EAP_TLS/TTLS
    authentication with Certs that has Signature Algorithm:
    sha256WithRSAEncryption . Can anybody tell me why SSL does not like
    the TLS session ?

    I would appreciate your help. here is the radiusd -X log:

    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 142 length 13
    rlm_eap: Continuing tunnel setup.
    ++[eap] returns ok
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP/ttls
    rlm_eap: processing type ttls
    rlm_eap_ttls: Authenticate
    rlm_eap_tls: processing TLS
    eaptls_verify returned 7
    rlm_eap_tls: Done initial handshake
    rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal decrypt_error
    TLS Alert read:fatal:decrypt error
    TLS_accept:failed in SSLv3 read client certificate A
    rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decry
    pt error
    rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails.
    eaptls_process returned 13
    rlm_eap: Freeing handler
    ++[eap] returns reject
    auth: Failed to validate the user.
    Found Post-Auth-Type Reject
    +- entering group REJECT
    expand: %{User-Name} -> anonymous_identity
    attr_filter: Matched entry DEFAULT at line 11
    ++[attr_filter.access_reject] returns updated
    Sending Access-Reject of id 142 to 10.19.198.231 port 19801

    --
    Rafiqul Ahsan
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Re: openssl 0.8.9h sha256

    Rafiqul Ahsan escribió:
    > I see an error like below when trying to use EAP_TLS/TTLS
    > authentication with Certs that has Signature Algorithm:
    > sha256WithRSAEncryption . Can anybody tell me why SSL does not like
    > the TLS session ?
    >
    > I would appreciate your help. here is the radiusd -X log:
    >
    > ++[suffix] returns noop
    > rlm_eap: EAP packet type response id 142 length 13
    > rlm_eap: Continuing tunnel setup.
    > ++[eap] returns ok
    > rad_check_password: Found Auth-Type EAP
    > auth: type "EAP"
    > +- entering group authenticate
    > rlm_eap: Request found, released from the list
    > rlm_eap: EAP/ttls
    > rlm_eap: processing type ttls
    > rlm_eap_ttls: Authenticate
    > rlm_eap_tls: processing TLS
    > eaptls_verify returned 7
    > rlm_eap_tls: Done initial handshake
    > rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal decrypt_error
    > TLS Alert read:fatal:decrypt error
    > TLS_accept:failed in SSLv3 read client certificate A
    > rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decry
    > pt error
    > rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails.
    > eaptls_process returned 13
    > rlm_eap: Freeing handler
    > ++[eap] returns reject
    > auth: Failed to validate the user.
    > Found Post-Auth-Type Reject
    > +- entering group REJECT
    > expand: %{User-Name} -> anonymous_identity
    > attr_filter: Matched entry DEFAULT at line 11
    > ++[attr_filter.access_reject] returns updated
    > Sending Access-Reject of id 142 to 10.19.198.231 port 19801
    >
    >

    Hi,
    recently i tried to use certs with SHA-2 sign and got the same error.
    Probaly freeradius doesn't support (also) this size of sign. You can ask
    about this into freeradius mailing list. Try to put a cert with SHA-1
    algorithm and you will see it working.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: openssl 0.8.9h sha256

    Found a previous postings like this where Alan Dekok answered that
    FreeRadius use SSL from openssl, and if SSL supports any advanced
    algorithm FreeRadius should support it (I actually added a patch to
    FreeRadius to make sure this supports all digests). I am currently
    trying to find out whether I have linked the right openssl libraries
    when building the FreeRadius. I am unable to find out whether
    FreeRadius is being built with Solaris prebuilt openssl version 0.9.7d
    at /usr/sfw, or my newly installed openssl version 0.9.8h at
    /usr/local (with library /usr/local/ssl/lib). I have however few
    questions , and I would appreciate your reply:

    1. How to create CAcert.pem (root certs), server.pem (device certs),
    and server_pvt_key.pem (private key file) for server, and same for
    client to test TTLS, and TLS. It could be self signed.
    2. Also how to create certs using different algorithm (sha1, sha2,
    sha256 etc.) ?

    I need to create certs to test EAP-TLS/TTLS using WiMAX AP.

    Thanks, and appreciate your help.

    On 8/12/08, Sergio wrote:
    > Rafiqul Ahsan escribió:
    >
    > > I see an error like below when trying to use EAP_TLS/TTLS
    > > authentication with Certs that has Signature Algorithm:
    > > sha256WithRSAEncryption . Can anybody tell me why SSL does not like
    > > the TLS session ?
    > >
    > > I would appreciate your help. here is the radiusd -X log:
    > >
    > > ++[suffix] returns noop
    > > rlm_eap: EAP packet type response id 142 length 13
    > > rlm_eap: Continuing tunnel setup.
    > > ++[eap] returns ok
    > > rad_check_password: Found Auth-Type EAP
    > > auth: type "EAP"
    > > +- entering group authenticate
    > > rlm_eap: Request found, released from the list
    > > rlm_eap: EAP/ttls
    > > rlm_eap: processing type ttls
    > > rlm_eap_ttls: Authenticate
    > > rlm_eap_tls: processing TLS
    > > eaptls_verify returned 7
    > > rlm_eap_tls: Done initial handshake
    > > rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal decrypt_error
    > > TLS Alert read:fatal:decrypt error
    > > TLS_accept:failed in SSLv3 read client certificate A
    > > rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert

    > decry
    > > pt error
    > > rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails.
    > > eaptls_process returned 13
    > > rlm_eap: Freeing handler
    > > ++[eap] returns reject
    > > auth: Failed to validate the user.
    > > Found Post-Auth-Type Reject
    > > +- entering group REJECT
    > > expand: %{User-Name} -> anonymous_identity
    > > attr_filter: Matched entry DEFAULT at line 11
    > > ++[attr_filter.access_reject] returns updated
    > > Sending Access-Reject of id 142 to 10.19.198.231 port 19801
    > >
    > >
    > >

    > Hi,
    > recently i tried to use certs with SHA-2 sign and got the same error.
    > Probaly freeradius doesn't support (also) this size of sign. You can ask
    > about this into freeradius mailing list. Try to put a cert with SHA-1
    > algorithm and you will see it working.
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



    --
    Rafiqul Ahsan
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: openssl 0.8.9h sha256

    Rafiqul Ahsan escribió:
    > Found a previous postings like this where Alan Dekok answered that
    > FreeRadius use SSL from openssl, and if SSL supports any advanced
    > algorithm FreeRadius should support it (I actually added a patch to
    > FreeRadius to make sure this supports all digests). I am currently
    > trying to find out whether I have linked the right openssl libraries
    > when building the FreeRadius. I am unable to find out whether
    > FreeRadius is being built with Solaris prebuilt openssl version 0.9.7d
    > at /usr/sfw, or my newly installed openssl version 0.9.8h at
    > /usr/local (with library /usr/local/ssl/lib). I have however few
    > questions , and I would appreciate your reply:
    >
    > 1. How to create CAcert.pem (root certs), server.pem (device certs),
    > and server_pvt_key.pem (private key file) for server, and same for
    > client to test TTLS, and TLS. It could be self signed.
    > 2. Also how to create certs using different algorithm (sha1, sha2,
    > sha256 etc.) ?
    >
    > I need to create certs to test EAP-TLS/TTLS using WiMAX AP.
    >
    > Thanks, and appreciate your help.
    >
    > On 8/12/08, Sergio wrote:
    >
    >> Rafiqul Ahsan escribió:
    >>
    >>
    >>> I see an error like below when trying to use EAP_TLS/TTLS
    >>> authentication with Certs that has Signature Algorithm:
    >>> sha256WithRSAEncryption . Can anybody tell me why SSL does not like
    >>> the TLS session ?
    >>>
    >>> I would appreciate your help. here is the radiusd -X log:
    >>>
    >>> ++[suffix] returns noop
    >>> rlm_eap: EAP packet type response id 142 length 13
    >>> rlm_eap: Continuing tunnel setup.
    >>> ++[eap] returns ok
    >>> rad_check_password: Found Auth-Type EAP
    >>> auth: type "EAP"
    >>> +- entering group authenticate
    >>> rlm_eap: Request found, released from the list
    >>> rlm_eap: EAP/ttls
    >>> rlm_eap: processing type ttls
    >>> rlm_eap_ttls: Authenticate
    >>> rlm_eap_tls: processing TLS
    >>> eaptls_verify returned 7
    >>> rlm_eap_tls: Done initial handshake
    >>> rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal decrypt_error
    >>> TLS Alert read:fatal:decrypt error
    >>> TLS_accept:failed in SSLv3 read client certificate A
    >>> rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert
    >>>

    >> decry
    >>
    >>> pt error
    >>> rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails.
    >>> eaptls_process returned 13
    >>> rlm_eap: Freeing handler
    >>> ++[eap] returns reject
    >>> auth: Failed to validate the user.
    >>> Found Post-Auth-Type Reject
    >>> +- entering group REJECT
    >>> expand: %{User-Name} -> anonymous_identity
    >>> attr_filter: Matched entry DEFAULT at line 11
    >>> ++[attr_filter.access_reject] returns updated
    >>> Sending Access-Reject of id 142 to 10.19.198.231 port 19801
    >>>
    >>>
    >>>
    >>>

    >> Hi,
    >> recently i tried to use certs with SHA-2 sign and got the same error.
    >> Probaly freeradius doesn't support (also) this size of sign. You can ask
    >> about this into freeradius mailing list. Try to put a cert with SHA-1
    >> algorithm and you will see it working.
    >> __________________________________________________ ____________________
    >> OpenSSL Project http://www.openssl.org
    >> User Support Mailing List openssl-users@openssl.org
    >> Automated List Manager majordomo@openssl.org
    >>
    >>

    >
    >

    I'm not an expert but, not all SSL functions are used by freeradius, por
    example ocsp functions. You can see raddb/certs/Makefile and
    raddb/certs/README to follow the commands which creates test
    certificates. Surely with another openssl options you can use several
    algorithms but, there is one important point with test certs that
    freeradius generates. Client certificates are signed by server private
    key, so you should put the correct permissions into your openssl
    configuration for server certs creation or sign client cert with ca
    private key. I taken the second decision because it's more clear for me,
    and because the functionality is EXACTLY the same. For the other side, i
    don't know anything about WiMAX, but i suposse that credentials are the
    same. Hope this helps
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  5. Re: openssl 0.8.9h sha256

    Thanks, I will try to figure out as you suggested.

    Rafi

    On 8/13/08, Sergio wrote:
    > Rafiqul Ahsan escribió:
    >
    > > Found a previous postings like this where Alan Dekok answered that
    > > FreeRadius use SSL from openssl, and if SSL supports any advanced
    > > algorithm FreeRadius should support it (I actually added a patch to
    > > FreeRadius to make sure this supports all digests). I am currently
    > > trying to find out whether I have linked the right openssl libraries
    > > when building the FreeRadius. I am unable to find out whether
    > > FreeRadius is being built with Solaris prebuilt openssl version 0.9.7d
    > > at /usr/sfw, or my newly installed openssl version 0.9.8h at
    > > /usr/local (with library /usr/local/ssl/lib). I have however few
    > > questions , and I would appreciate your reply:
    > >
    > > 1. How to create CAcert.pem (root certs), server.pem (device certs),
    > > and server_pvt_key.pem (private key file) for server, and same for
    > > client to test TTLS, and TLS. It could be self signed.
    > > 2. Also how to create certs using different algorithm (sha1, sha2,
    > > sha256 etc.) ?
    > >
    > > I need to create certs to test EAP-TLS/TTLS using WiMAX AP.
    > >
    > > Thanks, and appreciate your help.
    > >
    > > On 8/12/08, Sergio wrote:
    > >
    > >
    > > > Rafiqul Ahsan escribió:
    > > >
    > > >
    > > >
    > > > > I see an error like below when trying to use EAP_TLS/TTLS
    > > > > authentication with Certs that has Signature Algorithm:
    > > > > sha256WithRSAEncryption . Can anybody tell me why SSL does not like
    > > > > the TLS session ?
    > > > >
    > > > > I would appreciate your help. here is the radiusd -X log:
    > > > >
    > > > > ++[suffix] returns noop
    > > > > rlm_eap: EAP packet type response id 142 length 13
    > > > > rlm_eap: Continuing tunnel setup.
    > > > > ++[eap] returns ok
    > > > > rad_check_password: Found Auth-Type EAP
    > > > > auth: type "EAP"
    > > > > +- entering group authenticate
    > > > > rlm_eap: Request found, released from the list
    > > > > rlm_eap: EAP/ttls
    > > > > rlm_eap: processing type ttls
    > > > > rlm_eap_ttls: Authenticate
    > > > > rlm_eap_tls: processing TLS
    > > > > eaptls_verify returned 7
    > > > > rlm_eap_tls: Done initial handshake
    > > > > rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal decrypt_error
    > > > > TLS Alert read:fatal:decrypt error
    > > > > TLS_accept:failed in SSLv3 read client certificate A
    > > > > rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1

    > alert
    > > > >
    > > > >
    > > > decry
    > > >
    > > >
    > > > > pt error
    > > > > rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails.
    > > > > eaptls_process returned 13
    > > > > rlm_eap: Freeing handler
    > > > > ++[eap] returns reject
    > > > > auth: Failed to validate the user.
    > > > > Found Post-Auth-Type Reject
    > > > > +- entering group REJECT
    > > > > expand: %{User-Name} -> anonymous_identity
    > > > > attr_filter: Matched entry DEFAULT at line 11
    > > > > ++[attr_filter.access_reject] returns updated
    > > > > Sending Access-Reject of id 142 to 10.19.198.231 port 19801
    > > > >
    > > > >
    > > > >
    > > > >
    > > > >
    > > > Hi,
    > > > recently i tried to use certs with SHA-2 sign and got the same error.
    > > > Probaly freeradius doesn't support (also) this size of sign. You can ask
    > > > about this into freeradius mailing list. Try to put a cert with SHA-1
    > > > algorithm and you will see it working.
    > > >

    > __________________________________________________ ____________________
    > > > OpenSSL Project http://www.openssl.org
    > > > User Support Mailing List openssl-users@openssl.org
    > > > Automated List Manager majordomo@openssl.org
    > > >
    > > >
    > > >

    > >
    > >
    > >

    > I'm not an expert but, not all SSL functions are used by freeradius, por
    > example ocsp functions. You can see raddb/certs/Makefile and
    > raddb/certs/README to follow the commands which creates test certificates..
    > Surely with another openssl options you can use several algorithms but,
    > there is one important point with test certs that freeradius generates.
    > Client certificates are signed by server private key, so you should put the
    > correct permissions into your openssl configuration for server certs
    > creation or sign client cert with ca private key. I taken the second
    > decision because it's more clear for me, and because the functionality is
    > EXACTLY the same. For the other side, i don't know anything about WiMAX, but
    > i suposse that credentials are the same. Hope this helps
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



    --
    Rafiqul Ahsan
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  6. RE: openssl 0.8.9h sha256

    Dear All,
    I tried to connect to stream server through using https (using open
    ssl).But I got response from server nothing means only zero content length
    of data and headers.
    Let me know why server was not sending data. Is any problem related to ssl
    due to delay time out happen towards server side or it is due any other
    reason.
    Please reply me.

    Thank you.

    Regards,

    --Ajeet Kumar Singh

    Sarve Bhavantu Sukhina ,Sarve Santu NiramayaSarve Bhadrani Pashyantu , Maa
    Kaschit Dukha Bhagh Bhavet



    -----Original Message-----
    From: owner-openssl-users@openssl.org
    [mailtowner-openssl-users@openssl.org] On Behalf Of Rafiqul Ahsan
    Sent: Wednesday, August 13, 2008 7:19 PM
    To: openssl-users@openssl.org
    Subject: Re: openssl 0.8.9h sha256

    Thanks, I will try to figure out as you suggested.

    Rafi

    On 8/13/08, Sergio wrote:
    > Rafiqul Ahsan escribió:
    >
    > > Found a previous postings like this where Alan Dekok answered that
    > > FreeRadius use SSL from openssl, and if SSL supports any advanced
    > > algorithm FreeRadius should support it (I actually added a patch to
    > > FreeRadius to make sure this supports all digests). I am currently
    > > trying to find out whether I have linked the right openssl libraries
    > > when building the FreeRadius. I am unable to find out whether
    > > FreeRadius is being built with Solaris prebuilt openssl version 0.9.7d
    > > at /usr/sfw, or my newly installed openssl version 0.9.8h at
    > > /usr/local (with library /usr/local/ssl/lib). I have however few
    > > questions , and I would appreciate your reply:
    > >
    > > 1. How to create CAcert.pem (root certs), server.pem (device certs),
    > > and server_pvt_key.pem (private key file) for server, and same for
    > > client to test TTLS, and TLS. It could be self signed.
    > > 2. Also how to create certs using different algorithm (sha1, sha2,
    > > sha256 etc.) ?
    > >
    > > I need to create certs to test EAP-TLS/TTLS using WiMAX AP.
    > >
    > > Thanks, and appreciate your help.
    > >
    > > On 8/12/08, Sergio wrote:
    > >
    > >
    > > > Rafiqul Ahsan escribió:
    > > >
    > > >
    > > >
    > > > > I see an error like below when trying to use EAP_TLS/TTLS
    > > > > authentication with Certs that has Signature Algorithm:
    > > > > sha256WithRSAEncryption . Can anybody tell me why SSL does not like
    > > > > the TLS session ?
    > > > >
    > > > > I would appreciate your help. here is the radiusd -X log:
    > > > >
    > > > > ++[suffix] returns noop
    > > > > rlm_eap: EAP packet type response id 142 length 13
    > > > > rlm_eap: Continuing tunnel setup.
    > > > > ++[eap] returns ok
    > > > > rad_check_password: Found Auth-Type EAP
    > > > > auth: type "EAP"
    > > > > +- entering group authenticate
    > > > > rlm_eap: Request found, released from the list
    > > > > rlm_eap: EAP/ttls
    > > > > rlm_eap: processing type ttls
    > > > > rlm_eap_ttls: Authenticate
    > > > > rlm_eap_tls: processing TLS
    > > > > eaptls_verify returned 7
    > > > > rlm_eap_tls: Done initial handshake
    > > > > rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal decrypt_error
    > > > > TLS Alert read:fatal:decrypt error
    > > > > TLS_accept:failed in SSLv3 read client certificate A
    > > > > rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1

    > alert
    > > > >
    > > > >
    > > > decry
    > > >
    > > >
    > > > > pt error
    > > > > rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails.
    > > > > eaptls_process returned 13
    > > > > rlm_eap: Freeing handler
    > > > > ++[eap] returns reject
    > > > > auth: Failed to validate the user.
    > > > > Found Post-Auth-Type Reject
    > > > > +- entering group REJECT
    > > > > expand: %{User-Name} -> anonymous_identity
    > > > > attr_filter: Matched entry DEFAULT at line 11
    > > > > ++[attr_filter.access_reject] returns updated
    > > > > Sending Access-Reject of id 142 to 10.19.198.231 port 19801
    > > > >
    > > > >
    > > > >
    > > > >
    > > > >
    > > > Hi,
    > > > recently i tried to use certs with SHA-2 sign and got the same error.
    > > > Probaly freeradius doesn't support (also) this size of sign. You can

    ask
    > > > about this into freeradius mailing list. Try to put a cert with SHA-1
    > > > algorithm and you will see it working.
    > > >

    > __________________________________________________ ____________________
    > > > OpenSSL Project http://www.openssl.org
    > > > User Support Mailing List openssl-users@openssl.org
    > > > Automated List Manager majordomo@openssl.org
    > > >
    > > >
    > > >

    > >
    > >
    > >

    > I'm not an expert but, not all SSL functions are used by freeradius, por
    > example ocsp functions. You can see raddb/certs/Makefile and
    > raddb/certs/README to follow the commands which creates test certificates.
    > Surely with another openssl options you can use several algorithms but,
    > there is one important point with test certs that freeradius generates.
    > Client certificates are signed by server private key, so you should put

    the
    > correct permissions into your openssl configuration for server certs
    > creation or sign client cert with ca private key. I taken the second
    > decision because it's more clear for me, and because the functionality is
    > EXACTLY the same. For the other side, i don't know anything about WiMAX,

    but
    > i suposse that credentials are the same. Hope this helps
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



    --
    Rafiqul Ahsan
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  7. Re: openssl 0.8.9h sha256

    Hi Sergio,

    I tried with SHA1, and it is working just fine (Signature Algorithm:
    sha1WithRSAEncryption).

    Now, sha256 is not really working...is really openssl 0.9.8h supports
    this advanced algorithm ? I have given the output as below...but
    freeradius suggests that with the patch it should work with sha256.
    The patch is all about calling a function OpenSSL_add_all_digests(),
    and I have compiled freeradius with this patch, also successfully
    linked with openssl 0.9.8h libraries. Any help ?

    Listening on accounting address * port 1813
    Listening on proxy address * port 1814
    Ready to process requests.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=183, leng
    th=139
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02b7001701616e6f6e796d6f75735f6964656e74697479
    Message-Authenticator = 0x2a16f3b6cdb4e18b4842080fe5b4f6c4
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 183 length 23
    rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
    ++[eap] returns updated
    ++[unix] returns notfound
    users: Matched entry anonymous_identity at line 778
    ++[files] returns ok
    ++[expiration] returns noop
    ++[logintime] returns noop
    rlm_pap: WARNING! No "known good" password found for the user. Authentication m
    ay fail because of this.
    ++[pap] returns noop
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: EAP Identity
    rlm_eap: processing type tls
    rlm_eap_tls: Requiring client certificate
    rlm_eap_tls: Initiate
    rlm_eap_tls: Start returned 1
    ++[eap] returns handled
    Sending Access-Challenge of id 183 to 10.19.198.231 port 19801
    3GPP2-MN-HA-SPI = 1000
    3GPP2-MN-HA-Shared-Key = "testtesttesttest"
    Motorola-WiMAX-User-NAI = "fbt3@wimax.mot.com"
    Motorola-WiMAX-EMS-Address = 10.10.10.10
    Motorola-WiMAX-Network-Domain-Name = "bt25.wimax.mot.com"
    Motorola-WiMAX-Provisioning-Server = "testuser"
    Motorola-WiMAX-Location-Server = "testuser"
    Motorola-WiMAX-NTP-Server = 0x010a13adf5
    Motorola-WiMAX-HO-SVC-CLASS = 0x05
    Motorola-WiMAX-Maximum-Total-Bandwidth = 0x000186a0000186a0
    Motorola-WiMAX-Maximum-Commit-Bandwidth = 0x0000c3500000c350
    Motorola-WiMAX-Convergence-Sublayer = 0x00
    Session-Timeout = 43200
    Motorola-WiMAX-Service-Flows = "2|Default"
    EAP-Message = 0x01b800060d20
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0x31599a9731e197e9acca5c2f1dc89330
    Finished request 0.
    Going to the next request
    Waking up in 4.9 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=184, leng
    th=140
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0x31599a9731e197e9acca5c2f1dc89330
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02b800060315
    Message-Authenticator = 0xf9f7eb83e8d0ed98e5ee4ca078e274d9
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 184 length 6
    rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
    ++[eap] returns updated
    ++[unix] returns notfound
    users: Matched entry anonymous_identity at line 778
    ++[files] returns ok
    ++[expiration] returns noop
    ++[logintime] returns noop
    rlm_pap: WARNING! No "known good" password found for the user. Authentication m
    ay fail because of this.
    ++[pap] returns noop
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP NAK
    rlm_eap: EAP-NAK asked for EAP-Type/ttls
    rlm_eap: processing type tls
    rlm_eap_tls: Initiate
    rlm_eap_tls: Start returned 1
    ++[eap] returns handled
    Sending Access-Challenge of id 184 to 10.19.198.231 port 19801
    3GPP2-MN-HA-SPI = 1000
    3GPP2-MN-HA-Shared-Key = "testtesttesttest"
    Motorola-WiMAX-User-NAI = "fbt3@wimax.mot.com"
    Motorola-WiMAX-EMS-Address = 10.10.10.10
    Motorola-WiMAX-Network-Domain-Name = "bt25.wimax.mot.com"
    Motorola-WiMAX-Provisioning-Server = "testuser"
    Motorola-WiMAX-Location-Server = "testuser"
    Motorola-WiMAX-NTP-Server = 0x010a13adf5
    Motorola-WiMAX-HO-SVC-CLASS = 0x05
    Motorola-WiMAX-Maximum-Total-Bandwidth = 0x000186a0000186a0
    Motorola-WiMAX-Maximum-Commit-Bandwidth = 0x0000c3500000c350
    Motorola-WiMAX-Convergence-Sublayer = 0x00
    Session-Timeout = 43200
    Motorola-WiMAX-Service-Flows = "2|Default"
    EAP-Message = 0x01b900061520
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0x31599a9730e08fe9acca5c2f1dc89330
    Finished request 1.
    Going to the next request
    Waking up in 4.9 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=185, leng
    th=242
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0x31599a9730e08fe9acca5c2f1dc89330
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02b9006c150016030100610100005d030148a4a9034e1468 c06e8d1b
    781b0d0cdc5a8c221860f1defe3e5d81e7ecd03ea500003600 390038003500160013000a00330032
    002f0007006600050004006300620061001500120009006500 640060001400110008000600030100
    Message-Authenticator = 0xc0d0d03abcccd72d678b8781ede23ecb
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 185 length 108
    rlm_eap: Continuing tunnel setup.
    ++[eap] returns ok
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP/ttls
    rlm_eap: processing type ttls
    rlm_eap_ttls: Authenticate
    rlm_eap_tls: processing TLS
    eaptls_verify returned 7
    rlm_eap_tls: Done initial handshake
    (other): before/accept initialization
    TLS_accept: before/accept initialization
    rlm_eap_tls: <<< TLS 1.0 Handshake [length 0061], ClientHello
    TLS_accept: SSLv3 read client hello A
    rlm_eap_tls: >>> TLS 1.0 Handshake [length 004a], ServerHello
    TLS_accept: SSLv3 write server hello A
    rlm_eap_tls: >>> TLS 1.0 Handshake [length 0734], Certificate
    TLS_accept: SSLv3 write certificate A
    rlm_eap_tls: >>> TLS 1.0 Handshake [length 020d], ServerKeyExchange
    TLS_accept: SSLv3 write key exchange A
    rlm_eap_tls: >>> TLS 1.0 Handshake [length 0004], ServerHelloDone
    TLS_accept: SSLv3 write server done A
    TLS_accept: SSLv3 flush data
    TLS_accept: Need to read more data: SSLv3 read client certificate A
    In SSL Handshake Phase
    In SSL Accept mode
    eaptls_process returned 13
    ++[eap] returns handled
    Sending Access-Challenge of id 185 to 10.19.198.231 port 19801
    EAP-Message = 0x01ba040015c0000009a3160301004a02000046030148a4a8 e49f8da6
    1380255cf63a888b4997f031d60eabc1df65d769c47c2a835d 204c19634fab06e54c5d8f8e91eee2
    7bfa4c4bd80f73d46726a6aa9c6ec9d46b9800390016030107 340b00073000072d00035e3082035a
    30820242a00302010202010e300d06092a864886f70d01010b 0500304d310b300906035504061302
    5553311a3018060355040a1311496e74656c20436f72706f72 6174696f6e31223020060355040313
    19496e74656c2057694d415820536572766572205375622043 41301e170d30383033303531393034
    35365a170d3338303330363139303435365a30573116301406
    EAP-Message = 0x0355040a0c0d537072696e74204e657874656c311e301c06 0355040b
    0c1557694d415820466f72756d28522920536572766572310a 3008060355040b0c01343111300f06
    035504030c08786f686d2e636f6d30820122300d06092a8648 86f70d01010105000382010f003082
    010a0282010100ce5002aacc12a34a67159a38629cc3fa896e e056c48ef593d978d1a941d5dcfab9
    417407974de935ecdf6450a0145c28702c0db6bfec7f7d8d73 a388299353924b4ed394dae0610f75
    1ecabf80775388f81139d7c6a2bbbb06581ef4f5167a5361a4 12c677f35054cb9a1802bfad47f048
    4a4e3f170cf1fca3264de39365a22882dec9a06bee5daaefcd
    EAP-Message = 0x0e9a7208499b4f4691cb426c0ddbb50f38f8fb92a63a2c8f 0e7f4a60
    776cc87e6ae7ac1bbc02f2982acc0d378f2a226d46a1e35069 5f43d5c7932a1c958c0c4ab4d683c9
    0f5d5e88fbb2308792e1f3905713d4f672542b53d9b43098ed 3d85ab070e4e971c143bca8b179021
    56f43adefed0b366f4a90203010001a33b303930090603551d 1304023000300b0603551d0f040403
    0205a0301f0603551d23041830168014dcaf91852f59569fd8 3057ec0cce63061f56ff9e300d0609
    2a864886f70d01010b050003820101005a08f9a53c6fe6f63d 2ce522fe7dda668eaae700045023f7
    5b913462171614959c5734059fa8ff3154be05ad10a5bd9c92
    EAP-Message = 0x4ce4a9e04a0187bb7711e896a289289af0b6ff377d709de6 2c043623
    61a3bfe215c2eb57339bf32ddc37a68307131f96f2dc43ecc0 f451f20efdb85f27f35238db351dc7
    03e3e5fd4aa99b4a48d262ff8a64c47c06f0a9195e3911a9cf 85264fb9f4ede4f6a68d5fa57e1cd2
    13a55e31bf0bb9a631291c1d3106e9d120276b9b576740c47a 4ef28db20bbd68b77f61351aa998ad
    64c589e44798c16b912190c22726a02d4334799fd39e081d2e 6a0b51f4505a0b5a54c90a2d2dac01
    8ad5417b6cd706fee4dc19dc5da149059a88800003c9308203 c5308202ada003020102020101300d
    06092a864886f70d01010b0500304e31263024060355040313
    EAP-Message = 0x1d57694d415820466f72756d
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0x31599a9733e38fe9acca5c2f1dc89330
    Finished request 2.
    Going to the next request
    Waking up in 3.5 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=186, leng
    th=140
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0x31599a9733e38fe9acca5c2f1dc89330
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02ba00061500
    Message-Authenticator = 0x5e90880da75d32e7c532443af13f1f6c
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 186 length 6
    rlm_eap: Continuing tunnel setup.
    ++[eap] returns ok
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP/ttls
    rlm_eap: processing type ttls
    rlm_eap_ttls: Authenticate
    rlm_eap_tls: processing TLS
    rlm_eap_tls: Received EAP-TLS ACK message
    rlm_eap_tls: ack handshake fragment handler
    eaptls_verify returned 1
    eaptls_process returned 13
    ++[eap] returns handled
    Sending Access-Challenge of id 186 to 10.19.198.231 port 19801
    EAP-Message = 0x01bb040015c0000009a32852292053657276657220526f6f 742d4341
    31173015060355040a130e57694d415820466f72756d285229 310b3009060355040613025553301e
    170d3038303130333232323335305a170d3433303130323232 323335305a304d310b300906035504
    0613025553311a3018060355040a1311496e74656c20436f72 706f726174696f6e31223020060355
    04031319496e74656c2057694d415820536572766572205375 6220434130820122300d06092a8648
    86f70d01010105000382010f003082010a0282010100c43c8a a44c801a067570647f9bf34771f841
    3547219bbe379ed6ef358f233a4b48c54433f189251d4db80e
    EAP-Message = 0xde071d3dda45d53ff025a812f55cc22ca3c8c9ce54b397ea b7c53ba5
    e50b5dd52d98ee397037d797570c1aa8ce63ea1e911faac89c 87e640cce6173846d44f82359ce815
    c607be5edec9f6d577daa81b38c5021dbd57fb8a16debac35c 30d160cbd87b6dda733fb1b15aba73
    96f6629f21a32ca16b94c42a158fbaad4f546a0ba71a6bf00b 9af44325e75d5b06f50801c60f21d7
    f1d4a4101e7a670a5a46e69c77c11b7012c40e4c63b75895ab d8b6ae71254d207a6526189263273f
    d119b7f9890806db0079aef5973a743707ce9c7ddfe073ce21 0203010001a381ae3081ab30120603
    551d130101ff040830060101ff020101300e0603551d0f0101
    EAP-Message = 0xff040403020106301d0603551d0e04160414dcaf91852f59 569fd830
    57ec0cce63061f56ff9e30450603551d1f043e303c303aa038 a0368634687474703a2f2f77696d61
    78666f72756d2e6f72672f63726c732f696e746572696d5f73 7276726f6f745f636163726c2e6372
    6c301f0603551d2304183016801444242dce8b547895a7c31f 03be731f1a70bd20a1300d06092a86
    4886f70d01010b050003820101004d905072f3317f37907a78 ddc5bccf4a51230c62aa189700a894
    176258fed38bdb5dad5f18a151e96d085cda6b559c692cb307 e9c29ea56d726b547b29bb8cbbde3e
    b085a6c651f1e88e72754a26b663ffb1f49ca686c4f36c5e60
    EAP-Message = 0x745f3bc7edc9afc1320210b6cb4aad5f6995be5aaeb230f0 751d67d5
    8b021e9c9076962375d50b0fbd49a5ea49c45f4859c0eac22c c467904f8246e0070dff6ac6089112
    f8b76e017a2bc46958f9d6bbd3b34cf68d4609b0ff48e8ee17 f7cc6f2ac84771c2e89f49a690ebf4
    4806f8271223b1fa516e02b7cfd27ffed7561f5ac13723ed22 1495617aff5bcfc7ddef57047dde42
    24e169dc7383f82f4a0056a713896f29b7160301020d0c0002 090080f0b6db676c9fcf7780842468
    a1d89b4abef36607162029cb6d6107d087a2a2b00b91b6b3d9 929c75b82cd2390c65179857aaaced
    286047d2a256469a02f15c8914b5f3ddb1972a705e0b498ab5
    EAP-Message = 0x87064215349cc08913277451
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0x31599a9732e28fe9acca5c2f1dc89330
    Finished request 3.
    Going to the next request
    Waking up in 2.4 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=187, leng
    th=140
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0x31599a9732e28fe9acca5c2f1dc89330
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02bb00061500
    Message-Authenticator = 0xb1507b6f278c6f04984adb7c0fc1b738
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 187 length 6
    rlm_eap: Continuing tunnel setup.
    ++[eap] returns ok
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP/ttls
    rlm_eap: processing type ttls
    rlm_eap_ttls: Authenticate
    rlm_eap_tls: processing TLS
    rlm_eap_tls: Received EAP-TLS ACK message
    rlm_eap_tls: ack handshake fragment handler
    eaptls_verify returned 1
    eaptls_process returned 13
    ++[eap] returns handled
    Sending Access-Challenge of id 187 to 10.19.198.231 port 19801
    EAP-Message = 0x01bc01c11580000009a3bc1fa417d3878638cf63dc23a149 d741f877
    5318269f0a08106a5d7bbbc7c8db6b3bc660950b6300010200 802c60c5e055002c417c899cfe9e69
    f58f0c8947ae75b7aa96ba853f32a65cdf563a0d79f5f552cd 9c06b8deafcbef246a50dd0c47f061
    c7cb6d1059ddaa7824c4ae23caec03d6f9758d01e1129431fc 0191bbac2e2ae5d71546cea2652381
    2e9e1607fe9c3771b8f7b36a1a56b6427bd3f5919ece6119d8 bc5606c7b39659bbfc01002ac87f02
    582002e81187ec4b0ea518fae356860b020add9c1bfbe52927 20b5177cbff175e6baaae0046224a4
    587a93c99046c602c06af2c232ba2bb4eefc5387c240016cdc
    EAP-Message = 0x092ba0a6620188dafd2995ba505e64ca7b61ddee35c488ac 024c85bb
    7964fc0f739efb50681dea7cc80a23e75d77aa5e7cc0003c0a ddff929c625fd22976f44be12a0443
    87b081778d6b6b56a90df284892c0e460e40f5589addb0c756 aa24f311bcd70bf3e998ea7d8bcd5e
    576f656617204060a8f091f7aa1f84dbdee0fab521161d019a 70f10d03eb27d28e71c19dbf6de3cc
    28941e066147e517dd1cb5ac27dfc9b621629b6860ab9b20a4 9d62cc23972962b7c26a297d65c916
    030100040e000000
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0x31599a9735e58fe9acca5c2f1dc89330
    Finished request 4.
    Going to the next request
    Waking up in 1.4 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=188, leng
    th=147
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0x31599a9735e58fe9acca5c2f1dc89330
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02bc000d150015030100020233
    Message-Authenticator = 0xf9cd726591bfea9e647f267b5bc92df3
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 188 length 13
    rlm_eap: Continuing tunnel setup.
    ++[eap] returns ok
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP/ttls
    rlm_eap: processing type ttls
    rlm_eap_ttls: Authenticate
    rlm_eap_tls: processing TLS
    eaptls_verify returned 7
    rlm_eap_tls: Done initial handshake
    rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal decrypt_error
    TLS Alert read:fatal:decrypt error
    TLS_accept:failed in SSLv3 read client certificate A
    rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decry
    pt error
    rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails.
    eaptls_process returned 13
    rlm_eap: Freeing handler
    ++[eap] returns reject
    auth: Failed to validate the user.
    Found Post-Auth-Type Reject
    +- entering group REJECT
    expand: %{User-Name} -> anonymous_identity
    attr_filter: Matched entry DEFAULT at line 11
    ++[attr_filter.access_reject] returns updated
    Sending Access-Reject of id 188 to 10.19.198.231 port 19801
    EAP-Message = 0x04bc0004
    Message-Authenticator = 0x00000000000000000000000000000000
    Finished request 5.
    Going to the next request
    Waking up in 0.3 seconds.
    Cleaning up request 0 ID 183 with timestamp +70
    Cleaning up request 1 ID 184 with timestamp +71
    Waking up in 1.3 seconds.
    Cleaning up request 2 ID 185 with timestamp +72
    Waking up in 1.0 seconds.
    Cleaning up request 3 ID 186 with timestamp +73
    Waking up in 1.0 seconds.
    Cleaning up request 4 ID 187 with timestamp +74
    Waking up in 1.0 seconds.
    Cleaning up request 5 ID 188 with timestamp +75
    Ready to process requests.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=191, leng
    th=139
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02bf001701616e6f6e796d6f75735f6964656e74697479
    Message-Authenticator = 0x1ecebcb7689a7e3f1bf714dde619b331
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 191 length 23
    rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
    ++[eap] returns updated
    ++[unix] returns notfound
    users: Matched entry anonymous_identity at line 778
    ++[files] returns ok
    ++[expiration] returns noop
    ++[logintime] returns noop
    rlm_pap: WARNING! No "known good" password found for the user. Authentication m
    ay fail because of this.
    ++[pap] returns noop
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: EAP Identity
    rlm_eap: processing type tls
    rlm_eap_tls: Requiring client certificate
    rlm_eap_tls: Initiate
    rlm_eap_tls: Start returned 1
    ++[eap] returns handled
    Sending Access-Challenge of id 191 to 10.19.198.231 port 19801
    3GPP2-MN-HA-SPI = 1000
    3GPP2-MN-HA-Shared-Key = "testtesttesttest"
    Motorola-WiMAX-User-NAI = "fbt3@wimax.mot.com"
    Motorola-WiMAX-EMS-Address = 10.10.10.10
    Motorola-WiMAX-Network-Domain-Name = "bt25.wimax.mot.com"
    Motorola-WiMAX-Provisioning-Server = "testuser"
    Motorola-WiMAX-Location-Server = "testuser"
    Motorola-WiMAX-NTP-Server = 0x010a13adf5
    Motorola-WiMAX-HO-SVC-CLASS = 0x05
    Motorola-WiMAX-Maximum-Total-Bandwidth = 0x000186a0000186a0
    Motorola-WiMAX-Maximum-Commit-Bandwidth = 0x0000c3500000c350
    Motorola-WiMAX-Convergence-Sublayer = 0x00
    Session-Timeout = 43200
    Motorola-WiMAX-Service-Flows = "2|Default"
    EAP-Message = 0x01c000060d20
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0xac7c7835acbc75e6037cf08f4de46719
    Finished request 6.
    Going to the next request
    Waking up in 4.9 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=192, leng
    th=140
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0xac7c7835acbc75e6037cf08f4de46719
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02c000060315
    Message-Authenticator = 0xca4d8264715d22f03a133ba123f344a8
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 192 length 6
    rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
    ++[eap] returns updated
    ++[unix] returns notfound
    users: Matched entry anonymous_identity at line 778
    ++[files] returns ok
    ++[expiration] returns noop
    ++[logintime] returns noop
    rlm_pap: WARNING! No "known good" password found for the user. Authentication m
    ay fail because of this.
    ++[pap] returns noop
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP NAK
    rlm_eap: EAP-NAK asked for EAP-Type/ttls
    rlm_eap: processing type tls
    rlm_eap_tls: Initiate
    rlm_eap_tls: Start returned 1
    ++[eap] returns handled
    Sending Access-Challenge of id 192 to 10.19.198.231 port 19801
    3GPP2-MN-HA-SPI = 1000
    3GPP2-MN-HA-Shared-Key = "testtesttesttest"
    Motorola-WiMAX-User-NAI = "fbt3@wimax.mot.com"
    Motorola-WiMAX-EMS-Address = 10.10.10.10
    Motorola-WiMAX-Network-Domain-Name = "bt25.wimax.mot.com"
    Motorola-WiMAX-Provisioning-Server = "testuser"
    Motorola-WiMAX-Location-Server = "testuser"
    Motorola-WiMAX-NTP-Server = 0x010a13adf5
    Motorola-WiMAX-HO-SVC-CLASS = 0x05
    Motorola-WiMAX-Maximum-Total-Bandwidth = 0x000186a0000186a0
    Motorola-WiMAX-Maximum-Commit-Bandwidth = 0x0000c3500000c350
    Motorola-WiMAX-Convergence-Sublayer = 0x00
    Session-Timeout = 43200
    Motorola-WiMAX-Service-Flows = "2|Default"
    EAP-Message = 0x01c100061520
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0xac7c7835adbd6de6037cf08f4de46719
    Finished request 7.
    Going to the next request
    Waking up in 4.9 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=193, leng
    th=242
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0xac7c7835adbd6de6037cf08f4de46719
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02c1006c150016030100610100005d030148a4a90f646a86 ef3817ee
    da28db3450ae987a75fdd3c2df1c9906b90126f1bc00003600 390038003500160013000a00330032
    002f0007006600050004006300620061001500120009006500 640060001400110008000600030100
    Message-Authenticator = 0xceb121b1811d4ded0a43eecdc781dbd7
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 193 length 108
    rlm_eap: Continuing tunnel setup.
    ++[eap] returns ok
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP/ttls
    rlm_eap: processing type ttls
    rlm_eap_ttls: Authenticate
    rlm_eap_tls: processing TLS
    eaptls_verify returned 7
    rlm_eap_tls: Done initial handshake
    (other): before/accept initialization
    TLS_accept: before/accept initialization
    rlm_eap_tls: <<< TLS 1.0 Handshake [length 0061], ClientHello
    TLS_accept: SSLv3 read client hello A
    rlm_eap_tls: >>> TLS 1.0 Handshake [length 004a], ServerHello
    TLS_accept: SSLv3 write server hello A
    rlm_eap_tls: >>> TLS 1.0 Handshake [length 0734], Certificate
    TLS_accept: SSLv3 write certificate A
    rlm_eap_tls: >>> TLS 1.0 Handshake [length 020d], ServerKeyExchange
    TLS_accept: SSLv3 write key exchange A
    rlm_eap_tls: >>> TLS 1.0 Handshake [length 0004], ServerHelloDone
    TLS_accept: SSLv3 write server done A
    TLS_accept: SSLv3 flush data
    TLS_accept: Need to read more data: SSLv3 read client certificate A
    In SSL Handshake Phase
    In SSL Accept mode
    eaptls_process returned 13
    ++[eap] returns handled
    Sending Access-Challenge of id 193 to 10.19.198.231 port 19801
    EAP-Message = 0x01c2040015c0000009a3160301004a02000046030148a4a8 efa49452
    0d8c28db3afc4b98c3d6481404474d5925cc8dd8cf92cb77b3 20ddeaa3002f91be71c4d8887cf36b
    2d2f92f11e29a353240d2c7209996721225f00390016030107 340b00073000072d00035e3082035a
    30820242a00302010202010e300d06092a864886f70d01010b 0500304d310b300906035504061302
    5553311a3018060355040a1311496e74656c20436f72706f72 6174696f6e31223020060355040313
    19496e74656c2057694d415820536572766572205375622043 41301e170d30383033303531393034
    35365a170d3338303330363139303435365a30573116301406
    EAP-Message = 0x0355040a0c0d537072696e74204e657874656c311e301c06 0355040b
    0c1557694d415820466f72756d28522920536572766572310a 3008060355040b0c01343111300f06
    035504030c08786f686d2e636f6d30820122300d06092a8648 86f70d01010105000382010f003082
    010a0282010100ce5002aacc12a34a67159a38629cc3fa896e e056c48ef593d978d1a941d5dcfab9
    417407974de935ecdf6450a0145c28702c0db6bfec7f7d8d73 a388299353924b4ed394dae0610f75
    1ecabf80775388f81139d7c6a2bbbb06581ef4f5167a5361a4 12c677f35054cb9a1802bfad47f048
    4a4e3f170cf1fca3264de39365a22882dec9a06bee5daaefcd
    EAP-Message = 0x0e9a7208499b4f4691cb426c0ddbb50f38f8fb92a63a2c8f 0e7f4a60
    776cc87e6ae7ac1bbc02f2982acc0d378f2a226d46a1e35069 5f43d5c7932a1c958c0c4ab4d683c9
    0f5d5e88fbb2308792e1f3905713d4f672542b53d9b43098ed 3d85ab070e4e971c143bca8b179021
    56f43adefed0b366f4a90203010001a33b303930090603551d 1304023000300b0603551d0f040403
    0205a0301f0603551d23041830168014dcaf91852f59569fd8 3057ec0cce63061f56ff9e300d0609
    2a864886f70d01010b050003820101005a08f9a53c6fe6f63d 2ce522fe7dda668eaae700045023f7
    5b913462171614959c5734059fa8ff3154be05ad10a5bd9c92
    EAP-Message = 0x4ce4a9e04a0187bb7711e896a289289af0b6ff377d709de6 2c043623
    61a3bfe215c2eb57339bf32ddc37a68307131f96f2dc43ecc0 f451f20efdb85f27f35238db351dc7
    03e3e5fd4aa99b4a48d262ff8a64c47c06f0a9195e3911a9cf 85264fb9f4ede4f6a68d5fa57e1cd2
    13a55e31bf0bb9a631291c1d3106e9d120276b9b576740c47a 4ef28db20bbd68b77f61351aa998ad
    64c589e44798c16b912190c22726a02d4334799fd39e081d2e 6a0b51f4505a0b5a54c90a2d2dac01
    8ad5417b6cd706fee4dc19dc5da149059a88800003c9308203 c5308202ada003020102020101300d
    06092a864886f70d01010b0500304e31263024060355040313
    EAP-Message = 0x1d57694d415820466f72756d
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0xac7c7835aebe6de6037cf08f4de46719
    Finished request 8.
    Going to the next request
    Waking up in 3.6 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=194, leng
    th=140
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0xac7c7835aebe6de6037cf08f4de46719
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02c200061500
    Message-Authenticator = 0x25c25bafd6d013b58dc0e9ff0229ab2a
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 194 length 6
    rlm_eap: Continuing tunnel setup.
    ++[eap] returns ok
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP/ttls
    rlm_eap: processing type ttls
    rlm_eap_ttls: Authenticate
    rlm_eap_tls: processing TLS
    rlm_eap_tls: Received EAP-TLS ACK message
    rlm_eap_tls: ack handshake fragment handler
    eaptls_verify returned 1
    eaptls_process returned 13
    ++[eap] returns handled
    Sending Access-Challenge of id 194 to 10.19.198.231 port 19801
    EAP-Message = 0x01c3040015c0000009a32852292053657276657220526f6f 742d4341
    31173015060355040a130e57694d415820466f72756d285229 310b3009060355040613025553301e
    170d3038303130333232323335305a170d3433303130323232 323335305a304d310b300906035504
    0613025553311a3018060355040a1311496e74656c20436f72 706f726174696f6e31223020060355
    04031319496e74656c2057694d415820536572766572205375 6220434130820122300d06092a8648
    86f70d01010105000382010f003082010a0282010100c43c8a a44c801a067570647f9bf34771f841
    3547219bbe379ed6ef358f233a4b48c54433f189251d4db80e
    EAP-Message = 0xde071d3dda45d53ff025a812f55cc22ca3c8c9ce54b397ea b7c53ba5
    e50b5dd52d98ee397037d797570c1aa8ce63ea1e911faac89c 87e640cce6173846d44f82359ce815
    c607be5edec9f6d577daa81b38c5021dbd57fb8a16debac35c 30d160cbd87b6dda733fb1b15aba73
    96f6629f21a32ca16b94c42a158fbaad4f546a0ba71a6bf00b 9af44325e75d5b06f50801c60f21d7
    f1d4a4101e7a670a5a46e69c77c11b7012c40e4c63b75895ab d8b6ae71254d207a6526189263273f
    d119b7f9890806db0079aef5973a743707ce9c7ddfe073ce21 0203010001a381ae3081ab30120603
    551d130101ff040830060101ff020101300e0603551d0f0101
    EAP-Message = 0xff040403020106301d0603551d0e04160414dcaf91852f59 569fd830
    57ec0cce63061f56ff9e30450603551d1f043e303c303aa038 a0368634687474703a2f2f77696d61
    78666f72756d2e6f72672f63726c732f696e746572696d5f73 7276726f6f745f636163726c2e6372
    6c301f0603551d2304183016801444242dce8b547895a7c31f 03be731f1a70bd20a1300d06092a86
    4886f70d01010b050003820101004d905072f3317f37907a78 ddc5bccf4a51230c62aa189700a894
    176258fed38bdb5dad5f18a151e96d085cda6b559c692cb307 e9c29ea56d726b547b29bb8cbbde3e
    b085a6c651f1e88e72754a26b663ffb1f49ca686c4f36c5e60
    EAP-Message = 0x745f3bc7edc9afc1320210b6cb4aad5f6995be5aaeb230f0 751d67d5
    8b021e9c9076962375d50b0fbd49a5ea49c45f4859c0eac22c c467904f8246e0070dff6ac6089112
    f8b76e017a2bc46958f9d6bbd3b34cf68d4609b0ff48e8ee17 f7cc6f2ac84771c2e89f49a690ebf4
    4806f8271223b1fa516e02b7cfd27ffed7561f5ac13723ed22 1495617aff5bcfc7ddef57047dde42
    24e169dc7383f82f4a0056a713896f29b7160301020d0c0002 090080f0b6db676c9fcf7780842468
    a1d89b4abef36607162029cb6d6107d087a2a2b00b91b6b3d9 929c75b82cd2390c65179857aaaced
    286047d2a256469a02f15c8914b5f3ddb1972a705e0b498ab5
    EAP-Message = 0x87064215349cc08913277451
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0xac7c7835afbf6de6037cf08f4de46719
    Finished request 9.
    Going to the next request
    Waking up in 2.6 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=195, leng
    th=140
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0xac7c7835afbf6de6037cf08f4de46719
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02c300061500
    Message-Authenticator = 0xe073757d183e771ab05bce878f4a4f24
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 195 length 6
    rlm_eap: Continuing tunnel setup.
    ++[eap] returns ok
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP/ttls
    rlm_eap: processing type ttls
    rlm_eap_ttls: Authenticate
    rlm_eap_tls: processing TLS
    rlm_eap_tls: Received EAP-TLS ACK message
    rlm_eap_tls: ack handshake fragment handler
    eaptls_verify returned 1
    eaptls_process returned 13
    ++[eap] returns handled
    Sending Access-Challenge of id 195 to 10.19.198.231 port 19801
    EAP-Message = 0x01c401c11580000009a3bc1fa417d3878638cf63dc23a149 d741f877
    5318269f0a08106a5d7bbbc7c8db6b3bc660950b6300010200 802e5fc98d74f79e490152db5c816b
    5a63f85617e82f3c0176fb472d18801f68b381da763b565c6a 4245074a7b1598b67b6f20c58825fa
    9ece1784563447231c3925e6c5a12134b8051808345cf3f62e 6ea7b0707bd319c90aecb83086cbc3
    4c56b634dae85bc137f73735f8975bb0ea19914842bbcfe8d2 15beed84c4dfbe50a10100c68a47cf
    987a66397663c9394920c5d4a5ee6db6933af194d8098c8cd8 3cf36b991ea9c517e7d068ca368add
    896d33f1599e9e58530bcb3cee5a9521060259a36454bd8db0
    EAP-Message = 0xddd2099d80a2c5a9821a5163758e2d4446512dab7b0a4f27 6f7c2d44
    3d092928f0a472c035ba80b7f92ed9bb01255ea22d17377585 62056b4dae2c2e80f2abd27b209092
    c9cb998510caf24fcfb6f5ad0a229eb2115c68469479019fe0 305f89e04342dd9cd89854e09c2e36
    3288714e23c67fee39e6d3a3e23fcf4e62670712b278f79a02 df974f83300d401b37d54670091900
    590c5455dc35a8be4d989c5146c55febe1d4b5df892a4975d4 c8beb555c5e34050645e4d5f1b0316
    030100040e000000
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0xac7c7835a8b86de6037cf08f4de46719
    Finished request 10.
    Going to the next request
    Waking up in 1.5 seconds.
    rad_recv: Access-Request packet from host 10.19.198.231 port 19801, id=196, leng
    th=147
    User-Name = "anonymous_identity"
    NAS-IP-Address = 192.168.1.102
    NAS-Port = 2048
    Service-Type = Login-User
    State = 0xac7c7835a8b86de6037cf08f4de46719
    Called-Station-Id = "\000\000{\000\000\010"
    Calling-Station-Id = "001e5a91f8b2"
    NAS-Identifier = "testuser"
    NAS-Port-Type = Wireless-Other
    EAP-Message = 0x02c4000d150015030100020233
    Message-Authenticator = 0x6a99fb6ef105249a453915162ac30dc6
    +- entering group authorize
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    rlm_realm: No '@' in User-Name = "anonymous_identity", looking up realm NULL
    rlm_realm: No such realm "NULL"
    ++[suffix] returns noop
    rlm_eap: EAP packet type response id 196 length 13
    rlm_eap: Continuing tunnel setup.
    ++[eap] returns ok
    rad_check_password: Found Auth-Type EAP
    auth: type "EAP"
    +- entering group authenticate
    rlm_eap: Request found, released from the list
    rlm_eap: EAP/ttls
    rlm_eap: processing type ttls
    rlm_eap_ttls: Authenticate
    rlm_eap_tls: processing TLS
    eaptls_verify returned 7
    rlm_eap_tls: Done initial handshake
    rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal decrypt_error
    TLS Alert read:fatal:decrypt error
    TLS_accept:failed in SSLv3 read client certificate A
    rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decry
    pt error
    rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails.
    eaptls_process returned 13
    rlm_eap: Freeing handler
    ++[eap] returns reject
    auth: Failed to validate the user.
    Found Post-Auth-Type Reject
    +- entering group REJECT
    expand: %{User-Name} -> anonymous_identity
    attr_filter: Matched entry DEFAULT at line 11
    ++[attr_filter.access_reject] returns updated
    Sending Access-Reject of id 196 to 10.19.198.231 port 19801
    EAP-Message = 0x04c40004
    Message-Authenticator = 0x00000000000000000000000000000000
    Finished request 11.

    On 8/13/08, Sergio wrote:
    > Rafiqul Ahsan escribió:
    >
    > > Found a previous postings like this where Alan Dekok answered that
    > > FreeRadius use SSL from openssl, and if SSL supports any advanced
    > > algorithm FreeRadius should support it (I actually added a patch to
    > > FreeRadius to make sure this supports all digests). I am currently
    > > trying to find out whether I have linked the right openssl libraries
    > > when building the FreeRadius. I am unable to find out whether
    > > FreeRadius is being built with Solaris prebuilt openssl version 0.9.7d
    > > at /usr/sfw, or my newly installed openssl version 0.9.8h at
    > > /usr/local (with library /usr/local/ssl/lib). I have however few
    > > questions , and I would appreciate your reply:
    > >
    > > 1. How to create CAcert.pem (root certs), server.pem (device certs),
    > > and server_pvt_key.pem (private key file) for server, and same for
    > > client to test TTLS, and TLS. It could be self signed.
    > > 2. Also how to create certs using different algorithm (sha1, sha2,
    > > sha256 etc.) ?
    > >
    > > I need to create certs to test EAP-TLS/TTLS using WiMAX AP.
    > >
    > > Thanks, and appreciate your help.
    > >
    > > On 8/12/08, Sergio wrote:
    > >
    > >
    > > > Rafiqul Ahsan escribió:
    > > >
    > > >
    > > >
    > > > > I see an error like below when trying to use EAP_TLS/TTLS
    > > > > authentication with Certs that has Signature Algorithm:
    > > > > sha256WithRSAEncryption . Can anybody tell me why SSL does not like
    > > > > the TLS session ?
    > > > >
    > > > > I would appreciate your help. here is the radiusd -X log:
    > > > >
    > > > > ++[suffix] returns noop
    > > > > rlm_eap: EAP packet type response id 142 length 13
    > > > > rlm_eap: Continuing tunnel setup.
    > > > > ++[eap] returns ok
    > > > > rad_check_password: Found Auth-Type EAP
    > > > > auth: type "EAP"
    > > > > +- entering group authenticate
    > > > > rlm_eap: Request found, released from the list
    > > > > rlm_eap: EAP/ttls
    > > > > rlm_eap: processing type ttls
    > > > > rlm_eap_ttls: Authenticate
    > > > > rlm_eap_tls: processing TLS
    > > > > eaptls_verify returned 7
    > > > > rlm_eap_tls: Done initial handshake
    > > > > rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal decrypt_error
    > > > > TLS Alert read:fatal:decrypt error
    > > > > TLS_accept:failed in SSLv3 read client certificate A
    > > > > rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1

    > alert
    > > > >
    > > > >
    > > > decry
    > > >
    > > >
    > > > > pt error
    > > > > rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails.
    > > > > eaptls_process returned 13
    > > > > rlm_eap: Freeing handler
    > > > > ++[eap] returns reject
    > > > > auth: Failed to validate the user.
    > > > > Found Post-Auth-Type Reject
    > > > > +- entering group REJECT
    > > > > expand: %{User-Name} -> anonymous_identity
    > > > > attr_filter: Matched entry DEFAULT at line 11
    > > > > ++[attr_filter.access_reject] returns updated
    > > > > Sending Access-Reject of id 142 to 10.19.198.231 port 19801
    > > > >
    > > > >
    > > > >
    > > > >
    > > > >
    > > > Hi,
    > > > recently i tried to use certs with SHA-2 sign and got the same error.
    > > > Probaly freeradius doesn't support (also) this size of sign. You can ask
    > > > about this into freeradius mailing list. Try to put a cert with SHA-1
    > > > algorithm and you will see it working.
    > > >

    > __________________________________________________ ____________________
    > > > OpenSSL Project http://www.openssl.org
    > > > User Support Mailing List openssl-users@openssl.org
    > > > Automated List Manager majordomo@openssl.org
    > > >
    > > >
    > > >

    > >
    > >
    > >

    > I'm not an expert but, not all SSL functions are used by freeradius, por
    > example ocsp functions. You can see raddb/certs/Makefile and
    > raddb/certs/README to follow the commands which creates test certificates..
    > Surely with another openssl options you can use several algorithms but,
    > there is one important point with test certs that freeradius generates.
    > Client certificates are signed by server private key, so you should put the
    > correct permissions into your openssl configuration for server certs
    > creation or sign client cert with ca private key. I taken the second
    > decision because it's more clear for me, and because the functionality is
    > EXACTLY the same. For the other side, i don't know anything about WiMAX, but
    > i suposse that credentials are the same. Hope this helps
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



    --
    Rafiqul Ahsan
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  8. Re: openssl 0.8.9h sha256

    Sergio wrote:
    > For the other side, i don't know anything about WiMAX, but i suposse
    > that credentials are the same. Hope this helps
    > __________________________________________________ ____________________
    >

    I do. WiMAX certs (the ones uses in EAP-TLS and EAP-TTLS sessions over
    the airlink to identify the device and AAA server) are required to use
    sha256withRSAEncryption and should use 2048 bit RSA but may use 1024 bit
    RSA if the notAfter date doesn't go past 2010. The root and subordinate
    certs for the server and device hierarchies from the WiMAX PKI do use
    sha256withRSAEncryption and 2048 bit RSA as do all the certs signed by
    the WiMAX CA. The WiMAX CA uses vanilla OpenSSL.

    I can confirm that people have got these WiMAX compliant certs
    authenticating with FreeRADIUS in a WiMAX network.

    Things to look out for.. Run it on a 64 bit OS. E.G. it has worked on 64
    bit fedora. The dates of the root and sub certs hit the 2038 problem, so
    64 bit is required for chain validation to work. Use the most current
    FreeRADIUS and OpenSSL packages that has support for the signature
    algorithms. Make sure you have the proper chain certs installed. If you
    are a WiMAX member, the certs are there on the WiMAX Forum web site with
    various documents including handy overview document that describes what
    chain certs to put where.

    Don't confuse these certs with the 802.16 authorization certs for fixed
    operation. These have a different profile that is in the 802.16 spec,
    don't go over EAP and use a different CA that I have nothing to do with.

    David Johnston




    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  9. Re: openssl 0.8.9h sha256

    We saw these same errors in a WiMAX test network with Free Radius.

    Moving from an older 32 bit Fedora to a current 64 bit Fedora and the
    stock freeradius and freeradius-util packages made it work and made the
    errors you exhibit disappear.

    openssl0.9.8h manifestly does support the necessary algorithms. With
    WiMAX certs (I assume from the logs, that is what you are using), you
    absolutely do need a 64 bit installation due to the post 2038 dates in
    the root and subordinate CA certs.

    DJ

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  10. Re: openssl 0.8.9h sha256

    Hi David,

    Thanks for your reply...I believe I am running Freeradius, and
    openssl0.9.8h on 64 bit OS. If you want I can post the certs output as
    well. Pls let me know. I need to make this working, and I have been
    working on this for last 2 weeks and seeing the same error.

    Here is the command used to verify :

    bash-3.00# isainfo -b
    64
    bash-3.00# isainfo -v
    64-bit sparcv9 applications
    vis2 vis
    32-bit sparc applications
    vis2 vis v8plus div32 mul32

    Here is the machine I am using (v210) :
    bash-3.00# uname -a
    SunOS v210ap20 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-V210


    On 8/14/08, David Johnston wrote:
    > We saw these same errors in a WiMAX test network with Free Radius.
    >
    > Moving from an older 32 bit Fedora to a current 64 bit Fedora and the stock
    > freeradius and freeradius-util packages made it work and made the errors you
    > exhibit disappear.
    >
    > openssl0.9.8h manifestly does support the necessary algorithms. With WiMAX
    > certs (I assume from the logs, that is what you are using), you absolutely
    > do need a 64 bit installation due to the post 2038 dates in the root and
    > subordinate CA certs.
    >
    > DJ
    >
    >



    --
    Rafiqul Ahsan
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  11. Re: openssl 0.8.9h sha256

    Hi David,

    I believe 2048 could not be the issue (as you said because I am using
    64 bit OS), this is about supporting sha256 algorithm either with
    0.9.8h, or my Freeradius 2.0.5 (both are latest). Because sha1 works
    well with my installation with even RSA 2048 key. And ofcourse, as per
    my previous email it was evident that I am using 64 bit OS. Here is
    the output of my working certs :

    Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    44:ae:e6:13:b6:3e:1c:63:39:eb:02:ef:7c:54:3f:9e
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=Motorola, Inc., OU=WiMAX Device Certificate Authority, C
    N=Motorola WiMAX Device Root CA
    Validity
    Not Before: Jul 7 22:54:11 2006 GMT
    Not After : Jul 7 22:54:11 2036 GMT
    Subject: C=US, O=Motorola, Inc., OU=WiMAX Device Certificate Authority,
    CN=Motorola WiMAX Device Root CA
    Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (2048 bit)
    Modulus (2048 bit):
    00:a7:7c:24:7f:ff:7b:aa:88:c6:ea:af:7e:1d:f4:
    bb:7d:ae:11:f0:27:72:61:9b:19:6e:b6:c8:1d:20:
    aa:a9:52:34:41:87:f0:05:94:ad:c4:77:7b:93:08:
    5c:29:8b:80:14:11:69:1c:4c:1d:39:cb:ff:30:9b:
    62:9d:d7:78:07:43:71:7c:15:31:fa:79:2c:36:a1:
    6b:d3:58:10:c2:8f:7c:91:20:1d:dc:9e:ea:10:55:
    66:cf:95:1f:9a:aa:8d:e6:2f:e9:dd:de:07:5c:87:
    17:77:0f:b4:26:d5:a4:c0:e9:09:8b:00:ec:f3:49:
    6f:37:bf:ac:a7:f1:81:64:6d:ab:2c:32:2d:03:7c:
    95:5b:8b:48:29:23:55:49:9b:df:bc:e2:26:4b:0f:
    ef:9f:81:5d:a9:b4:f2:34:b2:9f:a4:72:9e:0c:2d:
    d7:1d:7b:04:70:76:16:93:1e:7c:64:18:79:07:6d:
    60:c9:e6:8c:10:73:94:0f:2e:a1:63:d9:38:61:6e:
    5f:81:67:fe:39:3f:aa:47:26:14:30:0a:c4:c2:0b:
    4c:b1:2f:15:cd:dc:79:79:a7:f0:2a:1f:15:c6:25:
    cb:61:84:20:27:4d:48:44:9a:f2:47:f9:c7:b5:09:
    db:d7:28:f5:28:2e:f2:cc:42:31:36:8a:95:dc:02:
    22:39
    Exponent: 65537 (0x10001)
    X509v3 extensions:
    X509v3 Key Usage:
    Certificate Sign, CRL Sign
    X509v3 Subject Key Identifier:
    74:9F:F6:2C:2B:60:80:53:17:79:A0:39:6D:77:84:FD:BA8:88:65
    X509v3 Basic Constraints: critical
    CA:TRUE

    On 8/14/08, Rafiqul Ahsan wrote:
    > Hi David,
    >
    > Thanks for your reply...I believe I am running Freeradius, and
    > openssl0.9.8h on 64 bit OS. If you want I can post the certs output as
    > well. Pls let me know. I need to make this working, and I have been
    > working on this for last 2 weeks and seeing the same error.
    >
    > Here is the command used to verify :
    >
    > bash-3.00# isainfo -b
    > 64
    > bash-3.00# isainfo -v
    > 64-bit sparcv9 applications
    > vis2 vis
    > 32-bit sparc applications
    > vis2 vis v8plus div32 mul32
    >
    > Here is the machine I am using (v210) :
    > bash-3.00# uname -a
    > SunOS v210ap20 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-V210
    >
    >
    > On 8/14/08, David Johnston wrote:
    > > We saw these same errors in a WiMAX test network with Free Radius.
    > >
    > > Moving from an older 32 bit Fedora to a current 64 bit Fedora and the stock
    > > freeradius and freeradius-util packages made it work and made the errors you
    > > exhibit disappear.
    > >
    > > openssl0.9.8h manifestly does support the necessary algorithms. With WiMAX
    > > certs (I assume from the logs, that is what you are using), you absolutely
    > > do need a 64 bit installation due to the post 2038 dates in the root and
    > > subordinate CA certs.
    > >
    > > DJ
    > >
    > >

    >
    >
    > --
    > Rafiqul Ahsan
    >



    --
    Rafiqul Ahsan
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  12. Re: openssl 0.8.9h sha256

    On Thu August 14 2008 23:05, Rafiqul Ahsan wrote:
    > Hi David,
    >
    > I believe 2048 could not be the issue (as you said because I am using
    > 64 bit OS),
    >


    Which will probably run either 32bit or 64bit userland code.
    Next question: Are you running 64bit openSSL?
    (You could be running 32bit openSSL and never know it unless you check.)

    Mike

    > this is about supporting sha256 algorithm either with
    > 0.9.8h, or my Freeradius 2.0.5 (both are latest). Because sha1 works
    > well with my installation with even RSA 2048 key. And ofcourse, as per
    > my previous email it was evident that I am using 64 bit OS. Here is
    > the output of my working certs :
    >
    > Certificate:
    > Data:
    > Version: 3 (0x2)
    > Serial Number:
    > 44:ae:e6:13:b6:3e:1c:63:39:eb:02:ef:7c:54:3f:9e
    > Signature Algorithm: sha1WithRSAEncryption
    > Issuer: C=US, O=Motorola, Inc., OU=WiMAX Device Certificate Authority, C
    > N=Motorola WiMAX Device Root CA
    > Validity
    > Not Before: Jul 7 22:54:11 2006 GMT
    > Not After : Jul 7 22:54:11 2036 GMT
    > Subject: C=US, O=Motorola, Inc., OU=WiMAX Device Certificate Authority,
    > CN=Motorola WiMAX Device Root CA
    > Subject Public Key Info:
    > Public Key Algorithm: rsaEncryption
    > RSA Public Key: (2048 bit)
    > Modulus (2048 bit):
    > 00:a7:7c:24:7f:ff:7b:aa:88:c6:ea:af:7e:1d:f4:
    > bb:7d:ae:11:f0:27:72:61:9b:19:6e:b6:c8:1d:20:
    > aa:a9:52:34:41:87:f0:05:94:ad:c4:77:7b:93:08:
    > 5c:29:8b:80:14:11:69:1c:4c:1d:39:cb:ff:30:9b:
    > 62:9d:d7:78:07:43:71:7c:15:31:fa:79:2c:36:a1:
    > 6b:d3:58:10:c2:8f:7c:91:20:1d:dc:9e:ea:10:55:
    > 66:cf:95:1f:9a:aa:8d:e6:2f:e9:dd:de:07:5c:87:
    > 17:77:0f:b4:26:d5:a4:c0:e9:09:8b:00:ec:f3:49:
    > 6f:37:bf:ac:a7:f1:81:64:6d:ab:2c:32:2d:03:7c:
    > 95:5b:8b:48:29:23:55:49:9b:df:bc:e2:26:4b:0f:
    > ef:9f:81:5d:a9:b4:f2:34:b2:9f:a4:72:9e:0c:2d:
    > d7:1d:7b:04:70:76:16:93:1e:7c:64:18:79:07:6d:
    > 60:c9:e6:8c:10:73:94:0f:2e:a1:63:d9:38:61:6e:
    > 5f:81:67:fe:39:3f:aa:47:26:14:30:0a:c4:c2:0b:
    > 4c:b1:2f:15:cd:dc:79:79:a7:f0:2a:1f:15:c6:25:
    > cb:61:84:20:27:4d:48:44:9a:f2:47:f9:c7:b5:09:
    > db:d7:28:f5:28:2e:f2:cc:42:31:36:8a:95:dc:02:
    > 22:39
    > Exponent: 65537 (0x10001)
    > X509v3 extensions:
    > X509v3 Key Usage:
    > Certificate Sign, CRL Sign
    > X509v3 Subject Key Identifier:
    > 74:9F:F6:2C:2B:60:80:53:17:79:A0:39:6D:77:84:FD:BA8:88:65
    > X509v3 Basic Constraints: critical
    > CA:TRUE
    >
    > On 8/14/08, Rafiqul Ahsan wrote:
    > > Hi David,
    > >
    > > Thanks for your reply...I believe I am running Freeradius, and
    > > openssl0.9.8h on 64 bit OS. If you want I can post the certs output as
    > > well. Pls let me know. I need to make this working, and I have been
    > > working on this for last 2 weeks and seeing the same error.
    > >
    > > Here is the command used to verify :
    > >
    > > bash-3.00# isainfo -b
    > > 64
    > > bash-3.00# isainfo -v
    > > 64-bit sparcv9 applications
    > > vis2 vis
    > > 32-bit sparc applications
    > > vis2 vis v8plus div32 mul32
    > >
    > > Here is the machine I am using (v210) :
    > > bash-3.00# uname -a
    > > SunOS v210ap20 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-V210
    > >
    > >
    > > On 8/14/08, David Johnston wrote:
    > > > We saw these same errors in a WiMAX test network with Free Radius.
    > > >
    > > > Moving from an older 32 bit Fedora to a current 64 bit Fedora and the stock
    > > > freeradius and freeradius-util packages made it work and made the errors you
    > > > exhibit disappear.
    > > >
    > > > openssl0.9.8h manifestly does support the necessary algorithms. With WiMAX
    > > > certs (I assume from the logs, that is what you are using), you absolutely
    > > > do need a 64 bit installation due to the post 2038 dates in the root and
    > > > subordinate CA certs.
    > > >
    > > > DJ
    > > >
    > > >

    > >
    > >
    > > --
    > > Rafiqul Ahsan
    > >

    >
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  13. Re: openssl 0.8.9h sha256

    Mike,

    I have installed openssl on 64 bit OS. I believe 64-bit libraries
    produced by default if we try to build OpenSSL on a 64-bit platform.

    I would still like to verify whether the installed openssl is 32, or
    64 bit . Can you please let me know the necessary commands to verify
    it ?


    On 8/15/08, Michael S. Zick wrote:
    > On Thu August 14 2008 23:05, Rafiqul Ahsan wrote:
    > > Hi David,
    > >
    > > I believe 2048 could not be the issue (as you said because I am using
    > > 64 bit OS),
    > >

    >
    > Which will probably run either 32bit or 64bit userland code.
    > Next question: Are you running 64bit openSSL?
    > (You could be running 32bit openSSL and never know it unless you check.)
    >
    > Mike
    >
    > > this is about supporting sha256 algorithm either with
    > > 0.9.8h, or my Freeradius 2.0.5 (both are latest). Because sha1 works
    > > well with my installation with even RSA 2048 key. And ofcourse, as per
    > > my previous email it was evident that I am using 64 bit OS. Here is
    > > the output of my working certs :
    > >
    > > Certificate:
    > > Data:
    > > Version: 3 (0x2)
    > > Serial Number:
    > > 44:ae:e6:13:b6:3e:1c:63:39:eb:02:ef:7c:54:3f:9e
    > > Signature Algorithm: sha1WithRSAEncryption
    > > Issuer: C=US, O=Motorola, Inc., OU=WiMAX Device Certificate Authority, C
    > > N=Motorola WiMAX Device Root CA
    > > Validity
    > > Not Before: Jul 7 22:54:11 2006 GMT
    > > Not After : Jul 7 22:54:11 2036 GMT
    > > Subject: C=US, O=Motorola, Inc., OU=WiMAX Device Certificate Authority,
    > > CN=Motorola WiMAX Device Root CA
    > > Subject Public Key Info:
    > > Public Key Algorithm: rsaEncryption
    > > RSA Public Key: (2048 bit)
    > > Modulus (2048 bit):
    > > 00:a7:7c:24:7f:ff:7b:aa:88:c6:ea:af:7e:1d:f4:
    > > bb:7d:ae:11:f0:27:72:61:9b:19:6e:b6:c8:1d:20:
    > > aa:a9:52:34:41:87:f0:05:94:ad:c4:77:7b:93:08:
    > > 5c:29:8b:80:14:11:69:1c:4c:1d:39:cb:ff:30:9b:
    > > 62:9d:d7:78:07:43:71:7c:15:31:fa:79:2c:36:a1:
    > > 6b:d3:58:10:c2:8f:7c:91:20:1d:dc:9e:ea:10:55:
    > > 66:cf:95:1f:9a:aa:8d:e6:2f:e9:dd:de:07:5c:87:
    > > 17:77:0f:b4:26:d5:a4:c0:e9:09:8b:00:ec:f3:49:
    > > 6f:37:bf:ac:a7:f1:81:64:6d:ab:2c:32:2d:03:7c:
    > > 95:5b:8b:48:29:23:55:49:9b:df:bc:e2:26:4b:0f:
    > > ef:9f:81:5d:a9:b4:f2:34:b2:9f:a4:72:9e:0c:2d:
    > > d7:1d:7b:04:70:76:16:93:1e:7c:64:18:79:07:6d:
    > > 60:c9:e6:8c:10:73:94:0f:2e:a1:63:d9:38:61:6e:
    > > 5f:81:67:fe:39:3f:aa:47:26:14:30:0a:c4:c2:0b:
    > > 4c:b1:2f:15:cd:dc:79:79:a7:f0:2a:1f:15:c6:25:
    > > cb:61:84:20:27:4d:48:44:9a:f2:47:f9:c7:b5:09:
    > > db:d7:28:f5:28:2e:f2:cc:42:31:36:8a:95:dc:02:
    > > 22:39
    > > Exponent: 65537 (0x10001)
    > > X509v3 extensions:
    > > X509v3 Key Usage:
    > > Certificate Sign, CRL Sign
    > > X509v3 Subject Key Identifier:
    > > 74:9F:F6:2C:2B:60:80:53:17:79:A0:39:6D:77:84:FD:BA8:88:65
    > > X509v3 Basic Constraints: critical
    > > CA:TRUE
    > >
    > > On 8/14/08, Rafiqul Ahsan wrote:
    > > > Hi David,
    > > >
    > > > Thanks for your reply...I believe I am running Freeradius, and
    > > > openssl0.9.8h on 64 bit OS. If you want I can post the certs output as
    > > > well. Pls let me know. I need to make this working, and I have been
    > > > working on this for last 2 weeks and seeing the same error.
    > > >
    > > > Here is the command used to verify :
    > > >
    > > > bash-3.00# isainfo -b
    > > > 64
    > > > bash-3.00# isainfo -v
    > > > 64-bit sparcv9 applications
    > > > vis2 vis
    > > > 32-bit sparc applications
    > > > vis2 vis v8plus div32 mul32
    > > >
    > > > Here is the machine I am using (v210) :
    > > > bash-3.00# uname -a
    > > > SunOS v210ap20 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-V210
    > > >
    > > >
    > > > On 8/14/08, David Johnston wrote:
    > > > > We saw these same errors in a WiMAX test network with Free Radius.
    > > > >
    > > > > Moving from an older 32 bit Fedora to a current 64 bit Fedora and the stock
    > > > > freeradius and freeradius-util packages made it work and made the errors you
    > > > > exhibit disappear.
    > > > >
    > > > > openssl0.9.8h manifestly does support the necessary algorithms. With WiMAX
    > > > > certs (I assume from the logs, that is what you are using), you absolutely
    > > > > do need a 64 bit installation due to the post 2038 dates in the root and
    > > > > subordinate CA certs.
    > > > >
    > > > > DJ
    > > > >
    > > > >
    > > >
    > > >
    > > > --
    > > > Rafiqul Ahsan
    > > >

    > >
    > >

    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



    --
    Rafiqul Ahsan
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread