Wireless Access

Hi Guys,

 

Our public signed wildcard certificate is due to expire, I loaded the new cert to a test Instant cluster via Airwave (exactly how we deployed the previous) however it comes up with the following error...

 

DLG_FLAGS_INVALID_CA

 

We loaded the wildcard cert onto the Instant AP's so when authentication is succesful Clearpass hands off to the AP and because it has the wildcard cert the page is kept secure.

 

I just cant understand why the new cert would give this error? Its signed by Entrust, the same as the previous?

Did you chain it correctly?

 I did try to chain the cert using XCA but Airwave would not accept it giving the error Invalid Certificate file for 'PEM' format.

The chain was formated slighlty incorrect, Aruba TAC helped to correct, for reference if anyone needs it;

 

export the certs in base-64 format, copy them to a text file in the following order;

 

1. wildcard
2. inter
3. inter 2
4. root
5. private key

save as .pem

sometimes private key needs to be at top, as someimtes cert error's can occour with it at the bottom on AP's (very rare)

 

You should not be including the root.

This was the advise from TAC, to include the root (CA) cert?

Not sure why they said that. You never include the root in a chain.

What's the reason behind this? seems odd they said this, came from a senior support guy also...

_________________________________________
SHANE SUGGETT
NETWORK ADMINISTRATOR | WABTEC GLOBAL IT| +44 1283 357300 | M: +44 7825 712669
Need Help? Click here

This email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

Pretty standard industry practice. The server should never present the root. The root is in the client trust store.

Hi Tim, from your article on certificates you mentioned combining the root as a standard thing to do.

 

can you explain what's the difference? 

 

https://community.arubanetworks.com/t5/Controller-Based-WLANs/ArubaOS-Default-Certificate-Revocation-FAQ-Controllers/ta-p/275809

 

section:

HOW DO I COMBINE THE PUBLIC KEY FROM MY CA WITH THE INTERMEDIATE, ROOT AND MY PRIVATE KEY USING OPENSSL?

The root CA should not be included. Only intermediates and the leaf.