UCM and secure phone registration issue (SIP TLS)

[gfolens]

I've a UCM cluster v12.5SU5 in mixed mode. All registered phones have a LSC certificate.
Initially all phones registered fine in SIP TLS Secure mode on port 5061 in Encryption mode.
Now we have moved the servers and phones to a new location. The DNS names remained. Only the IP addresses of the UCM's and phones changed.
And now there is also a FW between the phones the the UCM servers.
Since the move we are not able anymore to register the phones in SIP Secure mode.
 Switch back to SIP non-secure profile solves the registration problem.
I took some traces and logs but could not find the reason of this problem.
The FW guys say they do not see any packet drops and all required ports should be open.
In the logs I see a connection attempt but this seems to timeout:
00056347.000 |13:54:14.042 |AppInfo |SdlSSLTCPListener::verify_cb pre-verified=1,cert verification errno=0,depth=1
00056348.000 |13:54:14.042 |AppInfo |SdlSSLTCPListener::verify_cb pre-verified=1,cert verification errno=0,depth=0
00056349.000 |13:54:14.082 |SdlSig |SdlConnectionInd |wait |SIPTcp(1,100,191,1) |SdlSSLTCPConnection(1,100,247,43) |1,100,249,2.43^*^* |*TraceFlagOverrode
00056349.001 |13:54:14.082 |AppInfo |SIPTcp - Connection Indication - Listen Port = 5061, Peer Port = 52608
00056349.002 |13:54:14.082 |AppInfo |SIPTcp - New Connection - Index = 172, Listen Port = 5061, Peer Port = 52608
00056350.000 |13:54:14.082 |SdlSig |SIPSPISignal |wait |SIPHandler(1,100,183,1) |SIPTcp(1,100,191,1) |1,100,249,2.43^*^* |*TraceFlagOverrode
00056350.001 |13:54:14.082 |AppInfo |//SIP/Stack/Info/0x0/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 2 (SIP_NETWORK_MSG), for event 57 (SIPSPI_EV_NEW_CONNECTION)
00056350.002 |13:54:14.082 |AppInfo |//SIP/Stack/Transport/0x0/sipTransportProcessNWNewConnMsg: context=(nil)
00056350.003 |13:54:14.082 |AppInfo |//SIP/Stack/Transport/0x0/sipConnectionManagerProcessNewConnMsg: gConnTab=0xe97a7720, addr=10.130.115.143, port=52608, connid=172, transport=TLS Over TCP
00056350.004 |13:54:14.082 |AppInfo |//SIP/Stack/Transport/0x0/sipCreateConnInstance: Created new accptd conn=0xe48c6998, connid=172, addr=10.130.115.143, port=52608, transport=TLS Over TCP
....

The next connection attempt is then seen on the second UCM subscriber.
I tried to use the Cisco TranslatorX but this seems not to detect SIP TLS conversations.

I also took some network captures on the UCM's but there I only see some certificate exchanges and apparently no errors in the conversation (see screen capture).
Anything else I can check to find the cause?

[gfolens]

Probably this is the cause:

Changing the IP address or hostname triggers an automatic self-signed certificate regeneration. This causes all devices in the cluster to reset so that they can download an updated ITL file. If your cluster is using CA-signed certificates, you will need to have them re-signed.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/11_5_1/ipchange/cucm_b_change-ip-address-and-hostname_1151/cucm_b_change-ip-address-and-hostname_1151_chapter_011.html

[gfolens]

Just found out the UCM was not using CA-signed certificates but used the etokens to sign the CTL. Do I need to re-sign the CTL with these tokens using the CTLclient?

[Jonathan Schulenberg]

You need to execute the command from the CLI: utils ctl update CTLFile 

There is a real risk of breaking trust between phones and CUCM here though. It’s not clear what version you upgraded from or which certificates were regenerated. The updated CTL file must be signed by a certificate with the SAST role in the previous/old CTL file the phone has saved to flash. If not the phone won’t accept the new CTL. With eTokens there are two certs with this role in the CTL: CallManager+TFTP of the pub and ITLRecovery. One is actively used and the other serves as a backup. Prior to 12.0 the primary was CallManager+TFTP. This flipped in 12.0 to use the ITLRecovery as primary since it’s validity period is longer. One of those two certs, hopefully ITLRecovery, must not have changed and sign the updated CTL file.

[KMG]

Hello,

To make things secure TLS TCP is not enough, TLS 1.0 and TLS 1.1 are deprecated.

KMG

[b.winter]

What should your command mean? And what has it to do with the original post?
It should be widely know already, that TLS 1.0 and 1.1 are deprecated and shouldn't be used any more.