802.1x with GoDaddy Certificates EAP-TTLS
I have a little question. I am not sure but does clients need to resolve AAA Server via DNS and need to reach AAA Server if I use EAP-TTLS with GoDaddy x509 Certificates to verify the certificate on e.g. Mobile Devices or does the client need in any other case to reach some endpoint to validate the certificates common name? I have a AAA Server in a separate Network installed which is only reachable for the authenticator (Wireless Controller). The Clients communicate with the AccessPoint. A hand full devices like Android are not able to connect the wireless because of certificate validation error. The other devices has no problems. You see the certificate of the server and after accept, the connection will be established. The AAA Server sends the full chain like RootCA, Intermediate and server certificate. BR. Torsten
On Jun 29, 2023, at 10:27 AM, Torsten Wilms via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I have a little question. I am not sure but does clients need to resolve AAA Server via DNS and need to reach AAA Server if I use EAP-TTLS with GoDaddy x509 Certificates to verify the certificate on e.g. Mobile Devices or does the client need in any other case to reach some endpoint to validate the certificates common name?
No.
I have a AAA Server in a separate Network installed which is only reachable for the authenticator (Wireless Controller). The Clients communicate with the AccessPoint. A hand full devices like Android are not able to connect the wireless because of certificate validation error. The other devices has no problems. You see the certificate of the server and after accept, the connection will be established. The AAA Server sends the full chain like RootCA, Intermediate and server certificate. BR. Torsten
The supplicant has not been configured with the root CA used by the server. This has to be done in order for the supplicant to trust the root CA. The EAP-TLS connection does *not* send the root CA in the certificate chain. Even if it did, there is no reason for the supplicant to trust some random root CA it gets from a RADIUS server. Alan DeKok.
Ok. But we use a GoDaddy G2 certificate. And the supplicant must have the root CA, because if not, the device would not to be able to validate any GoDaddy certificate in the browser ssl connection. Or am I thinking wrong?
I have a little question. I am not sure but does clients need to resolve AAA Server via DNS and need to reach AAA Server if I use EAP-TTLS with GoDaddy x509 Certificates to verify the certificate on e.g. Mobile Devices or does the client need in any other case to reach some endpoint to validate the certificates common name?
No.
I have a AAA Server in a separate Network installed which is only reachable for the authenticator (Wireless Controller). The Clients communicate with the AccessPoint. A hand full devices like Android are not able to connect the wireless because of certificate validation error. The other devices has no problems. You see the certificate of the server and after accept, the connection will be established. The AAA Server sends the full chain like RootCA, Intermediate and server certificate. BR. Torsten
The supplicant has not been configured with the root CA used by the server. This has to be done in order for the supplicant to trust the root CA. The EAP-TLS connection does *not* send the root CA in the certificate chain. Even if it did, there is no reason for the supplicant to trust some random root CA it gets from a RADIUS server. Alan DeKok.
The idea behind using a public certificate is that anyone can connect to the WLAN without a certificate error if the username and password are correct Ok. But we use a GoDaddy G2 certificate. And the supplicant must have the root CA, because if not, the device would not to be able to validate any GoDaddy certificate in the browser ssl connection. Or am I thinking wrong?
I have a little question. I am not sure but does clients need to resolve AAA Server via DNS and need to reach AAA Server if I use EAP-TTLS with GoDaddy x509 Certificates to verify the certificate on e.g. Mobile Devices or does the client need in any other case to reach some endpoint to validate the certificates common name?
No.
I have a AAA Server in a separate Network installed which is only reachable for the authenticator (Wireless Controller). The Clients communicate with the AccessPoint. A hand full devices like Android are not able to connect the wireless because of certificate validation error. The other devices has no problems. You see the certificate of the server and after accept, the connection will be established. The AAA Server sends the full chain like RootCA, Intermediate and server certificate. BR. Torsten
The supplicant has not been configured with the root CA used by the server. This has to be done in order for the supplicant to trust the root CA. The EAP-TLS connection does *not* send the root CA in the certificate chain. Even if it did, there is no reason for the supplicant to trust some random root CA it gets from a RADIUS server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 29, 2023, at 10:58 AM, Torsten Wilms via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
The idea behind using a public certificate is that anyone can connect to the WLAN without a certificate error if the username and password are correct
That's a nice wish. But it's just a wish. It is entirely unrelated to the real world. If you don't like this, then please convince the standards bodies, Microsoft, Cisco, Google etc. to configure the systems the way you want, and not the way they work today. You can't magically wish functionality into existence. If the systems don't work the way you want, you either live with that limitation, or you spend years at standards bodies trying to fix it. Alan DeKok.
That was really very nicely put. Understood. Thank you very much for your time
On Jun 29, 2023, at 10:58 AM, Torsten Wilms via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
The idea behind using a public certificate is that anyone can connect to the WLAN without a certificate error if the username and password are correct
That's a nice wish. But it's just a wish. It is entirely unrelated to the real world. If you don't like this, then please convince the standards bodies, Microsoft, Cisco, Google etc. to configure the systems the way you want, and not the way they work today. You can't magically wish functionality into existence. If the systems don't work the way you want, you either live with that limitation, or you spend years at standards bodies trying to fix it. Alan DeKok.
Hi Torsten, I have a very similar issue with radius assigned VLAN multi-tenant building networks - so far it is only Google phones that have stopped working with our 802.1x SSID and I have to put them on a MAC auth SSID instead which used to only be used for printers and other devices not supporting 802.1X - and obviously privacy MAC has to be disabled as well. I suspect many other Android devices will probably follow suit soon. I know we could implement an onboarding system but the landlord is not going to pay for that. Paul Bone -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+paul.bone=probitas-solutions.tech@lists.freeradius.org> On Behalf Of Torsten Wilms via Freeradius-Users Sent: Thursday, June 29, 2023 4:04 PM To: Alan DeKok <aland@deployingradius.com>; FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Torsten Wilms <T.Wilms@m3connect.de> Subject: Re: 802.1x with GoDaddy Certificates EAP-TTLS That was really very nicely put. Understood. Thank you very much for your time
On Jun 29, 2023, at 10:58 AM, Torsten Wilms via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
The idea behind using a public certificate is that anyone can connect to the WLAN without a certificate error if the username and password are correct
That's a nice wish. But it's just a wish. It is entirely unrelated to the real world. If you don't like this, then please convince the standards bodies, Microsoft, Cisco, Google etc. to configure the systems the way you want, and not the way they work today. You can't magically wish functionality into existence. If the systems don't work the way you want, you either live with that limitation, or you spend years at standards bodies trying to fix it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Paul and Alan, Many many thanks for your answers. BR. Torsten! Hi Torsten, I have a very similar issue with radius assigned VLAN multi-tenant building networks - so far it is only Google phones that have stopped working with our 802.1x SSID and I have to put them on a MAC auth SSID instead which used to only be used for printers and other devices not supporting 802.1X - and obviously privacy MAC has to be disabled as well. I suspect many other Android devices will probably follow suit soon. I know we could implement an onboarding system but the landlord is not going to pay for that. Paul Bone -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+paul.bone=probitas-solutions.tech@lists.freeradius.org> On Behalf Of Torsten Wilms via Freeradius-Users Sent: Thursday, June 29, 2023 4:04 PM To: Alan DeKok <aland@deployingradius.com>; FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Torsten Wilms <T.Wilms@m3connect.de> Subject: Re: 802.1x with GoDaddy Certificates EAP-TTLS That was really very nicely put. Understood. Thank you very much for your time
On Jun 29, 2023, at 10:58 AM, Torsten Wilms via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
The idea behind using a public certificate is that anyone can connect to the WLAN without a certificate error if the username and password are correct
That's a nice wish. But it's just a wish. It is entirely unrelated to the real world. If you don't like this, then please convince the standards bodies, Microsoft, Cisco, Google etc. to configure the systems the way you want, and not the way they work today. You can't magically wish functionality into existence. If the systems don't work the way you want, you either live with that limitation, or you spend years at standards bodies trying to fix it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 29, 2023, at 11:18 AM, Paul Bone <paul.bone@probitas-solutions.tech> wrote:
I have a very similar issue with radius assigned VLAN multi-tenant building networks - so far it is only Google phones that have stopped working with our 802.1x SSID and I have to put them on a MAC auth SSID instead which used to only be used for printers and other devices not supporting 802.1X - and obviously privacy MAC has to be disabled as well.
I suspect many other Android devices will probably follow suit soon.
It's likely that those devices were configured with "don't validate server certificate". This was always wrong and insecure. Recent WiFi standards have mandated that devices validate the server certificate. i.e. the devices must do that in order to use the"WiFi compatible" logo. As a result, we will soon see a whole set of devices which can't get on the net. The best solution is to fix their configuration so that it's secure. Alan DeKok.
If anyone on this list has a cost effective onboarding solution for 802.1x I would certainly be interested. My customers have baulked at the cost of the options such as securew2 for example, and hence we have always used the do not validate flag on these types of networks. It is internet service and internal networks in multi tenant buildings, so margins are very slim! Sent from Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Alan DeKok <aland@deployingradius.com> Sent: Thursday, June 29, 2023 4:34:50 PM To: Paul Bone <paul.bone@probitas-solutions.tech> Cc: FreeRadius users mailing list <freeradius-users@lists.freeradius.org>; Torsten Wilms <T.Wilms@m3connect.de> Subject: Re: 802.1x with GoDaddy Certificates EAP-TTLS On Jun 29, 2023, at 11:18 AM, Paul Bone <paul.bone@probitas-solutions.tech> wrote:
I have a very similar issue with radius assigned VLAN multi-tenant building networks - so far it is only Google phones that have stopped working with our 802.1x SSID and I have to put them on a MAC auth SSID instead which used to only be used for printers and other devices not supporting 802.1X - and obviously privacy MAC has to be disabled as well.
I suspect many other Android devices will probably follow suit soon.
It's likely that those devices were configured with "don't validate server certificate". This was always wrong and insecure. Recent WiFi standards have mandated that devices validate the server certificate. i.e. the devices must do that in order to use the"WiFi compatible" logo. As a result, we will soon see a whole set of devices which can't get on the net. The best solution is to fix their configuration so that it's secure. Alan DeKok.
On Jun 29, 2023, at 11:45 AM, Paul Bone <paul.bone@probitas-solutions.tech> wrote:
If anyone on this list has a cost effective onboarding solution for 802.1x I would certainly be interested.
I haven't seen many. It's difficult and expensive to write software for many operating systems. Plus, vendors see "software for 100K users", and get $$$ in their eyes.
My customers have baulked at the cost of the options such as securew2 for example, and hence we have always used the do not validate flag on these types of networks.
That is very much not recommended. It's not only insecure, it is less likely to work as time progresses. You might have a year or two before most people upgrade, and certificate validation is required.
It is internet service and internal networks in multi tenant buildings, so margins are very slim!
This isn't a priority for vendors selling onboarding software. :( Alan DeKok.
Paul Bone <paul.bone@probitas-solutions.tech> wrote:
If anyone on this list has a cost effective onboarding solution for 802.1x I would certainly be interested.
Apple is easy. iPhones, iPads, and MacOS laptops just need to load a .mobileconfig file. You might want to look where the EDUROAM-CAT product is at the moment, as it is actively developed. Anything android will require an app most likely, which means to bundle a site config, you or the provider of the app would have to publish a site-specific edition of the app in Google's Store. The captive portal support built into Apple, Android, and Windows tends to get broken by the vendors quite often, but is very useful when it actually works and can be used to push profiles on an open SSID as long as your security needs do not prohibit some slack during initial onboarding. We haven't done much on onboarding clients here, because we also have a NAC, and unless we were to use the expensive onboarding in that product, we'd have to add a step to an already onerous (from an end-user's perspective) process. Not to mention the expensive onboarding isn't exactly tightly integrated... you'd think for that much cash they would have smoothed it out but no... Really we need one opensource client that does NAC posture assessment and installs wifi profiles with minimal need for user interaction, since the market does not seem to want to provide one at any price, nevermind a decent price.
In the past we would provide an SSID per tenant and limit those SSIDs to their areas, but having building wide service using radius assigned VLANs is so attractive to both tenants and landlords. It might be we have to push down the route of MAC based authentication with radius assigned VLANs for everyone but it will be more time consuming for the support team. Sent from Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Freeradius-Users <freeradius-users-bounces+paul.bone=probitas-solutions.tech@lists.freeradius.org> on behalf of Brian Julin <BJulin@clarku.edu> Sent: Thursday, June 29, 2023 5:26:22 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: [EXT] Re: 802.1x with GoDaddy Certificates EAP-TTLS Paul Bone <paul.bone@probitas-solutions.tech> wrote:
If anyone on this list has a cost effective onboarding solution for 802.1x I would certainly be interested.
Apple is easy. iPhones, iPads, and MacOS laptops just need to load a .mobileconfig file. You might want to look where the EDUROAM-CAT product is at the moment, as it is actively developed. Anything android will require an app most likely, which means to bundle a site config, you or the provider of the app would have to publish a site-specific edition of the app in Google's Store. The captive portal support built into Apple, Android, and Windows tends to get broken by the vendors quite often, but is very useful when it actually works and can be used to push profiles on an open SSID as long as your security needs do not prohibit some slack during initial onboarding. We haven't done much on onboarding clients here, because we also have a NAC, and unless we were to use the expensive onboarding in that product, we'd have to add a step to an already onerous (from an end-user's perspective) process. Not to mention the expensive onboarding isn't exactly tightly integrated... you'd think for that much cash they would have smoothed it out but no... Really we need one opensource client that does NAC posture assessment and installs wifi profiles with minimal need for user interaction, since the market does not seem to want to provide one at any price, nevermind a decent price. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 29 Jun 2023, at 16:58, Torsten Wilms via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
The idea behind using a public certificate is that anyone can connect to the WLAN without a certificate error if the username and password are correct
Hi, this question bugged me for a while but I didn't have time to verify it, today I've checked, and I think this depends on implementation inside Android. I am using a Pixel phone and Android 11. It has the option to specify the certificates store/chain that will be used to verify the cert from the radius server. But by default, it is expected that you will install CA cert that was used to issue the cert for the radius server. So I think you can make it work, but just need to do a bit more configuration on devices. It is not possible to send screenshots in mail list, so the links are to shared files on GDrive https://drive.google.com/file/d/1mf0dG1wPC1rnw9NvxMNgb3qbPjtThsah - specify security "profile" https://drive.google.com/file/d/1yXknkMmSzTkf6sA7o0d5J-jdiwgG2rNF - specify which certificate store on the Android to use to verify cert from radius server https://drive.google.com/file/d/1ga_QH3tRnyq64LdCJfeSvOcNpW6pdPYL - specify the domain for radius server that will be expected in server cert CN field
On Jun 29, 2023, at 10:53 AM, Torsten Wilms <T.Wilms@m3connect.de> wrote:
Ok. But we use a GoDaddy G2 certificate. And the supplicant must have the root CA
No.
, because if not, the device would not to be able to validate any GoDaddy certificate in the browser ssl connection. Or am I thinking wrong?
"browser" != "supplicant" While they both run on the same device, they are different pieces of software, with different configurations. If you look for documentation on 802.1X and EAP, *everything* will tell you that you need to configure the root CA for EAP. This is how it works. The reasons are complicated and unimportant here. All that is important is that the root CAs used for the web are *not* automatically used for EAP. And there are very good reasons for that. Alan DeKok.
oh Thanks. I think certificate in web server (ssl) could be used in radius. but , i look at in android settings, in privacy and security, there is list of trusted root CA installed. This CA is for browser or for eap ? Thanks. Regards Johan On Thu, Jun 29, 2023 at 9:59 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jun 29, 2023, at 10:53 AM, Torsten Wilms <T.Wilms@m3connect.de> wrote:
Ok. But we use a GoDaddy G2 certificate. And the supplicant must have the root CA
No.
, because if not, the device would not to be able to validate any GoDaddy certificate in the browser ssl connection. Or am I thinking wrong?
"browser" != "supplicant"
While they both run on the same device, they are different pieces of software, with different configurations.
If you look for documentation on 802.1X and EAP, *everything* will tell you that you need to configure the root CA for EAP. This is how it works.
The reasons are complicated and unimportant here. All that is important is that the root CAs used for the web are *not* automatically used for EAP. And there are very good reasons for that.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 22, 2023, at 11:24 AM, johan firdianto <johanfirdi@gmail.com> wrote:
I think certificate in web server (ssl) could be used in radius.
Yes. Various people have claimed otherwise, but...
but , i look at in android settings, in privacy and security, there is list of trusted root CA installed. This CA is for browser or for eap ?
It's for the browser. Alan DeKok.
On 22 Jul 2023, at 17:24, johan firdianto <johanfirdi@gmail.com> wrote:
This CA is for browser or for eap ?
Yes, but I think is named system CA store i.e it is not special or used just for the browsers. I think it depends on Android. Different vendors might not use stock Android and reimplement or cripple base UI, so maybe your device does not expose settings to select CA store. Under the hood, Android uses wpa_supplicant and just passes to it parameters to do wifi/radius authorization. If your UI does not show what CA store will be used, you can try to enable debug logs and then examine them. Here are the logs from my device, I've redacted personal info. WifiNetworkSuggestionsManager: Enterprise config: 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: anonymous_identity "anon@fjf.com" 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: password <removed> 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: proactive_key_caching 1 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: client_cert NULL 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: key_id NULL 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: engine 0 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: engine_id NULL 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: identity "username@whatever.com" 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: ca_path "/system/etc/security/cacerts" 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: domain_suffix_match "radius.whatever.com" 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: ca_cert NULL 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: eap_method: PEAP 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: phase2_method: MSCHAPV2 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: ocsp: 0 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: trust_on_first_use: false 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: user_approve_no_ca_cert: false 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: selected_rcoi: 0 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: IP config: 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: IP assignment: DHCP 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: Proxy settings: NONE 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: cuid=1000 cname=android.uid.system:1000 luid=1000 lname=android.uid.system:1000 lcuid=1000 allowAutojoin=true noInternetAccessExpected=false mostRecentlyConnected=false 07-22 15:09:45.059 1625 1794 V WifiNetworkSuggestionsManager: lastConnected: 07-22 15:08:45.489 07-22 15:08:39.738 10133 10133 D wpa_supplicant: SSL: SSL_connect:TLS client verify_server_certificate 07-22 15:08:39.753 10133 10133 D wpa_supplicant: OpenSSL: Peer certificate - depth 2 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Certificate: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Data: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Version: 3 (0x2) 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Serial Number: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: 03:3a:f1:e6:a7:11:a9:a0:bb:28:64:b1:1d:09:fa:e5 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Signature Algorithm: sha256WithRSAEncryption 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Validity 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Not Before: Aug 1 12:00:00 2013 GMT 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Not After : Jan 15 12:00:00 2038 GMT 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Subject: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Subject Public Key Info: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Public Key Algorithm: rsaEncryption 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Public-Key: (2048 bit) 07-22 15:08:39.753 10133 10133 D wpa_supplicant: Modulus: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: 00:bb:37:cd:34:dc:7b:6b:c9:b2:68:90:ad:4a:75: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: ff:46:ba:21:0a:08:8d:f5:19:54:c9:fb:88:db:f3: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: ae:f2:3a:89:91:3c:7a:e6:ab:06:1a:6b:cf:ac:2d: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: e8:5e:09:24:44:ba:62:9a:7e:d6:a3:a8:7e:e0:54: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: 75:20:05:ac:50:b7:9c:63:1a:6c:30:dc:da:1f:19: 07-22 15:08:39.753 10133 10133 D wpa_supplicant: b1:d7:1e:de:fd:d7:e0:cb: 07-22 15:08:39.754 10133 10133 I wpa_supplicant: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2' hash=cb3ccbb76031e5e0138f8dd39a23f9de47ffc35e43c1144cea27d46a5ab1cb5f 07-22 15:08:39.755 10133 10133 D wpa_supplicant: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=2 buf='/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2' ... 07-22 15:08:39.766 10133 10133 D wpa_supplicant: OpenSSL: Certificate Policy 2.23.140.1.2.2 07-22 15:08:39.766 10133 10133 I wpa_supplicant: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=<...>.com' hash=4 07-22 15:08:39.769 10133 10133 I wpa_supplicant: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:<...>.com 07-22 15:08:39.769 10133 10133 D wpa_supplicant: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=0 buf='<...>.com' 07-22 15:08:39.769 10133 10133 D wpa_supplicant: TLS: Match domain against suffix <...>.com 07-22 15:08:39.769 10133 10133 D wpa_supplicant: TLS: Certificate dNSName - hexdump(len=24): <....> 07-22 15:08:39.769 10133 10133 D wpa_supplicant: TLS: Suffix match in dNSName found 07-22 15:08:39.769 10133 10133 D wpa_supplicant: EAP: Status notification: remote certificate verification (param=success)
participants (6)
-
Alan DeKok -
Brian Julin -
johan firdianto -
Paul Bone -
Torsten Wilms -
work vlpl