cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

1297
Views
5
Helpful
5
Replies
Highlighted
Beginner

ISE 2.4: How find and remove ghost certificate?

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:

 

"There is one or more trusted certificate(s) with the same subject name and issuer but having a different serial number 'Subject: CN=OURISE2.ourdomain.intern - Serial Number: <SomeSerialNumber> '. Binding was aborted. For successful binding, you need to remove the other certificate(s) first."
 
Indeed, there was the "default self signed certificate" in Administration -> System -> Certifcates -> System Certificates with that CN.  
 
Solution Attempt: 
a) Generated a new self-signed Certificate with a different CN (DUMMY_OURISE.ourdomain.intern) and configured it to use all services (Admin, EAP, RADIUS DTLS, pxGrid, Portal). 
b) Eventually, the "default self-signed server certificate" with the true CN (which matches the FQDN) was "not in use", and I deleted it from the GUI
c) although disabled, I also reconfigured the SecureSyslogCollector (Admin -> Logging -> Remote Logging Targets) to refer to another CA (here, I had found the "default self-signed server certificate" as well)
 
Problem remains: 
I still can't add a certificate which has the "true" CN=OURISE2.ourdomain.intern, because of the above conflict. However...
 
neither System -> Certificates -> Certificate Management -> System Certificates 
nor System -> Certificates -> Certificate Management -> Trusted Certificates 
 
.. lists a certificate with the supposedly conflicting CN. 
 
 
Since I'm on Patch 10, I hope that this Bug should not bite me.
 
I know, there's always the easy way to generate a CSR with a slightly altered CN and correct SANs. Still, that seems a bit of a band-aid method.
 
QUESTION:
Where else should I be looking for traces of the "default self-signed server certificate", and get rid of it, so I can import the signed certificate with the proper CN? 
 
Thanks a lot for your suggestions and pointers!
Marc
 
 
 
 
 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
VIP Mentor

Hi

The self signed shouldn't deny you to bind the certificate generated by internal pki to your csr.
The error message shows that subject and issuer are the same as your duplicate in your trusted store certificate.
Did you checked in you trusted store of you already have imported the same cert?
Are these certificates including wildcard san?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

View solution in original post

5 REPLIES 5
Highlighted
VIP Mentor

Hi

The self signed shouldn't deny you to bind the certificate generated by internal pki to your csr.
The error message shows that subject and issuer are the same as your duplicate in your trusted store certificate.
Did you checked in you trusted store of you already have imported the same cert?
Are these certificates including wildcard san?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

View solution in original post

Highlighted

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

Highlighted

From cli, you can import export certificate but nothing more.
Are you able to share the output of the new certificate you're trying to bind and what's in your certificate stores?

Also are you able to try a restart of your ise and see if the error is still here?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question
Highlighted

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

 

 

 

Highlighted

No problem. Sometimes it's so obvious and in front of us that we don't see it.
You're welcome and glad your issue is now solved

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question
Content for Community-Ad