09-19-2022 02:29 AM
I need some help with regards to certificates in Cisco ISE. I have read the following link, but it still has not landed fully:
DEPLOYMENT:
Upcoming Two node ISE deployment (primary node has Primary Admin MnT role and PSN node 1, secondary node has Secondary Admin MnT role and PSN node 2). Internal CA. Have only built a single node setup in a lab environment.
I understand that it is best practice not to use one certificate for Multi Use purposes, which the ISE GUI also clearly states. On the other hand, about every tutorial I read/watched has no issue with using this in a lab setup (which is fine of course in a lab setup).
Then there are recommendations/statements as "why not just use a wildcard certificate and be done with it". As a network engineer I understand what certificates do, but how to implement this in practice is still pretty confusing to me.
Firstly, I would like to use the Admin Identity/certificate and use it only for this purpose (i.e. administrator access to the web portal and clustering of both ISE nodes).
Let's say I use these FQNDs for the nodes:
ise1.abc.com
ise2.abc.com
These then need to be signed by the internal CA of abc.com.
As a network administrator, I am sitting behind my management workstation and pointing my browser to ise1.abc.com. My browser doesn't trust this certificate yet, but I click accept and it is added into my trusted store. It also might be that my workstation/browser trusts the Root CA and I don't see a certificate warning. I have now landed on the Primary Administration Node (PAN).
- Just for my confirmation, as an administrator, I will only need to make any configuration changes on the PAN node correct? It is only when the PAN fails, the secondary node will take over the Administration role? I.e. if everything is stable for years, I will only point my browser to ise1.abc.com?
- In case of a failure and the secondary Administration node takes over, will I just have to point my browser to the secondary FQDN ise2.abc.com (and then accept that certificate)?
- Suppose everything is stable and setup as intended. PAN node which originally was setup as the "master" is still the "master". If I point my browser to ise1.abc.com and ise2.abc.com, will I get a certificate warning for both (if it is not in my Trusted Store)? (This might be a silly question, but I'd like to know how this works if I later on would like to deploy certificates for a possible Guest Portal/BYOD and how the user experience would be when they land at different PSN nodes)
- Would it suffice to give the node ise1.abc.com a Common Name of ise1.abc.com and the node ise2.abc.com a Common Name of ise2.abc.com in the certificates (and not use a Subject Alternative Name) and be done with it? I.e. as an administrator I would get two warning messages when accessing these nodes separately?
- Would there be any merit in adding ise2.abc.com in the SAN field of ise1.abc.com and vice versa? I am not sure if I am understanding this concept correctly. I read that by using the SAN field I would only need need to have one certificate for both nodes, making life as an admin easier because I have one less certificate to worry about when it expires, and it also improves my admin user experience because I don't have to accept a certificate warning two times (for both nodes).
With regards to certificates for EAP client authentication, what is best practice? I don't want an end user to have to accept a certificate warning twice.
In case of EAP client authentication, I assume that having the Root CA sign it, it would also be automatically trusted by managed clients? Or you could manually add these via GPO to the managed client systems? Then the certificate warning would not matter for managed clients.
How does this work certificate wise when setting up a Guest portal/BYOD setup? Where you don't have control over the end user devices?
If you could help me wrap my head around how to setup these certificates for these use cases, without using wildcard certficates, I would be much obliged. Thanks in advance.
Solved! Go to Solution.
09-20-2022 05:36 AM
- Just for my confirmation, as an administrator, I will only need to make any configuration changes on the PAN node correct? It is only when the PAN fails, the secondary node will take over the Administration role? I.e. if everything is stable for years, I will only point my browser to ise1.abc.com?
Correct. Also its best practice not to enable auto PAN failover. Perform failover manually as needed.
- In case of a failure and the secondary Administration node takes over, will I just have to point my browser to the secondary FQDN ise2.abc.com (and then accept that certificate)?
Correct.
- Suppose everything is stable and setup as intended. PAN node which originally was setup as the "master" is still the "master". If I point my browser to ise1.abc.com and ise2.abc.com, will I get a certificate warning for both (if it is not in my Trusted Store)? (This might be a silly question, but I'd like to know how this works if I later on would like to deploy certificates for a possible Guest Portal/BYOD and how the user experience would be when they land at different PSN nodes)
You should deploy certificates CA (private or public) and not use the default self-signed certificates. If you do this properly, you will not get any certificate warnings. Make sure the FQDN of the ISE nodes are in the SAN field.
- Would it suffice to give the node ise1.abc.com a Common Name of ise1.abc.com and the node ise2.abc.com a Common Name of ise2.abc.com in the certificates (and not use a Subject Alternative Name) and be done with it? I.e. as an administrator I would get two warning messages when accessing these nodes separately?
No, Chrome and other browsers require the DNS name to be in the SAN field.
- Would there be any merit in adding ise2.abc.com in the SAN field of ise1.abc.com and vice versa? I am not sure if I am understanding this concept correctly. I read that by using the SAN field I would only need need to have one certificate for both nodes, making life as an admin easier because I have one less certificate to worry about when it expires, and it also improves my admin user experience because I don't have to accept a certificate warning two times (for both nodes).
Yes, if you want to use the same public/private key pair across both nodes. However is best security practice to have individual certificates on each node. Like so:
Certificate 1: CN: ise1.abc.com
SAN: ise1.abc.com
Certificate 2: CN: ise2.abc.com
SAN: ise2.abc.com
With regards to certificates for EAP client authentication, what is best practice? I don't want an end user to have to accept a certificate warning twice.
Do as mentioned above. If you do not have a private CA deployed, get your EAP certificate signed by a public CA.
In case of EAP client authentication, I assume that having the Root CA sign it, it would also be automatically trusted by managed clients? Or you could manually add these via GPO to the managed client systems? Then the certificate warning would not matter for managed clients.
You would do this via GPO. If you have Active Directory Certificate Authority already setup and integrated this should happen automatically. You should get your ISE certificates signed by that CA if this your case.
How does this work certificate wise when setting up a Guest portal/BYOD setup? Where you don't have control over the end user devices?
Public certificates should be used for Guest. Wildcards work fine for guest auth via HTTPS. Wildcard do not play well with EAP (some clients will not trust wildcard for EAP).
09-20-2022 05:36 AM
- Just for my confirmation, as an administrator, I will only need to make any configuration changes on the PAN node correct? It is only when the PAN fails, the secondary node will take over the Administration role? I.e. if everything is stable for years, I will only point my browser to ise1.abc.com?
Correct. Also its best practice not to enable auto PAN failover. Perform failover manually as needed.
- In case of a failure and the secondary Administration node takes over, will I just have to point my browser to the secondary FQDN ise2.abc.com (and then accept that certificate)?
Correct.
- Suppose everything is stable and setup as intended. PAN node which originally was setup as the "master" is still the "master". If I point my browser to ise1.abc.com and ise2.abc.com, will I get a certificate warning for both (if it is not in my Trusted Store)? (This might be a silly question, but I'd like to know how this works if I later on would like to deploy certificates for a possible Guest Portal/BYOD and how the user experience would be when they land at different PSN nodes)
You should deploy certificates CA (private or public) and not use the default self-signed certificates. If you do this properly, you will not get any certificate warnings. Make sure the FQDN of the ISE nodes are in the SAN field.
- Would it suffice to give the node ise1.abc.com a Common Name of ise1.abc.com and the node ise2.abc.com a Common Name of ise2.abc.com in the certificates (and not use a Subject Alternative Name) and be done with it? I.e. as an administrator I would get two warning messages when accessing these nodes separately?
No, Chrome and other browsers require the DNS name to be in the SAN field.
- Would there be any merit in adding ise2.abc.com in the SAN field of ise1.abc.com and vice versa? I am not sure if I am understanding this concept correctly. I read that by using the SAN field I would only need need to have one certificate for both nodes, making life as an admin easier because I have one less certificate to worry about when it expires, and it also improves my admin user experience because I don't have to accept a certificate warning two times (for both nodes).
Yes, if you want to use the same public/private key pair across both nodes. However is best security practice to have individual certificates on each node. Like so:
Certificate 1: CN: ise1.abc.com
SAN: ise1.abc.com
Certificate 2: CN: ise2.abc.com
SAN: ise2.abc.com
With regards to certificates for EAP client authentication, what is best practice? I don't want an end user to have to accept a certificate warning twice.
Do as mentioned above. If you do not have a private CA deployed, get your EAP certificate signed by a public CA.
In case of EAP client authentication, I assume that having the Root CA sign it, it would also be automatically trusted by managed clients? Or you could manually add these via GPO to the managed client systems? Then the certificate warning would not matter for managed clients.
You would do this via GPO. If you have Active Directory Certificate Authority already setup and integrated this should happen automatically. You should get your ISE certificates signed by that CA if this your case.
How does this work certificate wise when setting up a Guest portal/BYOD setup? Where you don't have control over the end user devices?
Public certificates should be used for Guest. Wildcards work fine for guest auth via HTTPS. Wildcard do not play well with EAP (some clients will not trust wildcard for EAP).
09-20-2022 05:53 AM
We have our guest setup with 2 nodes (PSN/PAN/MNT combo) .... The same certificate is on both. the subject it issued to iseguest.domain.com, then we have subject alternative DNS names for iseguest.domain.com, ise1guest.domain.com, ise2guest.domain.com, and subject alternative IP Address entries for the two IPs: 168.244.212.7 and 168.244.212.8 (all random names in the above example, but the config follows the exact same pattern in practice). We are using certificates this way on multiple ISE cubes / clusters, not just one of our ISE guest pairs.
I really want to take this further on my inside (not guest) hosts and figure out how to use the API to tell which node is the primary admin, so we can get that into an F5 LTM health check so we can add another common name which the LTM can forward admin traffic to so adminguest.domain.com, for example, would always throw you onto the primary admin.
Regards,
David
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide