NOTE: These steps are not required in ArubaOS-Switch 16.08 and ClearPass 6.7.8.
Overview
A root certificate is required on a switch when it is doing downloadable user roles (DUR) or sending fingerprinting data back to ClearPass. The process is documented in several places (eg http://community.arubanetworks.com/t5/Wired-Intelligent-Edge-Campus/What-is-Device-Fingerprinting-How-do-you-configure-Device/m-p/449426), but the first time I tried it, I had to keep looking up intermediate steps that were not spelled out. I documented the whole process, and hopefully that will be useful to others.
The most recent release of switch firmware 16.08 provides some enhancements that makes the process of adding the root certificate even easier.
See https://community.arubanetworks.com/t5/Wired-Intelligent-Edge-Campus/Low-Cost-Certificates-in-the-Lab/td-p/513693 for info on obtaining certificates and DNS management.
Starting Point
This document starts after you have a working certificate on your ClearPass server. (There are already published processes for this; I will probably post some details about my experiences setting up up and managing free SSL certs and managing them later.)
This is two different versions of what the switch shows initially:
Train-core(config)# sh crypto pki ta-profile
Profile Name Profile Status CRL Configured OCSP Configured
--------------- ------------------------------ --------------- ---------------
IDEVID_ROOT Root Certificate Installed
2930F-31(config)# sh crypto pki ta-profile
Profile Name Profile Status CRL Configured OCSP Configured
--------------- ------------------------------ --------------- ---------------
IDEVID_ROOT Root Certificate Installed
COMODO_CA Root Certificate Installed No No
GEOTRUST_CA Root Certificate Installed No No
ARUBA_CA Root Certificate Installed No No
ADDTRUST_CA Root Certificate Installed No No
The aim is to add the root certificate used by ClearPass to the switch.
Extract Root Cert from ClearPass
Browse to ClearPass; note the padlock indicating a valid https certificate.
Right-click on the Site Information block, and view certificate
Choose the Certification Path tab, and select the topmost certificate (DST Root CA X3). 
View Root Certificate.
Click the Details tab, and Copy to File.
This will bring up the Export Wizard
Choose the Base-64 encoded option
Save to a suitable location, leave at defaults, Finish.
On your switch
This is the point where you continue to follow the docs for wired security (https://community.arubanetworks.com/t5/Security/ClearPass-Solution-Guide-Wired-Policy-Enforcement/m-p/298161, p20 switch configuration).
Create a new ta-profile on the switch. You can call it anything, but it would be sensible to refer to the root certificate ID.
2930F-31(config)# sh crypto pki ta-profile
Profile Name Profile Status CRL Configured OCSP Configured
--------------- ------------------------------ --------------- ---------------
IDEVID_ROOT Root Certificate Installed
COMODO_CA Root Certificate Installed No No
GEOTRUST_CA Root Certificate Installed No No
ARUBA_CA Root Certificate Installed No No
ADDTRUST_CA Root Certificate Installed No No
DST-Root-CA-X3 Pending Root Certificate In... No No
The new ta-profile will say "pending" until the certificate is copied to the switch.
2930F-31(config)# copy tftp ta-certificate DST-Root-CA-X3 10.20.30.248 DST-Root-
CA-X3.cer
000M Transfer is successful
2930F-31(config)# sh crypto pki ta-profile
Profile Name Profile Status CRL Configured OCSP Configured
--------------- ------------------------------ --------------- ---------------
IDEVID_ROOT Root Certificate Installed
COMODO_CA Root Certificate Installed No No
GEOTRUST_CA Root Certificate Installed No No
ARUBA_CA Root Certificate Installed No No
ADDTRUST_CA Root Certificate Installed No No
DST-Root-CA-X3 Root Certificate Installed No No
The certificate is now installed and ready to use.
Errors
These are some of the error conditions you may encounter
Incorrect cert type or format
p12 format doesn't work
Colourless(config)# copy tftp ta-certificate vm-syd-cppm 10.20.30.99 vm-syd-cppm_HTTPSServerCertificate.p12
000M Transfer is successful
Invalid file format. Only PEM or DER format certificates are supported.
PEM format (converted using openssl)
Colourless(config)# copy tftp ta-certificate vm-syd-cppm 10.20.30.99 vm-syd-cppm_HTTPS.crt.pem
000M Transfer is successful
Invalid file format. Only PEM or DER format certificates are supported.
Different PEM format
Colourless(config)# copy tftp ta-certificate vm-syd-cppm 10.20.30.99 vm-syd-cppm_HTTPS.crt.pem
000M Transfer is successful
Invalid Trust Anchor certificate.
From log:
`W 08/18/18 14:44:19 03415 crypto: Attempted to install certificate containing formatting errors.
Wildcard Certificate
if you use a wildcard cert instead of a cert issued to a specific FQDN, you will see a error like this
Even though the site is being access by HTTPS with a valid certificate, the certificate is a wildcard. The initial error message is NET::ERR_CERT_COMMON_NAME_INVALID
This is why a specific certificate for web servers is recommended.
Always use a proper certificate.
Self-signed
Self-signed certificates won't work. I also found that intermediate certificates did not work (even though at least one manual said that it should work).
http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/K-KA-KB/15-18/5998-8150_access_security_guide/content/v25051427.html
The file is checked immediately upon completion of transfer and results written to the CLI. The file can be in PEM-encoded or DER-encoded (binary) PKCS#7 format. If the certificate subject matches an existing TA certificate associated with the specified TA profile, then the new certificate updates the existing certificate.
Any certificate which is a root or intermediate certificate will be accepted as a TA certificate. There is no check for the subject.