topic Re: Cisco ACS 5.X Self Signed Certificate (ACS Redundancy) in Network Access Control

Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

Ramraj Sivagnanam Sivajanam — Mon, 11 Mar 2019 02:55:56 GMT

Hi Bro's

I need advice. If I have 2 ACS (redundancy purposes), do I need to generate self signed certs from each of the ACS or just one of the ACS will do, just fine?

The reason I asked is because the self signed cert is used for WLAN users authentication with the ACS. Currently, this is all working fine with 1 ACS.

For further details on this, please do refer to this URL https://supportforums.cisco.com/thread/2177788

Please kindly assist me.

Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

Tarik Admani — Wed, 02 Jan 2013 03:31:04 GMT

Hi,

If you are using this for wireless users and do not want to duplicate certificate validation warnings you can export the certificate and private key from one of the ACS servers and then import the certificate to the other ACS but only import this certificate for the eap interface and I am sure you will be fine.

Thanks,

Tarik Admani
*Please rate helpful posts*

Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

Ramraj Sivagnanam Sivajanam — Wed, 02 Jan 2013 13:03:54 GMT

Hi Tarik

Is there a Cisco document on this step, please?

Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

AdamBlackNNT — Wed, 02 Jan 2013 18:35:21 GMT

You scare me a bit when you're talking about using self-signed certificates for wireless users. As a general rule this is a very bad practice. Users connecting via wireless should be using a protocol like PEAP or EAP-TLS (etc), which rely on them validating the certificate presented to them by your ACS server; if a self-signed certificate is used one of these two things happen:

1. The client drops PEAP/EAP-TLS and uses LEAP instead, which is insecure and can be cracked, rendering your solution insecure.

