[SOLVED] iwd, eduroam, bad_certificate error

rochus · 2024-02-27 12:48:41

Thanks for the additional clarification, my post was not accurate enough on that!

Regarding your university's certificates, you need to check the entire certificate chain if there is one that was signed with SHA-1. If that's really not the case, then there might indeed be another issue, but given that SHA-1 was the only one removed from the kernel's crypto stack from 6.6 to 6.7, I suspect your certificate chain to be the issue.

unbaked_woven · 2024-02-27 12:58:34

Do you know how I can get hold of the certificate chain? It would be interesting to look into this...

rochus · 2024-02-27 13:18:48

You have the certificate chain somewhere on your system if you successfully connected to eduroam in the past. For instance, if you used the Configuration Assistant Tool from eduroam (cat_installer), then the certificate chain is most likely installed to $HOME/.cat_installer/ca.pem. To view the content of the file in a somewhat human readable format, you could use:

$ openssl storeutl -noout -text -certs ~/.cat_installer/ca.pem

or if you directly want to find out if one of the certs in the chain was signed via sha1, then:

$ openssl storeutl -noout -text -certs ~/.cat_installer/ca.pem | grep -i "sha1"

In my case, this yields

Signature Algorithm: sha1WithRSAEncryption

for one of the certs.

If you cannot locate your ca.pem double check your network configuration, or download your university's cat-installer. The ca.pem is part of the file itself (the cat-installer is simply a python script and the certificate is usually written into the variable Config.CA).

unbaked_woven · 2024-02-27 13:44:35

Thanks for the detailed answer! From what I can see, the radius server's certificate is signed with ecdsa-with-SHA256, and the intermediate and root certificates are signed with ecdsa-with-SHA384. No SHA-1 here...

Last edited by unbaked_woven (2024-02-27 13:45:23)

rochus · 2024-02-27 13:53:26

