10-11-2019 05:50 AM - edited 10-15-2019 01:51 AM
Hi all
I have a nagging problem with fresh setup of ISE 2.4 (Patch 10 already applied) and a certificate CN conflict I can't resolve.
Background Info:
Intended final setup is a 2 node Cluster with Admin, PSN, and MnT Roles, for ~250 sessions with MAB only. Really, small stuff. Customer Admins require access to the Admin GUI, so the Cert used for Admin should be signed by their internal CA.
Current state:
First/primary node-to-be is fully configured (identities, policies, network devices etc) but lacks the CA signed certificates. Secondary node is just basically set up (IP, NICs, Patch installed, Admin Account) and is waiting for the cert and to be clustered. CSRs with correct FQDN and SANs were generated on both primary and secondary node. CSRs were signed by the CA, now trying to import/bind on the secondary node.
Problem:
Can't bind the certificate received from the CA to the CSR, because this:
Solved! Go to Solution.
10-13-2019 09:28 PM
10-13-2019 09:28 PM
10-13-2019 11:52 PM - edited 10-13-2019 11:56 PM
Hi Francesco
Thanks for your answer.
I only know these two places to go looking for certificates:
System -> Certificates -> Certificate Management -> System Certificates
System -> Certificates -> Certificate Management -> Trusted Certificates
In neither, I can find any certificate with the conflicting CN (or S/N).
Are there any other places to look at? Possibly only via CLI?
Also: None of the certificates involved has a wildcard, neither in CN nor in SAN. Usually, I try to avoid these.
The given internal PKI/CA's root certificate (in extenso: the one that signed the certificate that I'm trying to import) was of course imported to Trusted Certificates. If it weren't, the import/binding attempt would fail at an even earlier stage with a different error message (tried that, too). But the CA/PKI's root cert has a completely different CN and S/N from the certificate reported as conflicting.
There is just one particularity to the given CSR and certificate: Since half of the admins will access these ISEs by IP address, not by FQDN (don't ask, that's just the way it is in this case), I added the IP address(es) of the ISE as SANs (of course of type "IP Address").
Our given error message does not refer to any of these, though. DNS entries (forward and reverse) for the IP addresses and FQDNs in question are configured and resolvable by the ISEs.
The nagging thing is: The error message tells us that the serial number of the already present certificate (which should removed before importing the freshly signed cert) is exactly the serial number of the "default self-signed server certificate" which I had deleted in step b) of the solution attempt (see question above).
This tells me that this default self-signed server certificate -- although presumably unused and deleted -- , is still somewhere in the system, and is still being active or used by some other service. The ISE was rebooted multiple times, hoping that services being restarted would let go of the "ghost" certificate - to no avail.
Which brings back to the original question: Where else can I look for traces of the default self-signed server certificate and clean them out?
best regards
Marc
10-14-2019 06:03 PM
10-15-2019 01:48 AM - edited 10-15-2019 01:49 AM
Hi Franceso
Problem is solved. PEBKAC. I'll go and sit in the shame corner for two days now.
Although I was so certain to have checked the trusted certificates list many times, I eventually did find the default self signed server certificate right there (System -> Certificates -> Certificate Management -> Trusted Certificates), in the exactly the place hinted at by the error message - just as you had pointed out. I must've been blind.
I had left the designated primary node entirely untouched w/regards to certificates, so I could repeat the procedure and document it. And this time, now being aware that the default self signed server certificate appears in both System Certificates and Trusted Certificates, things were straightforward and simple.
Thanks a lot!
Marc
10-17-2019 08:47 AM
04-06-2022 05:54 PM
This worked for me as well. Spent hours both alone and with TAC trying to figure it out. We had disabled the cert but turns out we had to delete it altogether to allow us to import the new cert with same name.
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