Stop using self-signed certificates for 802.1X

Adam Education, Uncategorized

Stop using self-signed certificates for 802.1X

Share

When setting up 802.1X we often run into questions about using self signed certificates for WPA2-Enterprise server certificate validation.  First, we should clarify the difference between a self-signed certificate and a private Certificate Authority — this is often a point of confusion.

Self-Signed Certificate:
A self signed certificate is a certificate that has no chain of trust.  It is essentially saying something like ‘You should trust who I am because I say so’.  This works in some cases with webservers that are only being used in non-production environments or in some cases where certificate pinning can be used.
Private Certificate Authorities:
A private certificate authority is a fully functional certificate authority however, the trust chain may not be widely distributed as would be the case with a public CA.   A private CA will contain a root and may contain one or more intermediate certificates.  Unique certificates will be issued for clients and servers as needed.

 

The biggest difference between a private CA and a self signed CA is the trust.  A self signed certificate contains no trust, it is a root and a server certificate rolled into one.  A private CA establishes a trust chain and uses separate certificates for the root and the clients or servers.

Reasons to avoid Self-Signed Certificates for RADIUS:

  1. There is no trust relationship:  RADIUS clients or supplicants will configure a trust relationship on and validate the RADIUS server certificate based on that trust.  By specifying the root and intermediate certificates, the client will accept any RADIUS server certificate signed by that trust as being valid.   Some clients (OSX) may support self signed certificates but not all.
  2. Certificates Expire:  All certificates expire, often it is not realized until after the fact when the help desk is flooded with calls.  802.1X certificate expiration has the potential to cause widespread problems as clients with pinned self signed certs reject the certificate due to expiration.  After replacing the certificate, each client will have to go through the potentially dangerous process of pinning the new certificate.  Where a full CA is used (private or public), the new radius server certificate will most likely be issued from the same trust, so no configuration change will be necessary on the client.

In many cases a private CA may be preferable to a public CA for RADIUS.  Private CAs are often found in Microsoft Windows Domain environments where Microsoft Certificate Services is being run.  In this case, it is trivial to issue a new RADIUS server certificate from the CA.  In environments where a script based linux option is preferred, I have found the EasyRSA package based on openssl to be quick and easy while providing a lot of flexibility.