2. The client uses PEAP anyway (bad behavior on the client part). This is very scary because if the client does not enforce its authentication of the server someone could easily turn up a rogue access point and users would connect to it instead with equal validity (it would present an untrusted certificate, but it's not any less trusted than the one you are presenting). This can lead to all kinds of sensitive data loss.

The only way around that mess using a self-signed certificate would be to use group policy to push out to clients that they should trust the certificate, but that doesn't really work either because:

1. If you have Group Policy that you can push out anyway you have a Microsoft Windows server solution, which you could use as a certificate authority anyway, which is a much better solution

2. Devices such as corporate cell phones and bring-your-own-devices will not get any such update and will be vulnerable to the issues above.

Ultimately the best solution is to get a certificate from a trusted Internet CA. If you don't mind manually re-registering once a year you can even get certificates that you can use for this purpose them for free from some vendors, so cost should not be an issue.

Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

sramraj2000 — Sun, 06 Jan 2013 17:25:18 GMT

Hi Bro

I'm using EAP-FAST.

By the way, just one last question... If I were to have an existing ACS 1121 v5.3 with self signed cert (which is all working fine). When I place the second ACS 1121 v5.3, all I have to do is export the certificate and private key from the existing ACS servers and then import the certificate to the second ACS, am I right?

lastly, I would need to point in my Cisco WLC to the second ACS IP, as well, am I right?

Re: Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

Tarik Admani — Sun, 06 Jan 2013 19:23:04 GMT

On the second ACS I have some doubt if you can use the same self signed certificate for both the https and eap interfaces. I am sure you can make this work with the eap interfaces, but for the https they will have to be different if you plan to join them in a distributed setup (which I assume you are going to do). You can give it a try however, i dont thinking using the same self signed certificate for https interface will work.

Thanks,
Tarik Admani

Sent from Cisco Technical Support iPad App

Re: Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

sramraj2000 — Mon, 07 Jan 2013 00:25:29 GMT

Hi Tarik

I’m confused. Why can’t I use the self-signed certificate generated from the first ACS Server on the second ACS Server? Is it because self-signed certificate are tied to chassis Serial Number?

The reason I asked is because in your earlier explanation, you mentioned that “If you are using this for wireless users and do not want to duplicate certificate validation warnings you can export the certificate and private key from one of the ACS servers and then import the certificate to the other ACS but only import this certificate for the eap interface and I am sure you will be fine.”

Does this mean if I want to manage the second ACS Server via https://10.10.10.50, this won’t work? If yes, then how can I resolve my issue? Please kindly advice.

Re: Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

Tarik Admani — Mon, 07 Jan 2013 01:02:04 GMT

When you import a certificate into the ACS you are given the option as to which interface you want to bind the certificate to. In the case for the wireless users, you can import the same certificate to the "eap Interface" as for the "https interface" you will want to keep those unique, since running in a distributed environment requires https communication with each other.

Thanks,
Tarik

Sent from Cisco Technical Support iPad App

Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

AdamBlackNNT — Tue, 08 Jan 2013 15:19:50 GMT

Hi Steve,

I would not recommend using self-signed certificates for WLC's, regardless of protocol. See my post above for why - EAP-FAST from a security perspective really isn't much better than LEAP if I'm honest... to make it secure you need a lot more client-side work than would be involved with just deploying a trusted certificate to the WLC, and it still wouldn't be as secure as if you had just used a more standards-based approach.

Regarding why you don't want to re-use a certificate for your management interface, let's first consider what a certificate does. It verifies that the name you browse to is owned by the system you connected to. For example, when you go to https://www.google.com, the certificate says that you indeed connected to "www.google.com". If you re-use a certificate generated for a specific host name what you're doing is effectively invalidating the entire certificate security model (note that a wildcard certificate is a bit different, as it is not for a specific name but rather for a range of names).

From a management side, what a certificate lets you do is browse to your server at either https:// or https:// without getting a certificate error. If you generate a certificate on another box presumably the name and IP addresses are different, and therefore the certificate will never be valid for the destination you have browsed to, and thus you should always receive an error. Depending on your browser you may be able to get it to ignore the certificate to name mismatch, but if you do that one begs the question of why you're bothering to use the same certificate anyway since again you are completely invalidating the entire certificate security model (which you can do by using unique self-signed certificates anyway, thus making the exercise of re-using them futile).

Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

Tarik Admani — Tue, 08 Jan 2013 16:07:32 GMT

Adam,

This certificate is not regarding the WLC. This is for the ACS. Most customers prefer to use the same certificate for peap authentication so if there are a cluster of radius servers they are constantly prompted to validate the identity of the radius server. You can validate the radius server certificate through group policy.

Thanks,

Tarik Admani
*Please rate helpful posts*

Re: Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

AdamBlackNNT — Tue, 08 Jan 2013 17:08:21 GMT

Hi Tarik,

I think you've misread my post a bit - I'm talking about the ACS as well. From a management perspective you still browse to https:// or https://, and a self-signed certificate generated by machine A cannot be valid for machine B because the IP address and/or DNS name presented in the certificate will not match what you are browsing to.

For PEAP authentication re-use is more acceptable because that's a slightly different matter because the certificates are handled a bit differently, but consider that if you are suggesting that a customer should use Group Policy to push out the certificate you are directly stating that the customer is using Microsoft Server - which comes with a built-in Certificate Authority anyway! Further, please consider that Group Policy does not affect in any way/shape/form devices such as smartphones, tablets, or any other BYOD equipment - which means that they are 100% vulnerable to all manner of wireless attacks since you are using invalid certificates; take a look at my post above for a run-down of the scenarios that can and do come up.

Ultimately the use of self-signed certificates - particularly shared and therefore invalid self-signed certificates (these are not wildcard certificates remember, these are tied to specific host information which will not be shared) - is insecure, non-scalable, and does not support a wide variety of use-cases... that really can't be up for debate without calling the practicality certificate chains in general into question. Can you get it to work? Yeah, basically, and for a small shop it's fine, but without question it's simply not a best practice and there is an argument to make that for small shops it's actually better to just use Pre-Shared Keys, which are more secure in every way if we discount the possibility of social engineering (which can arguably be more safely discounted in smaller shop where the "IT person" may just configure all the wireless devices manually, and therefore no other employees need to know the PSK).

There is just such a huge range of free or nearly free solutions that completely sidestep this problem that one should always push for their use and ask why they are not possible before accepting the worst-case scenario. As quick examples, Microsoft Server has a CA built in, as do Cisco routers and ASA's. If something is desired that will work for BYOD equipment and cost was a factor, many public / Internet CA's will issue you a number of free single-host certificates... the catch is they're type I/II and typically expire in 1 year, which would force you to renew every year.

Re: Cisco ACS 5.X Self Signed Certificate (ACS Redundancy)

Tarik Admani — Tue, 08 Jan 2013 17:15:40 GMT

Adam,

I am not talking about the HTTPS certificate, when you import a certificate into ACS you have two interfaces that you can attach the certificate to. Once being the EAP interface (which I am talking about) the other for the HTTPs interface (which is not in the conversation when using PEAP). Sure you can import the same cert for both interfaces however some customers like to use a single certificate for all their radius requests.

Here is a screenshot that will help clarify how ACS can have two certs:

Tarik Admani
*Please rate helpful posts*