ISE Distributed Deployment Not Authenticating with Primary Node

[jdmaybe]

After a storage failure, had to recreate a new ISE instance. Upon rebuilding and relicensing, attempting to re-register the node into the distributed deployment (after confirming most up to date version and patch across sites), getting the following error,

"Unable to authenticate ISE (FQDN) Please check certificate configuration. 

Make sure from 'Primary Admin Node' system certificate chain of registering node is present in 'Trusted certificates' and 'Trust for authentication with ISE' Option selected."

After doing both of those things, (using self-signed) and manually importing the appropriate certificates to each node, still receiving the same error. 

Thanks in advance

[marce1000]

 - FYI : https://community.cisco.com/t5/network-access-control/ise-unable-to-register-a-node/td-p/2673444

M.

[jdmaybe]

DNS resolves both ways and both nodes have the corresponding cert from the other as well. 

[marce1000]

 - When trying to register, on both the 'client' node and the Primary Node issue : show logging system ade/ADE.log  , check if any additional info's can be found (use the command on both nodes)

 M.

[jdmaybe]

Nothing there, nor anything relevant in system general log for either node 30 min prior or after attempted registration

[Milos_Jovanovic]

Hi @jdmaybe,

You've double confirmed that your self-signed certificate indeed contains FQDN of ISE server? On both PAN and newly installed node? And you have both forward and reverse DNS records, for both servers?

You are also using FQDN for registration, not IP address?

Kind regards,

Milos

[jdmaybe]

Thanks Milos, yes to both. Multiple folks have confirmed certs are good. Also have a third node in the deployment to match against that is working. 

[marce1000]

 - Make sure that the involved FQDN(s) also have correct PTR-records, 

 M.

[davidgfriedman]

I always add the FQDN as a SAN DNS and the IP Address as a SAN IP, on top of having the FQDN as the common name. Some browsers require it in the SAN DNS field.  

Also, can you verify it from a linux server?  For example, on my linux server I use an openssl call to see the certificate chain, separate from my Windows machine:

openssl s_client ise.yourdomain.com:443

Then, I check the first few results:

depth=2 CN = YOURROOT
verify return:1
depth=1 DC = com, DC = yourdomain, CN = YOURISSUER
verify return:1
depth=0 C = US, ST = NY, L = City, O = Your Company, Inc, OU = SOMEOU, CN = ise.yourdomain.com
verify return:1
CONNECTED(00000003)
---
Certificate chain

0 s:C = US, ST = NY, L = City, O = Your Company, Inc, OU = SOMEOU, CN = ise.yourdomain.com
i:DC = com, DC = yourdomain, CN = YOURISSUER
1 s:DC = com, DC = yourdomain, CN = YOURISSUER
i:CN = YOURROOT
2 s:CN = YOURROOT
i:CN = YOURROOT

There is a lot more after that, but the first few lines show the installed chain, no worrying about IE, Edge, Mozilla or Chrome configs.  If I find it looks good with the openssl check, then the rest is just some browser crap and the Admin GUI was correct.

Regards,
David

[jdmaybe · Accepted solution]

Turns out 1/3 DNS servers had a second, old POR for the node in question that was responding first, despite rx'ing the correct response from nslookup in the node. Had to go into the DNS server and delete the old POR. Cert error message resolved right after that.