For the UXI sensor to test a network that uses EAP-TLS certificate-based authentication, the sensor first needs a certificate. There are three ways you can specify a certificate in the UXI network settings:
Manual – In this method, you must work with your PKI administrator offline to provide the sensor a PKCS12 format certificate file that all the sensors testing the network will use for EAP-TLS authentication.
Simple Certificate Enrollment Protocol (SCEP) – To use this method, your environment must have a SCEP server and you must have the challenge password for the SCEP server to request certificates. You can then specify the SCEP server details in your UXI network settings, and the sensors will use those settings to request and renew certificates that will be used for EAP-TLS authentication.
Enrollment over Secure Transport (EST) – This method is an alternative to SCEP. To use this method, your environment must have an EST server and you must have the authentication credentials for the EST server to request certificates. (We currently support Basic and Digest HTTP authentication methods). You can then specify the EST server details in your UXI network settings, and the sensors will use those settings to request certificates that will be used for EAP-TLS authentication.
This article will describe the EST settings in more detail.
Please note that the UXI sensors do not currently support all aspects of EST. The sensor follows all mandatory client functionality of the IETF RFC7030 specification (https://datatracker.ietf.org/doc/html/rfc7030) and some optional functionality, it should work with most EST servers, but has currently only been verified against Aruba Clearpass 6.12.0 and Digicert One Trust Lifecycle 1.5164.0.
For client authentication, UXI supports HTTP-based Basic or Digest username/password authentication. UXI do not currently support:
Certificate TLS with a previously issued client certificate or an installed certificate, a.k.a. Mutual TLS
TLS-PWD a.k.a. certificate-less TLS
For renewal, the sensor will submit a new /simpleenroll request over the connected network that the obtained EST client certificate is used to connect to. In this version, we do not yet support /simplereenroll.
Server Key Generation through /serverkeygen is not supported
Full CMC through /fullcmc is not supported
EST Configuration
This feature is configured in the User Experience Insight settings on a per-network basis, and all sensors testing that network will obtain their own individual certificates for client authentication using the EST settings defined for the network. The sensors then use these certificates to do EAP-TLS client authentication.
Before you can configure a network to obtain a client authentication certificate using EST, you must first define an Enrollment Network, which is the network (wired or wireless) over which the sensor will initially contact the EST server. You can create an Enrollment Network by going to Settings -> Networks and select Add. The Enrollment Network should not require a proxy.
In the Add Network menu, enter the following settings.
Network - Select the wireless network for EST (no selection to be made if creating a wired network)
Alias - (Optional) Specify an alternate network name for how it should be identified in the dashboard.
Security: Enterprise
Auth Method: Certificate
Enrollment Method: EST
Enrollment Network: Select the enrollment network (wired or wireless). This is the network over which the device will reach the EST server and perform the EST process.
EST Server URL: Specify the URL at which to reach the EST server, including the scheme and path, e.g. https://example/.well-known/est
Username – This is the username credential used for HTTP Basic or Digest auth with the EST server. You can choose to use a custom value for all requests or use the sensor name or sensor serial in the request.
Password – This is the password credential used for HTTP Basic or Digest auth with the EST server.
Common Name: The main subject name that identifies the entity associated with the public key of the issued certificate. You can use the sensor serial or the sensor dashboard name. You can also enter a custom value, but the custom value will be the same for all requests. The Common Name should correspond to a user account on the EAP-TLS server for the sensor to successfully use the obtained certificate for EAP-TLS authentication.
Digest Algorithm: Select from SHA-256 or SHA-384.
Key Type: Select from RSA-2048, RSA-4096, EC-prime256v1 or EC-secp384r1
Explicit Trust Anchor: The certificate used to establish trust to bootstrap TLS communication with the server.
Renewal Buffer: A value to define how far in advance you want the sensor to request a new certificate before the certificate expires.
Please note, while we allow configuring the Key Type and Digest Algorithm, we also support /csrattrs. If the EST server also supports /csrattrs and responds with attributes that are different from the configured values (e.g. RSA-2048 is configured but the server responds with a request for prime256v1), the sensor will use the values requested by the server through /csrattrs. (In the example, the sensor will prefer prime256v1 as requested by the server).
There’s also one additional option in the advanced settings you may also want to set is the field for “Specify Server CA” – this is where you upload the root certificate of your RADIUS server. This is used by the sensor to establish trust with the RADIUS server during the 802.1X EAP-TLS process. You can select from:
Re-use EST /cacerts: in this case, the sensor will use the CA certificates obtained during the /cacerts call of EST for EAP-TLS. (This is the default).
Re-use Explicit Trust Anchor: in this case, the sensor will reuse the Trust Anchor (which must be uploaded under the Explicit Trust Anchor setting) as the CA certificate for EAP-TLS.
Import Certificate: this is the same as the original Specify Server CA setting where the uploaded certificate is used as the CA certificate for EAP-TLS.
Merge EST /cacerts and imported Server CA: in this case, a certificate bundle is created by merging the certificates obtained during the EST /cacerts call with an uploaded certificate to form a trust store that is used to verify EAP-TLS.
Certificate Renewal
The sensor will automatically attempt to renew its certificate x days in advance of the expiry date of the current certificate, where x is the configured renewal buffer. Both the certificate expiry date and the certificate renewal date are shown in the ABOUT section of the sensor status page. In this release, the sensor will issue a new /simpleenroll request to the server for renewal, using the configured parameters, including the username and password. Therefore, the EST server must allow multiple enrollment requests from the same device. The renewal request will be issued over the final network that the obtained certificate was used for, not over the original enrollment network. This means that for renewal to be successful, there must be a path to the EST server over the network itself.
FAQ
Does the EST server need to be available after the sensors have obtained certificates?
No. After the sensors have successfully obtained valid certificates, the sensors do not need to contact the EST server until renewal time, or if the certificate is revoked or expired. The EST server must be reachable without a proxy.
When does the sensor request a new certificate?
The sensor will automatically request a new certificate renewal buffer number of days in advance of its expiry.
Can the enrollment network be the same as the network to be tested?
Yes. For example, if you have a network that supports EAP-PEAP but prefers EAP-TLS and the EST server is reachable using EAP-PEAP, you would first create the EAP-PEAP network in the dashboard and use the alias function to name it. Then you can use this network as an enrollment network for the EAP-TLS network obtaining the certificate via EST.
Does the enrollment network count against the 4 network maximum the sensors can test?
No. Unless you want to test the enroll network by adding it to the sensor.
Can I use the same certificate obtained from EST for multiple networks such as wired and wireless?
No. The sensor will request separate certificates for each network.
How do I resolve an error message that says "802.1X failed with unknown CA"?
If you examine the triage menu and the output says "local TLS alert: Unknown CA", this likely indicates the CA you were issued a certificate from via EST does not have the same root CA as the RADIUS server. You can add the root CA certificate or certificate chain for the RADIUS server in the SCEP network settings under Advanced -> Server CA and select Import Certificate.
Which EST Servers are Supported?
Since the sensor follows all mandatory client functionality of the IETF RFC7030 specification (https://datatracker.ietf.org/doc/html/rfc7030) and the optional functionality that has been specified in this document, it should work with most EST servers. However, it has currently only been verified against Aruba Clearpass 6.12.0 and Digicert One Trust Lifecycle 1.5164.0.