Mist Access Assurance – Server Certificate

Overview

When clients are using any form of EAP authentication, authentication is always mutual, i.e. both the client need to trust or authenticate the server they are talking to, as well as the server needs to authenticate the client. First step of that mutual authentication is for the client to validate or trust a Server certificate. In our case the “Server” is Mist Access Assurance cloud.

If we take a look at any EAP transaction (say EAP-TLS or EAP-TTLS), regardless if it is wireless or wired authentication, the first step is for the server to identity itself by sending a Server Hello:

Now, when a client receives a Server certificate it has two options based on the client configuration:

1. Look at the list of trusted Certificate Authorities (CAs) in the WiFi/LAN profile and see if Server certificate is signed by one of the trusted CAs. Optionally, if configured, check if Server Name matches the list of trusted server names in the supplicant/client config.
2. Bypass validation step and “blindly” trust the server certificate.
   1. This is a high security risk practice and should not be done in any production deployment. This opens up MITM (Man in the middle) attacks especially when credential based authentication is being used. An attacker can easily spoof client username/password in that scenario.
   2. Some operating systems recently have started to remove this capability from client configuration (hello, Android), and provide an alternative approach instead called “Trust on First Use”. This creates new set of issues when your server certificate is rotated (you need to forget the network and add it again). So to reiterate – do not use bypass server validation option in production.

Default Access Assurance server certificate

By default, each Mist organization has its own private Mist Certificate Authority that also issues Access Assurance server certificate. If nothing is configured, clients will be presented with a default certificate signed by your Mist Org CA. Certificate will be issued for the name “auth.mist.com”.

Example:

What do I need to do on the client side?

Essentially, you have two options, both are perfectly valid:

1- Let clients trust your organisation Mist CA cert and optionally validate server cert name as “auth.mist.com”. This option is good if you do not want to issue server certificate using your own PKI/Cert infra, and it is easy for you to make changes to your client devices. Do do this navigate to Organization > Access > Certificates and click on View Mist Certificate:

Copy this certificate and save it as .crt or .cer file, which you can later import to all your clients as a trusted Root Certificate. Once clients are configured to trust Mist CA certificate it is typically good for ~10 years.

2- Using Custom Server Certificate. This option is preferred when you would like to avoid making any changes to existing client configuration, and you want clients to trust server certificate issued by the same CA that issued client certs.

In such scenario, you can import your own custom server certificate if you navigate to Organization > Access > Certificates, then click on Import Custom RADIUS Server Certificate:

Few guidelines on using custom server certs:

• Do not use wildcard certificates, i.e. *.acme.com. When it comes to 802.1X most clients will complain when they see a wildcard cert. We strongly recommend avoiding these certs for 802.1X authentication. You can use any CN / SAN name you like, since clients are not actually validating server name to IP resolution, for example auth.mycompany.com.
• When using custom server certificate clients are configured to trust the Root CA cert that signed your server certificate, so when you are rotating server cert (typically done every year or few years), clients would still trust the new server cert, since they trust the parent CA.
• When importing server certificate into “Signed Certificate” field, please include all the intermediate CAs and Root CA certs as well. They should all be separated by —–BEGIN CERTIFICATE—– | —–END CERTIFICATE—– sections.
• We recommend the following x509 extensions to be included (to keep majority of the client device OS happy):
  • certificate version should be v3 (not legacy v1)
  • if using server name as validation criteria on the client side, include SAN (Subject Alternative Name): DNS and use this name for validation
  • include Extended Key Usage as TLS Web Server Authentication (required for most Android devices).