SIP Trunk Security Profile Generator

When I open a CUCM cluster I haven't seen before, I usually find three SIP trunks: one to CUBE, one to IM&P, and one to the ITSP or carrier SBC. Out of every ten clusters, eight have at least one of those three in Non Secure mode with the Device Security Mode set to the default "Non Secure SIP Trunk Profile" that CUCM ships with. Reasons given: "we had a cert issue during cutover", "the carrier doesn't support TLS", "it was working so we never changed it." Each reason has a shelf life measured in days; what actually happens is it sits unencrypted for ten years.

The fix is mechanical. For CUBE and CUCM-to-CUCM (ICT), both sides are Cisco — use Encrypted (TLS 1.2 signaling + SRTP media) with mutual TLS. For IM&P, use Encrypted — the IM&P publisher and CUCM publisher exchange certificates automatically if you select "Use Trusted Relay Point" in the trunk config. For Expressway-C, Encrypted with mutual TLS is the standard MRA config and is fully documented. For a third-party SBC, Encrypted if the SBC supports TLS + SRTP (nearly all modern ones do); the one-time cost is importing CA certs in both directions. For a direct-to-ITSP trunk with no SBC in the middle, you're at the mercy of what the carrier offers — many US carriers still only offer TCP 5060 at the SIP level, at which point you should be putting a CUBE or SBC in front anyway.

The one place the profile field most commonly hides a landmine is X.509 Subject Name. This must match the CN or SAN in the peer's certificate exactly. A leading space, a lowercase difference, or the wrong fully-qualified domain vs. short name will make TLS establish but SIP OPTIONS fail with a cryptic "407 Proxy Authentication Required" or a silently-dropped SUBSCRIBE. When the tool emits the Subject CN, it uses the FQDN you entered — verify it matches the cert on the peer before saving.