Page MenuHomeVyOS Platform

eapol: Support for specifying the full CA chain of trust for both client and server
Closed, ResolvedPublicFEATURE REQUEST

Description

Currently, the eapol code seems to support specifying a single CA certificate and client certificate: https://github.com/vyos/vyos-1x/blob/122c7a53575f67759f157e02eca776f799658dc1/src/conf_mode/interfaces-ethernet.py#L170-L171

However, with some ISPs (eg. AT&T Fiber), there are multiple certificates in the server chain of trust (eg. intermediate + root CA) and the client cert might also have its own separate chain of trust as well. wpa_supplicant supports specifying these additional CA's by appending them to the end of the ca_file (server) and client_cert (client) PEM files. It would be nice if this could be configured via the VyOS configuration system. Without this, the EAP-TLS handshake is unable to complete successfully.

(Edited on 2022-02-17 to mention client chain of trust)

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Config syntax change (migratable)
Issue type
Improvement (missing useful functionality)

Event Timeline

Alternatively, since the pki code seems to already recognize parents/issuers:

vyos@vyos:~$ show pki
Certificate Authorities:
Name     Subject                                                                         Issuer CN         Issued               Expiry               Private Key    Parent
-------  ------------------------------------------------------------------------------  ----------------  -------------------  -------------------  -------------  --------
atteap1  CN=ARRIS Group\, Inc. Device Intermediate CA ATTCPE1,O=ARRIS Group\, Inc.,C=US  CN=ARRIS Group\   2013-10-24 20:22:56  2038-10-24 20:22:56  No             atteap2
atteap2  CN=ARRIS Group\, Inc. Device Root CA ATTCPE1,O=ARRIS Group\, Inc.,C=US          CN=ARRIS Group\   2013-10-24 20:17:26  2043-10-24 20:17:26  No             N/A

Would it make sense to keep the current syntax and have interfaces-ethernet.py concatenate all parents?

I started working on implementing my "alternative" idea. It's a little bit more complicated than I first thought because we have to consider both the server and client chain of trust.

Looking at a packet capture with my ISP-provided router, the handshake looks like this:

  • EAP TLS Server Hello:
    • ISP sends 2 certificates
      • Server cert
      • Server intermediate CA
    • ISP router has server root CA in wpa_supplicant's ca_file
  • EAP TLS Client Hello:
    • wpa_supplicant sends 3 certificates
      • Client cert
      • Client intermediate CA
      • Client root CA
    • ISP router has client intermediate CA and client root CA in wpa_supplicant's ca_file

So there are 3 total certificates in wpa_supplicant's ca_file: server intermediate CA, client intermediate CA, and client root CA. If I take any of them out, the handshake fails.

Based on that, it looks like on the VyOS side, if we have:

set interfaces ethernet eth0 eapol ca-certificate isp-server-ca
set interfaces ethernet eth0 eapol certificate isp-client

then /run/wpa_supplicant/eth0_ca.pem must include the full chain of trust for both isp-server-ca and isp-client. I will work on implementing this and then submit a PR to get some feedback about this approach.

After further testing, it looks like it's not necessary to have <iface>_ca.pem contain both the server and client chains of trust.

If <iface>_ca.pem has the full server chain of trust and <iface>_cert.pem has the full client chain of trust, that works just as well. The resulting handshake (as captured by tcpdump) is exactly the same. I'll implement it this way since it's cleaner.

chenxiaolong renamed this task from eapol: Support for multiple CA certificates (eg. intermediate + root) to eapol: Support for specifying the full CA chain of trust for both client and server.Feb 17 2022, 7:38 AM
chenxiaolong updated the task description. (Show Details)
chenxiaolong claimed this task.

Closing this as resolved since both PRs have been merged.