Bring Your Own Certificate (BYOC)

Central NAC provides an easy onboarding workflow for devices to connect securely through the Aruba Onboard App. This is a great solution for organizations looking for an easy way to onboard devices without having to deal with the complexities of managing a PKI or device management infrastructure. However, for organizations that already have PKI and device management solutions, the preferred approach would be use existing tools to provision devices. The Bring Your Own Certificate (BYOC) feature in Central NAC now allows the use of external PKI as part of authentication flows.

One example is where organization wants to use Microsoft Cloud PKI to issue certificates and Microsoft Intune to push wired and wireless profiles. In this example, Microsoft Intune would push certificates and network profiles to the devices which then authenticate against Central NAC when they need network connection.

Central NAC now allows uploading server certificate and trusted CA certs that will be used for EAP-TLS authentication. The ability to add trusted CAs enables Central NAC to trust certificates issued by external certificate authorities. Apart from validating trust, Central NAC can also perform OCSP checks to validate the status of the certificate before allowing access.

Configuration steps

The configuration steps to enable the BYOC feature are:

1. Create an 802.1X WLAN and assign it to appropriate scope with the authentication server as Central NAC
2. Navigate to Central NAC > Authentication Profile and create new profile as described in the following steps
3. Set the authentication type as EAP
4. Select the 802.1X network created in step #1. Enable wired authentication if needed
5. Select appropriate identity store to authorize the users if needed. (optional)

6. Under EAP Settings > Certificate select “Custom certificate” to enable BYOC
7. Under EAP Server Certificate paste the server certificate. The certificate needs to be in PEM encoded X.509 format in the order leaf server certificate followed by the intermediate certificates and finally the root CA

8. Provide the PEM encoded private key
9. If the private key is encrypted, provide the private key passphrase under EAP Server Key Passphrase. If the private key is unencrypted, leave the EAP Server Key Passphrase blank

10. Provide the CA certificates under EAP-TLS Client CA chain. The CA certificates have to be in PEM encoded X.509 format as well

Note that multiple root CA certificates can be concatenated together under the field “EAP-TLS Client CA chain” if there are multiple PKIs involved

Example: Company A has separate PKIs for BYOD devices vs corporate owned devices with the certificate chain being : client certificate -> Intermediate CA Certificate -> Root CA Certificate

The root CAs being used are: “Aruba Security CA-BYOD” and “Aruba Security CA-G1”

Here the EAP-TLS Client CA chain would be root CA certificate “Aruba Security CA-BYOD” in base-64 encoded pem format followed by “Aruba Security CA-G1” in base-64 encoded pem format as shown below:

-----BEGIN CERTIFICATE-----
MIIEnzCCA4egAwIBAgIBFjANBgkqhkiG9w0BAQ0FADCB1jELMAkGA1UEBhMCVVMx
EzARBgNVBAgMCkNhbGlmb3JuaWExETAPBgNVBAcMCFNhbiBKb3NlMRcwFQYDVQQK
................................................................
kffkodpJx/gYfamvUVSpkHSWrnw/WG2eMPYnV+ecwUS6bIC/kWhdxodXb4Ps/DqB
mYmhBQiKT+J7iIbNtfSqXyssIn42Ly9duCcwhhaDMDmFRiLObCnfjuwrYMC64yW3
3G0YY99uBOdzXpiUXTPBpnyk4xIXTfSK0jZ+5NhZjbcjhv4=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGUzCCBDugAwIBAgIBGDANBgkqhkiG9w0BAQwFADCBsDELMAkGA1UEBhMCVVMx
EzARBgNVBAgMCkNhbGlmb3JuaWExETAPBgNVBAcMCFNhbiBKb3NlMRcwFQYDVQQK
................................................................
Y/etu7jQ958IZLhwwFsveC9Wj11OzbED1mo5SL0OnkBRxptXSSoU8zp/3zvTgHd9
6j8ZUHcOZ5ZsgWhBqS5irnDgb3kZnMCQfmq6O91fsnfm5rIqEftrvRWB7bfMwm2Q
2mO38EACfNOtx1D7z9rrwM4PFRCZiFTnn3cnkYqdx8Har056gnzq
-----END CERTIFICATE-----

11. Online Certificate Status Protocol (OCSP) is a protocol used to determine the revocation status of a certificate. Enable OCSP check if required. When enabled, Central NAC would use the OCSP URL from the client certificate to validate the certificate. If client certificates do not have an OCSP URL or if you wish to override the OCSP URL specified in the certificate, there is option to provide a OCSP URL
12. OCSP Check Failure Response allows to either Reject or Allow authentications if the certificate has not yet expired. While normally you would want OCSP checks to be enforced, there could be special scenarios where you want the devices to connect to the network to be able to get a new certificate

BYOC FAQs

Q: Can multiple CA certs be added to the EAP-TLS Client CA chain?

A: Yes, multiple pem formatted x509 root CA certificates can be chained together under the field “EAP-TLS Client CA chain”

Q: Does Central NAC support ECC certificates for BYOC?

A: Yes, both ECC and RSA (up to RSA-2048) certificates are supported for BYOC under server certificate and EAP-TLS Client CA chain