[RADIATOR] Can't get chain certificates to work
Hello, I'm currently running Radiator 4.7 on SUSE linux with OpenSSL 0.9.8h. I've had this running for years without any problems (albeit different versions). Now that I have to begin using Chain Certificates with my CA, I'm stuck. I know for a fact that the my private key and server certificate share the same modulus and exponent. The private key also works fine. I was also given all the correct CA and Chain certificates from Thawte, so I'm confident I'm OK there. The certificates work fine when installed on a Cisco ACS server. I also tried another set of certificates from Entrust, and received the same exact errors. The only way I can get this configuration to work with the new certificates is to use configuration #1, and not have the wireless client validate the server cert. Obviously, not a solution. Any help or suggestions are greatly appreciated. Configuration #1: EAPType TTLS EAPTLS_CertificateType PEM EAPTLS_CAFile %D/certificates/cert/thawte.Premium.Root.CA.pem #EAPTLS_CertificateChainFile %D/certificates/cert/thawte.SSL123bundle.pem [disabled] EAPTLS_CertificateFile %D/certificates/cert/wirelesscert.pem EAPTLS_PrivateKeyFile %D/certificates/cert/thawtekey.pem EAPTLS_PrivateKeyPassword I get this error, which I would expect to receive without a chain cert in the configuration and the client wanting to validate the server cert. Tue Nov 2 12:02:35 2010: DEBUG: EAP TTLS SSL_accept result: 0, 1, 8576 Tue Nov 2 12:02:35 2010: DEBUG: EAP result: 1, EAP TTLS Handshake unsuccessful: 23668: 1 - error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Tue Nov 2 12:02:35 2010: DEBUG: AuthBy FILE result: REJECT, EAP TTLS Handshake unsuccessful: 23668: 1 - error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Tue Nov 2 12:02:35 2010: INFO: Access rejected for tsd7notebook: EAP TTLS Handshake unsuccessful: 23668: 1 - error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Configuration #2: EAPType TTLS EAPTLS_CertificateType PEM EAPTLS_CAFile %D/certificates/cert/thawte.Premium.Root.CA.pem EAPTLS_CertificateChainFile %D/certificates/cert/thawte.SSL123bundle.pem [enabled] EAPTLS_CertificateFile %D/certificates/cert/wirelesscert.pem EAPTLS_PrivateKeyFile %D/certificates/cert/thawtekey.pem EAPTLS_PrivateKeyPassword I get this error: Tue Nov 2 12:03:58 2010: ERR: TLS could not use_PrivateKey_file %D/certificates/cert/thawtekey.pem, 1: 23681: 1 - error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch Thanks, Steve Stephen A Felicetti Fox Chase Cancer Center Director, Information Security stephen.felice...@fccc.edu 215-728-2956 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Can't get chain certificates to work
I had trouble getting this to work as well. The problem turned out to be the order of certificates in the chain. They usually come, from top to bottom in the file, root CA, signing CA, your cert. It looks like the way Radiator wants it is your cert, followed by the signing CA. Try reversing the order of certs in your file and see if it works. -- Andrew Clark On Thursday, November 04, 2010 07:30:42 am Stephen A. Felicetti wrote: > Hello, > > I'm currently running Radiator 4.7 on SUSE linux with OpenSSL 0.9.8h. > I've had this running for years without any problems (albeit different > versions). Now that I have to begin using Chain Certificates with my CA, > I'm stuck. I know for a fact that the my private key and server > certificate share the same modulus and exponent. The private key also > works fine. I was also given all the correct CA and Chain certificates > from Thawte, so I'm confident I'm OK there. The certificates work fine > when installed on a Cisco ACS server. > I also tried another set of certificates from Entrust, and received the > same exact errors. The only way I can get this configuration to work with > the new certificates is to use configuration #1, and not have the wireless > client validate the server cert. Obviously, not a solution. > > Any help or suggestions are greatly appreciated. > > Configuration #1: > > EAPType TTLS > EAPTLS_CertificateType PEM > EAPTLS_CAFile %D/certificates/cert/thawte.Premium.Root.CA.pem > #EAPTLS_CertificateChainFile %D/certificates/cert/thawte.SSL123bundle.pem > [disabled] EAPTLS_CertificateFile %D/certificates/cert/wirelesscert.pem > EAPTLS_PrivateKeyFile %D/certificates/cert/thawtekey.pem > EAPTLS_PrivateKeyPassword > > I get this error, which I would expect to receive without a chain cert in > the configuration and the client wanting to validate the server cert. > > Tue Nov 2 12:02:35 2010: DEBUG: EAP TTLS SSL_accept result: 0, 1, 8576 > Tue Nov 2 12:02:35 2010: DEBUG: EAP result: 1, EAP TTLS Handshake > unsuccessful: 23668: 1 - error:14094418:SSL > routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Tue Nov 2 12:02:35 2010: > DEBUG: AuthBy FILE result: REJECT, EAP TTLS Handshake unsuccessful: > 23668: 1 - error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown > ca Tue Nov 2 12:02:35 2010: INFO: Access rejected for tsd7notebook: EAP > TTLS Handshake unsuccessful: 23668: 1 - error:14094418:SSL > routines:SSL3_READ_BYTES:tlsv1 alert unknown ca > > > > Configuration #2: > > EAPType TTLS > EAPTLS_CertificateType PEM > EAPTLS_CAFile %D/certificates/cert/thawte.Premium.Root.CA.pem > EAPTLS_CertificateChainFile %D/certificates/cert/thawte.SSL123bundle.pem > [enabled] EAPTLS_CertificateFile %D/certificates/cert/wirelesscert.pem > EAPTLS_PrivateKeyFile %D/certificates/cert/thawtekey.pem > EAPTLS_PrivateKeyPassword > > I get this error: > > Tue Nov 2 12:03:58 2010: ERR: TLS could not use_PrivateKey_file > %D/certificates/cert/thawtekey.pem, 1: 23681: 1 - error:0B080074:x509 > certificate routines:X509_check_private_key:key values mismatch > > > Thanks, > Steve > > Stephen A Felicetti > Fox Chase Cancer Center > Director, Information Security > stephen.felice...@fccc.edu > 215-728-2956 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Can't get chain certificates to work
Thanks for the response. But, I continue to get the "X509_check_private_key:key values mismatch" anytime I use the certificatechain configuration line. I've tried many combinations of certificates in the file, with all the same results. On Nov 4, 2010, at 12:50 PM, Andrew D. Clark wrote: I had trouble getting this to work as well. The problem turned out to be the order of certificates in the chain. They usually come, from top to bottom in the file, root CA, signing CA, your cert. It looks like the way Radiator wants it is your cert, followed by the signing CA. Try reversing the order of certs in your file and see if it works. -- Andrew Clark On Thursday, November 04, 2010 07:30:42 am Stephen A. Felicetti wrote: > Hello, > > I'm currently running Radiator 4.7 on SUSE linux with OpenSSL 0.9.8h. > I've had this running for years without any problems (albeit different > versions). Now that I have to begin using Chain Certificates with my CA, > I'm stuck. I know for a fact that the my private key and server > certificate share the same modulus and exponent. The private key also > works fine. I was also given all the correct CA and Chain certificates > from Thawte, so I'm confident I'm OK there. The certificates work fine > when installed on a Cisco ACS server. > I also tried another set of certificates from Entrust, and received the > same exact errors. The only way I can get this configuration to work with > the new certificates is to use configuration #1, and not have the wireless > client validate the server cert. Obviously, not a solution. > > Any help or suggestions are greatly appreciated. > > Configuration #1: > > EAPType TTLS > EAPTLS_CertificateType PEM > EAPTLS_CAFile %D/certificates/cert/thawte.Premium.Root.CA.pem > #EAPTLS_CertificateChainFile %D/certificates/cert/thawte.SSL123bundle.pem > [disabled] EAPTLS_CertificateFile %D/certificates/cert/wirelesscert.pem > EAPTLS_PrivateKeyFile %D/certificates/cert/thawtekey.pem > EAPTLS_PrivateKeyPassword > > I get this error, which I would expect to receive without a chain cert in > the configuration and the client wanting to validate the server cert. > > Tue Nov 2 12:02:35 2010: DEBUG: EAP TTLS SSL_accept result: 0, 1, 8576 > Tue Nov 2 12:02:35 2010: DEBUG: EAP result: 1, EAP TTLS Handshake > unsuccessful: 23668: 1 - error:14094418:SSL > routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Tue Nov 2 12:02:35 2010: > DEBUG: AuthBy FILE result: REJECT, EAP TTLS Handshake unsuccessful: > 23668: 1 - error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown > ca Tue Nov 2 12:02:35 2010: INFO: Access rejected for tsd7notebook: EAP > TTLS Handshake unsuccessful: 23668: 1 - error:14094418:SSL > routines:SSL3_READ_BYTES:tlsv1 alert unknown ca > > > > Configuration #2: > > EAPType TTLS > EAPTLS_CertificateType PEM > EAPTLS_CAFile %D/certificates/cert/thawte.Premium.Root.CA.pem > EAPTLS_CertificateChainFile %D/certificates/cert/thawte.SSL123bundle.pem > [enabled] EAPTLS_CertificateFile %D/certificates/cert/wirelesscert.pem > EAPTLS_PrivateKeyFile %D/certificates/cert/thawtekey.pem > EAPTLS_PrivateKeyPassword > > I get this error: > > Tue Nov 2 12:03:58 2010: ERR: TLS could not use_PrivateKey_file > %D/certificates/cert/thawtekey.pem, 1: 23681: 1 - error:0B080074:x509 > certificate routines:X509_check_private_key:key values mismatch > > > Thanks, > Steve > > Stephen A Felicetti > Fox Chase Cancer Center > Director, Information Security > stephen.felice...@fccc.edu > 215-728-2956 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Can't get chain certificates to work
> EAPType TTLS > EAPTLS_CertificateType PEM > EAPTLS_CAFile %D/certificates/cert/thawte.Premium.Root.CA.pem > EAPTLS_CertificateChainFile %D/certificates/cert/thawte.SSL123bundle.pem > [enabled] > EAPTLS_CertificateFile %D/certificates/cert/wirelesscert.pem > EAPTLS_PrivateKeyFile %D/certificates/cert/thawtekey.pem > EAPTLS_PrivateKeyPassword > > I get this error: > > Tue Nov 2 12:03:58 2010: ERR: TLS could not use_PrivateKey_file > %D/certificates/cert/thawtekey.pem, 1: 23681: 1 - error:0B080074:x509 > certificate routines:X509_check_private_key:key values mismatch I fought with this same issue and eventually discovered that the Radiator documentation is misleading: including both an EAPTLS_CertificateFile (for the server cert) and an EAPTLS_CertificateChainFile (for the intermediate cert) does not work because the underlying call to SSL_CTX_use_certificate_chain_file() expects a *single* file that contains *all* of the necessary certs. The error you're seeing now indicates that your private key doesn't match the first cert in thawte.SSL123bundle.pem. What you want to do is put them all in one file with yours on top: cat wirelesscert.pem thawte.SSL123bundle.pem > fullchain.pem and specify: EAPTLS_CertificateChainFile %D/certificates/cert/fullchain.pem (do not include an EAPTLS_CertificateFile directive) Hope this helps. David ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] WLAN EAP-TLS auth issue
That solved it. Why is this not the default ?
Thank you
Markus
- Original Message -
From: "Sami Keski-Kasari"
To: "Markus Moeller" ;
Sent: Wednesday, November 03, 2010 9:07 PM
Subject: Re: [RADIATOR] WLAN EAP-TLS auth issue
> Have you tried EAPTLS_SessionResumption 0?
>
> --
> Sami
>
> "Markus Moeller" wrote:
>
>>BTW I use version 4.7.
>> - Original Message -
>> From: Markus Moeller
>> To: radiator@open.com.au
>> Sent: Wednesday, November 03, 2010 8:04 PM
>> Subject: WLAN EAP-TLS auth issue
>>
>>
>> Hi
>>
>>I am testing EAP-TLS auth with Radiator and came across the following.
>>I have two SSIDs SSID-1 and SSID-2 and want to restrict access to
>>SSID-1, SSID-2 based on the certificate issue. e.g. on SSID-1 I allow
>>certs from issue COMP-A and on SSID2 from COMP-B. What I notice is that
>>once a user lets say authenticates to SSID-1 successfully and the
>>disconnects and connects to SSID-2 the EAPTLS Hook is not called (see
>>log example). I also see the the server is not sending the CA to the
>>client. Can it be that it is not seen as a new session ?
>>
>>I have the following configuration.
>>
>>
>> # EAPTLS authentication
>>
>>Identifier EapTLS
>># the file is used to check usernames (assuming EAP-TLS certificate
>>checks pass): just contains DEFAULT
>>Filename %D/wlan_users
>>EAPType TLS
>># WLAN Additional Certificate Check
>>EAPTLS_CertificateVerifyHook file:"%D/cert_check.pl"
>># WLAN root CAs
>>EAPTLS_CAFile %D/certs/CAa.pem
>>
>>EAPTLS_CertificateType PEM
>># Radiator Cert
>>EAPTLS_CertificateFile %D/certs/server_cert.pem
>># Radiator private key
>>EAPTLS_PrivateKeyFile %D/certs/server_cert.key
>>
>>EAPTLS_MaxFragmentSize 1000
>>
>>EAPTLS_CRLCheck
>>EAPTLS_CRLFile %D/certs/crls/Root_CA.pem
>>
>>AutoMPPEKeys
>>
>>
>>
>>
>> sub {
>>
>>use Crypt::OpenSSL::X509;
>>&main::log($main::LOG_DEBUG,"cert_check: enter hook");
>>
>># Pointer to request structure
>>my $p0 = $_[0];# $matchdn
>>my $p1 = $_[1];# $x509_store_ctx
>>my $p2 = $_[2];# $cert
>>my $p3 = $_[3];# $subject_name
>>my $p4 = $_[4];# $subject
>>my $p = $_[5]; # $p Radius Request
>>
>>my $issuer_name =
>>&Net::SSLeay::X509_NAME_oneline(&Net::SSLeay::X509_get_issuer_name($p2));
>>
>>my $x509 =
>>Crypt::OpenSSL::X509->new_from_string(&Net::SSLeay::PEM_get_string_X509($p2));
>>my $extensions = &Crypt::OpenSSL::X509::extensions_by_name($x509);
>>
>>my @extendedKeyUsage =
>>&Crypt::OpenSSL::X509::Extension::extKeyUsage($extensions->{extendedKeyUsage});
>>
>> my $eku_req_client_auth = grep { /clientAuth/ } ( @extendedKeyUsage );
>>my $eku_req_client_any = grep { /anyExtendedKeyUsage/ } (
>>@extendedKeyUsage );
>>
>>
>>&main::log($main::LOG_DEBUG,"cert_check: matchDN: $p0");
>>&main::log($main::LOG_DEBUG,"cert_check: issuer: $issuer_name");
>>&main::log($main::LOG_DEBUG,"cert_check: Extended Key Usage strings
>>found in certificate: " . (join " & ", @extendedKeyUsage) );
>>
>># User certificate CA strings:
>>user_CA = 'CN=User CA, OU=Test, C=UK';
>>
>># bail out if cannot determine the extendedKeyUsage for this
>>certificate:
>>if ( $eku_req_client_auth == 0 && $eku_req_client_any == 0 ) {
>>&main::log($main::LOG_ERR,"cert_check: certificate presented does not
>>have required values present in Extended Key Usage field.");
>>return undef;
>>}
>>
>># test each issuer string (which is valid for this ssid) against
>># the issuer string in the certificate in the request:
>>my $match = 0;
>>
>>if ($issuer_name =~ /^$user_CA$/) {
>>$match++;
>>&main::log($main::LOG_DEBUG,"cert_check: Successful match for
>>issuer_name [$issuer_name] with issuer_string [$user_CA]");
>>}
>>
>>
>>if ( $match == 0 ) {
>>&main::log($main::LOG_ERR,"cert_check: invalid certificate issuer
>>[$issuer_name] in request.");
>> return undef;
>>}
>>
>> }
>>
>>
>> Wed Nov 3 09:32:20 2010: DEBUG: Packet dump:
>> *** Received from 191.169.1.21 port 32768
>> Code: Access-Request
>> Identifier: 153
>> Authentic: +R<20><209><177><167>5/<246>y%<135><133><134><191><173>
>> Attributes:
>> User-Name = "us...@test.uk"
>> Calling-Station-Id = "00-22-fa-aa-bb-cc"
>> Called-Station-Id = "00-1a-e3-ab-cd-ed:SSID-1"
>> NAS-Port = 29
>> NAS-IP-Address = 191.169.1.21
>> NAS-Identifier = "Controller1"
>> Airespace-WLAN-Id = 7
>> Service-Type = Framed-User
>> Framed-MTU = 1300
>> NAS-Port-Type = Wireless-IEEE-802-11
>> Tunnel-Type = 0:VLAN
>> Tunnel-Medium-Type = 0:802
>> Tunnel-Private-Group-ID = 662
>> EAP-Message = <2><3><0><18><1>us...@test.uk
>>Message-Authenticator =
>>L><159><3>4<221><139>8<214>g<237><153><22>v<200><197>
>>
>>Wed Nov 3 09:32:20 2010: DEBUG: Handling request with Handler
>>'DeviceClass="WLAN"'
>>Wed Nov
Re: [RADIATOR] Can't get chain certificates to work
If I exclude the EAPTLS_CAFile, I get the following error: Thu Nov 4 16:06:42 2010: ERR: TLS could not load_verify_locations , : Thu Nov 4 16:06:42 2010: DEBUG: EAP result: 1, EAP TTLS Could not initialise context Thu Nov 4 16:06:42 2010: DEBUG: AuthBy FILE result: REJECT, EAP TTLS Could not initialise context Thu Nov 4 16:06:42 2010: INFO: Access rejected for fistrainlap8: EAP TTLS Could not initialise context Thanks, Steve On Nov 4, 2010, at 3:32 PM, David Zych wrote: > EAPType TTLS > EAPTLS_CertificateType PEM > EAPTLS_CAFile %D/certificates/cert/thawte.Premium.Root.CA.pem > EAPTLS_CertificateChainFile %D/certificates/cert/thawte.SSL123bundle.pem > [enabled] > EAPTLS_CertificateFile %D/certificates/cert/wirelesscert.pem > EAPTLS_PrivateKeyFile %D/certificates/cert/thawtekey.pem > EAPTLS_PrivateKeyPassword > > I get this error: > > Tue Nov 2 12:03:58 2010: ERR: TLS could not use_PrivateKey_file > %D/certificates/cert/thawtekey.pem, 1: 23681: 1 - error:0B080074:x509 > certificate routines:X509_check_private_key:key values mismatch I fought with this same issue and eventually discovered that the Radiator documentation is misleading: including both an EAPTLS_CertificateFile (for the server cert) and an EAPTLS_CertificateChainFile (for the intermediate cert) does not work because the underlying call to SSL_CTX_use_certificate_chain_file() expects a *single* file that contains *all* of the necessary certs. The error you're seeing now indicates that your private key doesn't match the first cert in thawte.SSL123bundle.pem. What you want to do is put them all in one file with yours on top: cat wirelesscert.pem thawte.SSL123bundle.pem > fullchain.pem and specify: EAPTLS_CertificateChainFile %D/certificates/cert/fullchain.pem (do not include an EAPTLS_CertificateFile directive) Hope this helps. David ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Can't get chain certificates to work
On 1:59 PM, Stephen A. Felicetti wrote: > On Nov 4, 2010, at 3:32 PM, David Zych wrote: >> >> I fought with this same issue and eventually discovered that the >> Radiator documentation is misleading: including both an >> EAPTLS_CertificateFile (for the server cert) and an >> EAPTLS_CertificateChainFile (for the intermediate cert) does not work >> because the underlying call to SSL_CTX_use_certificate_chain_file() >> expects a *single* file that contains *all* of the necessary certs. >> >> What you want to do is put them all in one file with yours on top: >> cat wirelesscert.pem thawte.SSL123bundle.pem > fullchain.pem >> >> and specify: >> EAPTLS_CertificateChainFile %D/certificates/cert/fullchain.pem >> >> (do not include an EAPTLS_CertificateFile directive) > > If I exclude the EAPTLS_CAFile, I get the following error: > > Thu Nov 4 16:06:42 2010: ERR: TLS could not load_verify_locations , : > Thu Nov 4 16:06:42 2010: DEBUG: EAP result: 1, EAP TTLS Could not initialise > context > Thu Nov 4 16:06:42 2010: DEBUG: AuthBy FILE result: REJECT, EAP TTLS Could > not initialise context > Thu Nov 4 16:06:42 2010: INFO: Access rejected for fistrainlap8: EAP TTLS > Could not initialise context You still need to specify either a EAPTLS_CAFile or EAPTLS_CAPath (it doesn't really mean much if you're not using client certs, but as you've just discovered, TTLS can't initialize without the declaration). ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] WLAN EAP-TLS auth issue
Hello Markus -
Because most people want it enabled.
regards
Hugh
On 5 Nov 2010, at 06:45, Markus Moeller wrote:
> That solved it. Why is this not the default ?
>
> Thank you
> Markus
>
> - Original Message -
> From: "Sami Keski-Kasari"
> To: "Markus Moeller" ;
> Sent: Wednesday, November 03, 2010 9:07 PM
> Subject: Re: [RADIATOR] WLAN EAP-TLS auth issue
>
>
>> Have you tried EAPTLS_SessionResumption 0?
>>
>> --
>> Sami
>>
>> "Markus Moeller" wrote:
>>
>>> BTW I use version 4.7.
>>> - Original Message -
>>> From: Markus Moeller
>>> To: radiator@open.com.au
>>> Sent: Wednesday, November 03, 2010 8:04 PM
>>> Subject: WLAN EAP-TLS auth issue
>>>
>>>
>>> Hi
>>>
>>> I am testing EAP-TLS auth with Radiator and came across the following.
>>> I have two SSIDs SSID-1 and SSID-2 and want to restrict access to
>>> SSID-1, SSID-2 based on the certificate issue. e.g. on SSID-1 I allow
>>> certs from issue COMP-A and on SSID2 from COMP-B. What I notice is that
>>> once a user lets say authenticates to SSID-1 successfully and the
>>> disconnects and connects to SSID-2 the EAPTLS Hook is not called (see
>>> log example). I also see the the server is not sending the CA to the
>>> client. Can it be that it is not seen as a new session ?
>>>
>>> I have the following configuration.
>>>
>>>
>>> # EAPTLS authentication
>>>
>>> Identifier EapTLS
>>> # the file is used to check usernames (assuming EAP-TLS certificate
>>> checks pass): just contains DEFAULT
>>> Filename %D/wlan_users
>>> EAPType TLS
>>> # WLAN Additional Certificate Check
>>> EAPTLS_CertificateVerifyHook file:"%D/cert_check.pl"
>>> # WLAN root CAs
>>> EAPTLS_CAFile %D/certs/CAa.pem
>>>
>>> EAPTLS_CertificateType PEM
>>> # Radiator Cert
>>> EAPTLS_CertificateFile %D/certs/server_cert.pem
>>> # Radiator private key
>>> EAPTLS_PrivateKeyFile %D/certs/server_cert.key
>>>
>>> EAPTLS_MaxFragmentSize 1000
>>>
>>> EAPTLS_CRLCheck
>>> EAPTLS_CRLFile %D/certs/crls/Root_CA.pem
>>>
>>> AutoMPPEKeys
>>>
>>>
>>>
>>>
>>> sub {
>>>
>>> use Crypt::OpenSSL::X509;
>>> &main::log($main::LOG_DEBUG,"cert_check: enter hook");
>>>
>>> # Pointer to request structure
>>> my $p0 = $_[0];# $matchdn
>>> my $p1 = $_[1];# $x509_store_ctx
>>> my $p2 = $_[2];# $cert
>>> my $p3 = $_[3];# $subject_name
>>> my $p4 = $_[4];# $subject
>>> my $p = $_[5]; # $p Radius Request
>>>
>>> my $issuer_name =
>>> &Net::SSLeay::X509_NAME_oneline(&Net::SSLeay::X509_get_issuer_name($p2));
>>>
>>> my $x509 =
>>> Crypt::OpenSSL::X509->new_from_string(&Net::SSLeay::PEM_get_string_X509($p2));
>>> my $extensions = &Crypt::OpenSSL::X509::extensions_by_name($x509);
>>>
>>> my @extendedKeyUsage =
>>> &Crypt::OpenSSL::X509::Extension::extKeyUsage($extensions->{extendedKeyUsage});
>>>
>>> my $eku_req_client_auth = grep { /clientAuth/ } ( @extendedKeyUsage );
>>> my $eku_req_client_any = grep { /anyExtendedKeyUsage/ } (
>>> @extendedKeyUsage );
>>>
>>>
>>> &main::log($main::LOG_DEBUG,"cert_check: matchDN: $p0");
>>> &main::log($main::LOG_DEBUG,"cert_check: issuer: $issuer_name");
>>> &main::log($main::LOG_DEBUG,"cert_check: Extended Key Usage strings
>>> found in certificate: " . (join " & ", @extendedKeyUsage) );
>>>
>>> # User certificate CA strings:
>>> user_CA = 'CN=User CA, OU=Test, C=UK';
>>>
>>> # bail out if cannot determine the extendedKeyUsage for this
>>> certificate:
>>> if ( $eku_req_client_auth == 0 && $eku_req_client_any == 0 ) {
>>> &main::log($main::LOG_ERR,"cert_check: certificate presented does not
>>> have required values present in Extended Key Usage field.");
>>> return undef;
>>> }
>>>
>>> # test each issuer string (which is valid for this ssid) against
>>> # the issuer string in the certificate in the request:
>>> my $match = 0;
>>>
>>> if ($issuer_name =~ /^$user_CA$/) {
>>> $match++;
>>> &main::log($main::LOG_DEBUG,"cert_check: Successful match for
>>> issuer_name [$issuer_name] with issuer_string [$user_CA]");
>>> }
>>>
>>>
>>> if ( $match == 0 ) {
>>> &main::log($main::LOG_ERR,"cert_check: invalid certificate issuer
>>> [$issuer_name] in request.");
>>> return undef;
>>> }
>>>
>>> }
>>>
>>>
>>> Wed Nov 3 09:32:20 2010: DEBUG: Packet dump:
>>> *** Received from 191.169.1.21 port 32768
>>> Code: Access-Request
>>> Identifier: 153
>>> Authentic: +R<20><209><177><167>5/<246>y%<135><133><134><191><173>
>>> Attributes:
>>> User-Name = "us...@test.uk"
>>> Calling-Station-Id = "00-22-fa-aa-bb-cc"
>>> Called-Station-Id = "00-1a-e3-ab-cd-ed:SSID-1"
>>> NAS-Port = 29
>>> NAS-IP-Address = 191.169.1.21
>>> NAS-Identifier = "Controller1"
>>> Airespace-WLAN-Id = 7
>>> Service-Type = Framed-User
>>> Framed-MTU = 1300
>>> NAS-Port-Type = Wireless-IEEE-802-11
>>> Tunnel-Type = 0:VLAN
>>> Tunnel-Medium-Type = 0:802
>>>
Re: [RADIATOR] WLAN EAP-TLS auth issue
Ok. Fair point.
Thank you
Markus
- Original Message -
From: "Hugh Irvine"
To: "Markus Moeller"
Cc: "Sami Keski-Kasari" ;
Sent: Thursday, November 04, 2010 10:35 PM
Subject: Re: [RADIATOR] WLAN EAP-TLS auth issue
Hello Markus -
Because most people want it enabled.
regards
Hugh
On 5 Nov 2010, at 06:45, Markus Moeller wrote:
> That solved it. Why is this not the default ?
>
> Thank you
> Markus
>
> - Original Message -
> From: "Sami Keski-Kasari"
> To: "Markus Moeller" ;
> Sent: Wednesday, November 03, 2010 9:07 PM
> Subject: Re: [RADIATOR] WLAN EAP-TLS auth issue
>
>
>> Have you tried EAPTLS_SessionResumption 0?
>>
>> --
>> Sami
>>
>> "Markus Moeller" wrote:
>>
>>> BTW I use version 4.7.
>>> - Original Message -
>>> From: Markus Moeller
>>> To: radiator@open.com.au
>>> Sent: Wednesday, November 03, 2010 8:04 PM
>>> Subject: WLAN EAP-TLS auth issue
>>>
>>>
>>> Hi
>>>
>>> I am testing EAP-TLS auth with Radiator and came across the following.
>>> I have two SSIDs SSID-1 and SSID-2 and want to restrict access to
>>> SSID-1, SSID-2 based on the certificate issue. e.g. on SSID-1 I allow
>>> certs from issue COMP-A and on SSID2 from COMP-B. What I notice is that
>>> once a user lets say authenticates to SSID-1 successfully and the
>>> disconnects and connects to SSID-2 the EAPTLS Hook is not called (see
>>> log example). I also see the the server is not sending the CA to the
>>> client. Can it be that it is not seen as a new session ?
>>>
>>> I have the following configuration.
>>>
>>>
>>> # EAPTLS authentication
>>>
>>> Identifier EapTLS
>>> # the file is used to check usernames (assuming EAP-TLS certificate
>>> checks pass): just contains DEFAULT
>>> Filename %D/wlan_users
>>> EAPType TLS
>>> # WLAN Additional Certificate Check
>>> EAPTLS_CertificateVerifyHook file:"%D/cert_check.pl"
>>> # WLAN root CAs
>>> EAPTLS_CAFile %D/certs/CAa.pem
>>>
>>> EAPTLS_CertificateType PEM
>>> # Radiator Cert
>>> EAPTLS_CertificateFile %D/certs/server_cert.pem
>>> # Radiator private key
>>> EAPTLS_PrivateKeyFile %D/certs/server_cert.key
>>>
>>> EAPTLS_MaxFragmentSize 1000
>>>
>>> EAPTLS_CRLCheck
>>> EAPTLS_CRLFile %D/certs/crls/Root_CA.pem
>>>
>>> AutoMPPEKeys
>>>
>>>
>>>
>>>
>>> sub {
>>>
>>> use Crypt::OpenSSL::X509;
>>> &main::log($main::LOG_DEBUG,"cert_check: enter hook");
>>>
>>> # Pointer to request structure
>>> my $p0 = $_[0];# $matchdn
>>> my $p1 = $_[1];# $x509_store_ctx
>>> my $p2 = $_[2];# $cert
>>> my $p3 = $_[3];# $subject_name
>>> my $p4 = $_[4];# $subject
>>> my $p = $_[5]; # $p Radius Request
>>>
>>> my $issuer_name =
>>> &Net::SSLeay::X509_NAME_oneline(&Net::SSLeay::X509_get_issuer_name($p2));
>>>
>>> my $x509 =
>>> Crypt::OpenSSL::X509->new_from_string(&Net::SSLeay::PEM_get_string_X509($p2));
>>> my $extensions = &Crypt::OpenSSL::X509::extensions_by_name($x509);
>>>
>>> my @extendedKeyUsage =
>>> &Crypt::OpenSSL::X509::Extension::extKeyUsage($extensions->{extendedKeyUsage});
>>>
>>> my $eku_req_client_auth = grep { /clientAuth/ } ( @extendedKeyUsage );
>>> my $eku_req_client_any = grep { /anyExtendedKeyUsage/ } (
>>> @extendedKeyUsage );
>>>
>>>
>>> &main::log($main::LOG_DEBUG,"cert_check: matchDN: $p0");
>>> &main::log($main::LOG_DEBUG,"cert_check: issuer: $issuer_name");
>>> &main::log($main::LOG_DEBUG,"cert_check: Extended Key Usage strings
>>> found in certificate: " . (join " & ", @extendedKeyUsage) );
>>>
>>> # User certificate CA strings:
>>> user_CA = 'CN=User CA, OU=Test, C=UK';
>>>
>>> # bail out if cannot determine the extendedKeyUsage for this
>>> certificate:
>>> if ( $eku_req_client_auth == 0 && $eku_req_client_any == 0 ) {
>>> &main::log($main::LOG_ERR,"cert_check: certificate presented does not
>>> have required values present in Extended Key Usage field.");
>>> return undef;
>>> }
>>>
>>> # test each issuer string (which is valid for this ssid) against
>>> # the issuer string in the certificate in the request:
>>> my $match = 0;
>>>
>>> if ($issuer_name =~ /^$user_CA$/) {
>>> $match++;
>>> &main::log($main::LOG_DEBUG,"cert_check: Successful match for
>>> issuer_name [$issuer_name] with issuer_string [$user_CA]");
>>> }
>>>
>>>
>>> if ( $match == 0 ) {
>>> &main::log($main::LOG_ERR,"cert_check: invalid certificate issuer
>>> [$issuer_name] in request.");
>>> return undef;
>>> }
>>>
>>> }
>>>
>>>
>>> Wed Nov 3 09:32:20 2010: DEBUG: Packet dump:
>>> *** Received from 191.169.1.21 port 32768
>>> Code: Access-Request
>>> Identifier: 153
>>> Authentic: +R<20><209><177><167>5/<246>y%<135><133><134><191><173>
>>> Attributes:
>>> User-Name = "us...@test.uk"
>>> Calling-Station-Id = "00-22-fa-aa-bb-cc"
>>> Called-Station-Id = "00-1a-e3-ab-cd-ed:SSID-1"
>>> NAS-Port = 29
>>> NAS-IP-Address = 191.169.1.21
>>> NAS-Identifier = "Controller1"
>>> Airespace-WLAN-Id = 7
>>>
