ISE 3.1 Smart licensing SSM On-Prem "Connection error to the server"

[JanLi]

Hi Everyone,

We have upgraded our ISE 2.4 tot 3.1 (With an in between step of 3.0)

first the upgrade to 3.0 worked and also i could make a connection towards our SSM On-Prem.

then we upgraded to 3.1 but the connection towards our SSM On-Prem is lost.

i tried to register from start again but it constantly says: "connection error to the server".

Extr information: 

the token is valid.

ISE can ping towards our SSM-On prem

also it looks like ISE is not making any http(s) traffic at all towards the SSM

We use ISE in standalone MODE. 

There is only 1 interface connected.

i also found in the cli the following command: license esr smart gigabitethernet <1-5>
but like i said. there is only 1 interface connection. in our case interface 0. 

Can you guys help me?

thanks in advance!

[Martin Grimm]

Hi JanLi,

did you manage to solve the problem?

Regards,

Martin

[Milos_Jovanovic]

Hi @Martin Grimm, @JanLi,

I would say that this issue is most often caused by using HTTPS, while either DNS is not properly set, or certificate in use is not trusted by ISE. Easiest for you should be to try and use HTTP (insecure) from ISE to SSM, and to try to use either FQDN or IP address, to eliminate certificate as a root cause.

Kind regards,

Milos

[Martin Grimm]

Hi Milos,
I think you are right.
In the ise-psc.log we are seeing the following after hitting the registration button and 3 minutes of waiting:
2022-11-22 09:24:45,461 ERROR [Thread-177][] com.cisco.nesla.plugin.GCH2Communication -::::- ResultEntity.getError_msg(): Cannot send out SL Message.Certificate for doesn't match any of the subject alternative names: [cssm-obm.mydomain.com]
2022-11-22 09:24:45,465 ERROR [Thread-177][] cisco.nesla.agent.impl.AsyncRequestProcessor -::::- failed to send request / process response: SmartAgentMessageReg
2022-11-22 09:24:45,465 ERROR [Thread-177][] cisco.nesla.agent.impl.AsyncRequestProcessor -::::- Reason: Communication send error.
The CSSM on prem has a valid Cert from our PKI, as ISE has it too and there are both CNs in the SAN Field (cssm.mydomain.com and cssm-obm.mydoamin.com)
But in ISE 3.1 (I think) you cannot bypass https connection. We also tried plain ip address instead of FQDN.
We opened a TAC Case, I will write the solution for that, if ready.

[andrewswanson]

Hi
Are you running into either of these issues?
hth
Andy

The 3.1 upgrade notes state:
https://www.cisco.com/c/en/us/td/docs/security/ise/3-1/upgrade_guide/HTML/b_upgrade_prepare_3_1.html

If you are upgrading from Cisco ISE Release 2.6 Patch 10 and later or 2.7 Patch 4 and later releases and have an SSM On-Prem server configured, you must disconnect the SSM On-Prem server before you begin the upgrade process.

The 3.1 release notes state:
https://www.cisco.com/c/en/us/td/docs/security/ise/3-1/admin_guide/b_ise_admin_3_1/b_ISE_admin_31_licensing.html

You must update to SSM On-Prem release 8-202108 or later to register your license successfully for Cisco ISE 3.0 and later.

[Martin Grimm]

Hi Andy,

No to all you mentioned:
We restored the backup from 2.7 to a fresh install of 3.1 P 4.
On Prem is latest & greatest Version.

We think ISE will do strict SSL matching.
We have 2 Interfaces at the CSSM on Prem, one management interface for all the routers and switches to communicate to this license server and one interface to communicate to the rest of the world. Each interface has a unique ip address and DNS Name. ISE was placed to the "Rest of world" interface because it is a central server. The certificate of the CSSM On Prem has a CN of the management interface and in the SAN Fields there are the entries for management interface and "Rest of world" interface.

Because we are talking to the ROW interface from ISE, ISE will do a strict SSL matching, and CN of certificate is not matching the FQDN we are entering in ISE configuration. If we change that and create an interface in ISE to reach the management interface of CSMM On Prem, then all is working fine.

We have to aknowledge this by TAC, so this are our findings so far. Hope that will help somebody. 

Regards

Martin

[stayd]

Hi something new ?

[Martin Grimm · Accepted solution]

No, we are waiting for TAC statement if this is an issue or a feature .
So ISE seems to do strict SSL CN matching. So you have to address the right CSSM On Prem interface and ISE has to trust the chain of the CSSM On Prem certificate. If this is selfsigned, then import the self signed certificate into the Trusted Certificates in ISE.
Regards, Martin

[stayd]

Hi Martin,

so after several months, have you received any TAC statement ?

[Martin Grimm · Accepted solution]

Hi,

i already forgot about that topic :-D.

And yes TAC have confirmed our assumption. So ISE is doing strict SSL CN matching by design.

Greetz
Martin

[jimroberts]

Hello,

I had a similar issue, what we noticed was once certificates were created and added to SSM and ISE we had to do a full re-synchronizing on the SSM. We found that this is required if you change the Common Name (CN) and/or add a subject alternative name of the SSL cert.

Hope this helps someone 

[MichelB]

We had a similar problem and we found out that the Cisco On prem server is using the following REST API for the registration process:
https:// FQDN-of-the-onprem-server/Transportgateway/services/DeviceRequestHandler  . 
However on the onprem server, Cisco is using a self signed cert, Which is missing the DNS SAN FQDN-of-the-onprem-server.
Only containing the hostname in the DNS SAN field of this certificate.  So in ISE I made a static DNS entry< ip host {hostname-of-the-onprem-server} { ip adr-of-the-onprem-server}>. 
In ISE I specify only the hostname-of-the-onprem-server which is now matching the registration REST-API cert DNS SAN.  And voila, ISE is now able to register itself to the Cisco onprem server.