08-29-2017 01:51 PM
Hello Everyone,
Spun up a new ISE 2.2 environment and upgrade it to 2.3.
Completed a Wildsans (per cisco instructions here https://communities.cisco.com/docs/DOC-68164) and received our certificate back from our provider.
Regardless of what we have tried on how the csr is created or the signed cert from the provider, we have been unable to BIND the cert to the ISE environment.
We received the following error:
Certificate must contain the FQDN "xxx: or a matching wildcard as a DNS name in teh SubjectAlternativeName (SAN) extension.
The provider has validated the wildcard (*) is in the san AND we have tried also creating the CSR using the FQDN in the CN field.
Does anyone have any hints/ideas/tricks that i may try?
Goal is to create a wildsans certificate to be compatible with our windows/appple/android devices for wifi (eap) authentication.
When creating the WildSAN cert, i am chosing 'multi use' and "use wildcard" options.
Does anyone know if multi-use wildcard cert is no longer supported in 2.3?
thanks in advance for any help.
Solved! Go to Solution.
08-29-2017 03:06 PM
Like Dustin said, it's supported. It seems something else that preventing the binding to work properly. Please engage Cisco TAC if not already done.
Not sure why Sean's post not showing up but he has a good point. You may try binding the certificate by selecting a usage option for either EAP or Portal but not Admin. This way the cert needs not match the FQDN of the ISE node.
08-29-2017 02:03 PM
Miguel,
I am moving your post to the Cisco Security ISE community for better access to feedback and information.
Identity Services Engine (ISE)
Kelli Glass
Moderator for Cisco Customer Communities
08-29-2017 02:28 PM
So, you are creating a cert similar to below?
I have not done a wildcard cert, but have a test 2.3 box, so can give it a try.
08-29-2017 02:31 PM
in the CN field i've used several things but not a wildcard (*) as per cisco recommendations and documents, window clients do not like that. so i have tried ise.domain.com, domain.com and the fdqn itself on both the cn and san fields.
08-29-2017 02:37 PM
yeah, I just looked, so you did a generic, and then a wildcard in the san? it does say to have the generic in the san also.
08-29-2017 02:46 PM
ok, I tried on my test box and was able to bind a wildcard cert.
I did not have it applied to anything, but it did bind
08-29-2017 02:52 PM
this is a site I like to verify the CSR.
https://redkestrel.co.uk/products/decoder/
It's a nice way to verify the security and san settings.
08-29-2017 03:06 PM
Like Dustin said, it's supported. It seems something else that preventing the binding to work properly. Please engage Cisco TAC if not already done.
Not sure why Sean's post not showing up but he has a good point. You may try binding the certificate by selecting a usage option for either EAP or Portal but not Admin. This way the cert needs not match the FQDN of the ISE node.
08-30-2017 07:33 AM
Hello everyone,
Dustin,
on your box, did you deploy the 2.3 ova or was it a 2.2 ova and then upgrade?
I had engage our cert vendor directly and they had validated the cert several times.
TAC is already engaged.
so far we are at "its supposed to work" and it worked in our test environment.
(lol well that's why i have a call into tech support...hahaha)
I'm thinking that deploying the ova 2.2 and then the upgrade package to 2.3 broke something in the background as the error keeps indicating that the secondary node (that was made primary during the upgrade and then secondary afterwards) is needed OR a wildcard in the SANS...the CSR is being created by the original PRIMARY and the name of the primary node and the wildcard have been validated to be correct and in the sans by the cert vendor.
Going to try a single use and report back but i'm thinking that this is upgrade issue with the package and since the environment is NOT in production we will blow away the OVA and deploy the 2.3 ova straight.
08-30-2017 07:40 AM
Yes, this is a test VM deployed directly to 2.3 via OVA.
I have 2 SNS-3595's running 2.3, but these were reinstalled to 2.3 instead of updating.
Hopefully TAC can correct the issue.
Are you using VM's or hardware? I've seen a few posts on upgrade issues and a few recommend just reinstalling to new version and just restoring a backup. This is what I did on our hardware, but also to correct a timezone issue since you can't change without wiping the box.
The nice thing with hardware is the serial doesn't change doing this, so you can reload your licenses.
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