Odd. Would you mind sharing your certificate chain? Also, you could also increase the log verbosity for iwd and see if this helps to narrow down which of the certificates fails. IIRC, journalctl lists the index of the first failing cert, or at least the debug print contains the running index or so (not on my notebook right now and don't remember how the output really looked like). Knowing which certificate fails could help identify the culprit.

unbaked_woven · 2024-02-27 13:59:40

Here's the certchain, in the order of radius server, intermediate and root:

Last edited by unbaked_woven (2024-02-29 11:03:23)

rimeno · 2024-02-27 14:21:13

Same here, my university's certificate don't use SHA-1, same certification chain as unbaked_woven.

rochus · 2024-02-27 14:43:18

It appears that rsa,sha384 is also not available in recent kernels any longer. At least, when comparing /proc/crypto between the patched arch 6.6.16-1-lts kernel (see the other thread references in one of the previous posts) against the most recent 6.7.6-arch1-1 the following blocks are missing:

< name         : pkcs1pad(rsa)
< driver       : pkcs1pad(rsa-generic)
< module       : kernel
< priority     : 100
< refcnt       : 1
< selftest     : passed
< internal     : no
< type         : akcipher
< 
< name         : pkcs1pad(rsa,sha384)
< driver       : pkcs1pad(rsa-generic,sha384)
< module       : kernel
< priority     : 100
< refcnt       : 1
< selftest     : passed
< internal     : no
< type         : akcipher
< 
< name         : pkcs1pad(rsa,sha1)
< driver       : pkcs1pad(rsa-generic,sha1)
< module       : kernel
< priority     : 100
< refcnt       : 1
< selftest     : passed
< internal     : no
< type         : akcipher

rimeno · 2024-02-27 15:46:05

You are right rochus, but I don't see rsa,sha384 on unbaked_woven's certificates. Only ecdsa,sha384. I'm wrong ?

Last edited by rimeno (2024-02-27 15:46:21)

rochus · 2024-02-27 16:41:35

You're right, I realized that after posting but had to hurry to a meeting and couldn't change my reply in time. In any case, it would be interesting to figure out which one of the certs fails (or if all), and then taking it from there. For that, looking at iwd debug output might be helpful, see TLS Debugging at https://iwd.wiki.kernel.org/debugging for how to turn it on.

unbaked_woven · 2024-02-27 19:43:12

I've figured out how to turn on debugging with the "-d" flag, and I've already enabled TLS debugging. I'll give it a try tomorrow and will post the results.

rimeno · 2024-02-28 07:52:04

Here is my debugging connection, with /etc/systemd/system/iwd.service.d/override.conf :

[Service]
Environment=IWD_TLS_DEBUG=TRUE
ExecStart=
ExecStart=/usr/lib/iwd/iwd -d

https://0x0.st/HR_i.txt

unbaked_woven · 2024-02-28 11:15:58

I copied this out of journalctl so things are a bit truncated, but it doesn't look like the debug "-d" flag added anything interesting to the input that TLS debugging hadn't already printed. The reason code for the failure remains "Can't l_key_get_info for peer public key".

Feb 28 12:01:35 localhost iwd[1213]: src/storage.c:storage_eap_tls_cache_load() No session cache loaded from /var/lib/iwd/.eap-tls-ses>
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_tx_handshake:1244 Sending a TLS_CLIENT_HELLO of 140 bytes
Feb 28 12:01:35 localhost iwd[1213]: TTLS: l_tls_start:3610 New state TLS_HANDSHAKE_WAIT_HELLO
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_mlme_notify() MLME notification Control Port TX Status(139)
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_unicast_notify() Unicast notification Control Port Frame(129)
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_control_port_frame_event()
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_mlme_notify() MLME notification Control Port TX Status(139)
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_unicast_notify() Unicast notification Control Port Frame(129)
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_control_port_frame_event()
Feb 28 12:01:35 localhost iwd[1213]: src/eap-tls-common.c:eap_tls_init_request_assembly() TTLS: Server has set the L bit in the fragme>
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_mlme_notify() MLME notification Control Port TX Status(139)
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_unicast_notify() Unicast notification Control Port Frame(129)
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_control_port_frame_event()
Feb 28 12:01:35 localhost iwd[1213]: src/eap-tls-common.c:eap_tls_init_request_assembly() TTLS: Server has set the L bit in the fragme>
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_handle_handshake:3074 Handling a TLS_SERVER_HELLO of 45 bytes
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_handle_server_hello:2419 Negotiated TLS 1.2
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_handle_server_hello:2455 Negotiated TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_handle_server_hello:2466 Negotiated CompressionMethod.null
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_handle_server_hello:2492 New state TLS_HANDSHAKE_WAIT_CERTIFICATE
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_handle_handshake:3074 Handling a TLS_CERTIFICATE of 2126 bytes
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_handle_certificate:2562 Peer certchain written to /tmp/iwd-tls-debug-server-cert.pem
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_handle_certificate:2673 Disconnect desc=internal_error local-desc=close_notify reason=C>
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_send_alert:1175 Sending a Fatal Alert: internal_error
Feb 28 12:01:35 localhost iwd[1213]: TTLS: tls_reset_handshake:195 New state TLS_HANDSHAKE_WAIT_START
Feb 28 12:01:35 localhost iwd[1213]: TTLS: Tunnel has disconnected with alert: internal_error
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_mlme_notify() MLME notification Control Port TX Status(139)
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_mlme_notify() MLME notification Notify CQM(64)
Feb 28 12:01:35 localhost iwd[1213]: src/netdev.c:netdev_cqm_event() Signal change event (above=1 signal=-55)
Feb 28 12:01:36 localhost iwd[1213]: src/netdev.c:netdev_unicast_notify() Unicast notification Control Port Frame(129)
Feb 28 12:01:36 localhost iwd[1213]: src/netdev.c:netdev_control_port_frame_event()
Feb 28 12:01:36 localhost iwd[1213]: EAP completed with eapFail

Last edited by unbaked_woven (2024-02-28 11:19:34)

seth · 2024-02-28 16:43:55

"journalctl --no-pager"
https://bbs.archlinux.org/viewtopic.php … 2#p2144352

Peer certchain written to /tmp/iwd-tls-debug-server-cert.pem

Can you capture that?

unbaked_woven · 2024-02-29 00:06:52

It’s the same as the first two certificates in the certchain that I posted previously. Thanks for the tip about journalctl btw!

seth · 2024-02-29 09:31:52

I assume you mean https://bbs.archlinux.org/viewtopic.php … 2#p2153512 (and please wrap those in code tags)

What sticks out is that the second certificate has a 256 bit key in an ecdsa-with-SHA384 signature…

Signature Algorithm: ecdsa-with-SHA384
Issuer: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
Validity
Not Before: Feb 18 00:00:00 2020 GMT
Not After : May 1 23:59:59 2033 GMT
Subject: C = NL, O = GEANT Vereniging, CN = GEANT OV ECC CA 4
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:5d:89:2f:1a:b7:eb:32:cd:88:c1:d2:39:f8:8c:
29:13:03:e1:fa:28:16:fc:13:96:7a:d9:8e:c0:ff:
d9:21:70:bc:7c:d7:82:df:f6:58:3c:00:0c:c9:1a:
45:4b:4b:f7:fd:ce:79:14:34:c4:db:16:ce:51:9e:
73:79:56:58:42
ASN1 OID: prime256v1
NIST CURVE: P-256

Also

grep -i ecdsa /proc/crypto

unbaked_woven · 2024-02-29 11:12:35

Ok, wrapped that in code as requested. Is the 256 bit key with a 384 bit signature unusual? Is it an issue?

Here's the output you wanted:

$ grep -i ecdsa /proc/crypto
name         : ecdsa-nist-p384
driver       : ecdsa-nist-p384-generic
name         : ecdsa-nist-p256
driver       : ecdsa-nist-p256-generic
name         : ecdsa-nist-p192
driver       : ecdsa-nist-p192-generic

Last edited by unbaked_woven (2024-02-29 11:12:49)

seth · 2024-02-29 15:55:35

https://www.mozilla.org/en-US/about/gov … umentation

5.1.2 ECDSA wrote:

When a root or intermediate certificate's ECDSA key is used to produce a signature, only the following algorithms MAY be used, and with the following encoding requirements:
If the signing key is P-256, the signature MUST use ECDSA with SHA-256. The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 300a06082a8648ce3d040302.
If the signing key is P-384, the signature MUST use ECDSA with SHA-384. The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 300a06082a8648ce3d040303.

But I frankly have no idea whether that applies here or should apply here - it just struck me as odd.

Neven · 2024-03-10 20:34:37

The discussion on the IWD section of the kernel mailing list seems like it concluded with something like "report a bug to upstream kernel crypto APIs, the removal was a regression". Has anyone done this?

This is the mailing list thread: https://lore.kernel.org/iwd/njvxKaPo_CB … rtys.no/#r

loqs · 2024-03-11 20:59:37

Neven wrote:

The discussion on the IWD section of the kernel mailing list seems like it concluded with something like "report a bug to upstream kernel crypto APIs, the removal was a regression". Has anyone done this?

lrz was going to https://bbs.archlinux.org/viewtopic.php … 9#p2146349 but I can not find any public contact to the kernel developers about the issue.
Edit:
Is everyone satisfied 16ab7cb5825fc3425c16ad2c6e53d827f382d7c6 is the cause? Would reverts applied to current kernels be of any help?

Last edited by loqs (2024-03-11 23:25:52)

rochus · 2024-03-12 06:35:13

for me, reverting 16ab7cb5825fc3425c16ad2c6e53d827f382d7c6 was the solution, but I'm not sure it helps in the cases where the certs were not signed with SHA-1. Unfortunately I didn't have much time yet to poke around regarding rimeno's and unbaked_woven's cert issues.

Neven · 2024-03-16 09:38:04

When IWD fails to connect to Eduroam, it dumps a certificate chain to /tmp/iwd-tls-debug-server-cert.pem. This is the output of the command as above:

$ openssl storeutl -noout -text -certs iwd-tls-debug-server-cert.pem 
0: Certificate
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3 (0x3)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=HR, ST=Zagreb, L=Zagreb, O=FER, CN=CA Root certificate fer.hr
        Validity
            Not Before: Nov 14 15:18:46 2022 GMT
            Not After : Nov 11 15:18:46 2032 GMT
        Subject: C=HR, ST=Zagreb, L=Zagreb, O=FER, CN=freeradius.fer.hr
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:6e:09:46:be:b3:77:0d:08:48:05:a7:92:4a:
                    91:e4:ef:8f:c1:39:72:d0:2a:7d:e0:96:67:f7:74:
                    f7:1f:ca:4a:18:e8:c5:75:47:6b:12:ba:87:06:d2:
                    54:1a:3c:5a:55:c4:da:98:49:1c:dd:60:fb:4e:b7:
                    30:75:f2:17:62:39:dd:fe:e0:3d:23:38:6a:44:a0:
                    8b:58:52:ea:8c:4c:60:66:c9:ce:73:64:6f:47:93:
                    c2:d5:46:52:d9:d7:3c:7c:e7:be:bf:e1:91:c5:92:
                    3b:e4:4b:cd:aa:71:b8:cc:f4:8c:84:3b:fa:93:87:
                    17:46:66:fa:fd:6e:a6:a8:05:c9:90:3a:1e:0d:4a:
                    8d:ab:58:eb:36:38:e7:12:e4:eb:3d:17:2f:43:0d:
                    cb:a8:83:12:3e:0e:b9:69:6d:eb:31:e6:7c:3a:1a:
                    29:97:de:d6:41:07:fd:7e:d6:c7:75:85:03:d2:16:
                    02:8b:ce:84:84:36:49:e3:b5:12:40:86:26:62:56:
                    e7:d6:78:ad:cd:56:38:62:4d:94:8d:37:e6:c8:2d:
                    aa:23:0d:e0:56:6e:27:b7:8b:d7:e6:5f:dd:86:1e:
                    87:f7:2f:a7:09:9a:17:c3:3b:60:c3:01:24:01:1f:
                    3e:0f:9e:08:89:49:b8:d9:f0:b5:c0:6e:8d:45:1f:
                    80:8b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Subject Alternative Name: 
                DNS:freeradius.fer.hr
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        0e:05:2b:f3:fa:7f:96:16:f3:47:d6:29:52:3a:86:5b:62:cc:
        ef:3c:d1:d5:c4:10:98:ad:84:05:a9:7d:3e:eb:18:71:4b:c4:
        13:22:2b:ea:51:44:8a:5c:02:cf:d2:bf:4f:c4:43:15:96:6e:
        b2:72:23:1f:f9:66:35:6c:66:43:ad:fb:3c:f0:8f:28:d1:72:
        07:d4:70:6f:f6:7f:8c:7e:be:3f:a8:91:56:55:6a:28:70:d4:
        fd:d7:dd:92:bc:5e:38:af:cd:27:6b:29:5a:fe:5c:9a:ff:38:
        f4:7d:92:6e:10:59:ed:4f:b6:90:72:f3:d0:f0:ec:41:df:b0:
        a2:9d:b2:55:91:8d:44:c7:31:6e:7c:59:e2:dd:44:c4:74:46:
        3a:8e:59:eb:92:21:e2:58:6f:75:21:5d:24:88:4c:9a:f9:dc:
        a6:7c:b4:75:ce:45:82:5b:6c:09:ca:61:4a:59:cc:83:96:96:
        d0:22:3b:9f:8e:6b:f6:18:85:3e:38:6b:b0:3f:1b:e8:05:fa:
        e7:67:a1:dd:43:09:d5:63:b3:01:26:52:ee:58:1b:39:9e:ab:
        ff:6f:31:b2:00:42:e6:88:9e:88:19:b5:96:16:5f:87:dc:c7:
        b0:c8:1a:ba:09:44:4b:6a:d9:36:d9:2a:b1:d5:f0:37:7f:81:
        d8:c7:b7:99
Total found: 1

SHA1 isn't mentioned anywhere? Was RSA support removed from the kernel? I guess it may be so, especially since someone says, in the IWD mailing list thread:

I'm not that familiar with TLS but based on the code RSA certs use PKCS1, which requires SHA1 (someone correct me if I'm wrong).

I guess this is also aligned with the /proc/crypto diff by rochus above.

FTR, this is my certificate from /var/lib/iwd/eduroam.8021x:

FTR, this is the Eduroam CAT-provided network configuration for my University component in ONC format (it's JSON):

{
    "Type": "UnencryptedConfiguration",
    "Certificates": [
        {
            "GUID": "{8f87dc87-9313-465c-1f46-20acd8a3d8a7}",
            "Remove": false,
            "Type": "Authority",
            "X509": "MIIDjzCCAnegAwIBAgIBADANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJIUjEPMA0GA1UECAwGWmFncmViMQ8wDQYDVQQHDAZaYWdyZWIxDDAKBgNVBAoMA0ZFUjEjMCEGA1UEAwwaQ0EgUm9vdCBjZXJ0aWZpY2F0ZSBmZXIuaHIwHhcNMjIwNDI5MTAyMjM0WhcNMzIwNDI2MTAyMjM0WjBiMQswCQYDVQQGEwJIUjEPMA0GA1UECAwGWmFncmViMQ8wDQYDVQQHDAZaYWdyZWIxDDAKBgNVBAoMA0ZFUjEjMCEGA1UEAwwaQ0EgUm9vdCBjZXJ0aWZpY2F0ZSBmZXIuaHIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDeL\/wTHIS2sfh8rRD+itHHIdpeFPhxhqZi4cN7uKXzvAfR4soy5TMcRUsFtMSoCOT6qo5UShlPu7AWlaJOergEuhEjY6eUtLBSCVvamuDrFgIy7zblPBtbI2WvSRYLhH4caMmyZeXhuTNlAg58vb8BLafHEx0gOCD8PLRtd4cnmY9LPJIBRTMdSP9Mr2vkdvPtn0cCr2v7EWOaieB3m0VfQjD29tLZ0aEuksMg7u9qaIDWMtIkRslyv4ElYVr\/h5lLUNru5PoumtbVP0bIDt402WZIILxsa8h9WibFmnHpCDl9tPBfs10211e+clsJBkdOvu\/P3hexX1yjvWR\/U\/rfAgMBAAGjUDBOMB0GA1UdDgQWBBQ+YP8FYA60WhMr4Ehdv2BcYuG0hDAfBgNVHSMEGDAWgBQ+YP8FYA60WhMr4Ehdv2BcYuG0hDAMBgNVHRMEBTADAQH\/MA0GCSqGSIb3DQEBBQUAA4IBAQBhvXWzczxULiUbezcZjtFcgxjm7ZdtZUL6qdlyLeJHcxtpwTSglpbA5NB3LbBOSMTJLCFb\/KrZ8NupguUClc9t94si3lxCPbgNaek1LMQfejqQoIjgc0HZvxMkDlRRhf5pbWIwpcIIzESmoHNEFauabM5vbJZK5FCHzNDaXYjKPrMOn3rc5Xhbx35+vKUTttpaMIKtslgQwYdVuUwzRZH3p\/dSe5sPVjCSa2Mm33BbIJfliGzRnkJIk54W5N06cet9CWzKAUpLCJIxCegtiT0k22vVpwzc6sLYOrywE9nic31E5GJBrgwCbd0stfLsmJD07c5wRG5HFdbqhyAfTj9C"
        }
    ],
    "NetworkConfigurations": [
        {
            "GUID": "07bd992d-0d9f-f537-cbd0-d9af02a3c86a",
            "Name": "eduroam",
            "Remove": false,
            "Type": "WiFi",
            "WiFi": {
                "AutoConnect": true,
                "EAP": {
                    "Outer": "EAP-TTLS",
                    "Inner": "PAP",
                    "SaveCredentials": true,
                    "ServerCARefs": [
                        "{8f87dc87-9313-465c-1f46-20acd8a3d8a7}"
                    ],
                    "UseSystemCAs": false,
                    "SubjectAlternativeNameMatch": [
                        {
                            "Type": "DNS",
                            "Value": "freeradius.fer.hr"
                        }
                    ],
                    "AnonymousIdentity": "anonymous@fer.hr"
                },
                "HiddenSSID": false,
                "SSID": "eduroam",
                "Security": "WPA-EAP"
            },
            "ProxySettings": {
                "Type": "WPAD"
            }
        }
    ]
}

Last edited by Neven (2024-03-16 09:38:21)

seth · 2024-03-16 16:37:37

[qutoe]Was RSA support removed from the kernel?[/qutoe]

grep -i rsa /proc/crypto

?

loqs · 2024-03-16 18:33:26

16ab7cb5825fc3425c16ad2c6e53d827f382d7c6 included removing support for RSA with SHA1 support from crypto/asymmetric_keys/x509_cert_parser.c. @Neven can you test with that commit reverted?

progandy · 2024-03-16 18:58:03

Neven wrote:

The discussion on the IWD section of the kernel mailing list seems like it concluded with something like "report a bug to upstream kernel crypto APIs, the removal was a regression". Has anyone done this?
This is the mailing list thread: https://lore.kernel.org/iwd/njvxKaPo_CB … rtys.no/#r

The regression has been reported here: https://lore.kernel.org/all/CZSHRUIJ4RK … matfyz.cz/

A patch to revert it has been sent and will be applied, but the kernel devs consider iwd using the kernel crypto api bad practice and userspace should use userspace crypto especially after all the mitigations slowing down syscalls.

https://lore.kernel.org/all/20240313234 … caldomain/
https://lore.kernel.org/linux-crypto/20 … ernel.org/
https://lore.kernel.org/all/CAMj1kXGxxR … gmail.com/

Last edited by progandy (2024-03-16 19:06:23)

Arch Linux

#26 2024-02-27 12:48:41

Re: [SOLVED] iwd, eduroam, bad_certificate error

#27 2024-02-27 12:58:34

Re: [SOLVED] iwd, eduroam, bad_certificate error

#28 2024-02-27 13:18:48

Re: [SOLVED] iwd, eduroam, bad_certificate error

#29 2024-02-27 13:44:35

Re: [SOLVED] iwd, eduroam, bad_certificate error

#30 2024-02-27 13:53:26

Re: [SOLVED] iwd, eduroam, bad_certificate error

#31 2024-02-27 13:59:40

Re: [SOLVED] iwd, eduroam, bad_certificate error

#32 2024-02-27 14:21:13

Re: [SOLVED] iwd, eduroam, bad_certificate error

#33 2024-02-27 14:43:18

Re: [SOLVED] iwd, eduroam, bad_certificate error

#34 2024-02-27 15:46:05

Re: [SOLVED] iwd, eduroam, bad_certificate error

#35 2024-02-27 16:41:35

Re: [SOLVED] iwd, eduroam, bad_certificate error

#36 2024-02-27 19:43:12

Re: [SOLVED] iwd, eduroam, bad_certificate error

#37 2024-02-28 07:52:04

Re: [SOLVED] iwd, eduroam, bad_certificate error

#38 2024-02-28 11:15:58

Re: [SOLVED] iwd, eduroam, bad_certificate error

#39 2024-02-28 16:43:55

Re: [SOLVED] iwd, eduroam, bad_certificate error

#40 2024-02-29 00:06:52

Re: [SOLVED] iwd, eduroam, bad_certificate error

#41 2024-02-29 09:31:52

Re: [SOLVED] iwd, eduroam, bad_certificate error

#42 2024-02-29 11:12:35

Re: [SOLVED] iwd, eduroam, bad_certificate error

#43 2024-02-29 15:55:35

Re: [SOLVED] iwd, eduroam, bad_certificate error

#44 2024-03-10 20:34:37

Re: [SOLVED] iwd, eduroam, bad_certificate error

#45 2024-03-11 20:59:37

Re: [SOLVED] iwd, eduroam, bad_certificate error

#46 2024-03-12 06:35:13

Re: [SOLVED] iwd, eduroam, bad_certificate error

#47 2024-03-16 09:38:04

Re: [SOLVED] iwd, eduroam, bad_certificate error

#48 2024-03-16 16:37:37

Re: [SOLVED] iwd, eduroam, bad_certificate error

#49 2024-03-16 18:33:26

Re: [SOLVED] iwd, eduroam, bad_certificate error

#50 2024-03-16 18:58:03

Re: [SOLVED] iwd, eduroam, bad_certificate error

Board footer