How in MRA the cisco phone security profile is dealed in encrypted TLS

[david.alfaro1]

Hello Dears

In order of the literature, it says that the names  of the phone security profiles in the Unified CM that are configured for encrypted TLS and are used for devices requiring  remote access. Use FQDN format and separate multiple entries with commas. Having the secure phone profiles as alternative names means that the Unified CM can communicate via TLS with the Expressway-C when it is forwarding messages from devices that use those profiles, son it is necessary to include this FQDN's in the Unified CM phone security profile names when issuing the Expressway-C CSR. All of that is understandable. However I wonder how these security profiles are dealed during the HTTPS communications between the remote device and the Expressway-C, I am confused because I understand that hosts or devices are identified with a URI or a FQDN, so my question is, during the transaction of the phone security profile FQDN, how the jabber device requests specifically the phone security profile name? because I understand that the jabber request is by using some messages using the GET method for example "GET /global-settings.xml HTTP/1.1" or "GET /jabber-config.xml HTTP/1.1", so my question is, what is the time and how the phone security profile is negotiated, in a ladder flow diagram when the HTTPS transaction is happening and what if the name of the phone security profile name is not in format FQDN when encrypted TLS is used, why is the reason to be in FQDN if the phone security profile is a service, it is not a device, host, or user?

Kind regards,

[Roger Kallberg]

AFAIK the security profile name needs to be in the SAN of the certificate as it will be part of the information that is in the communication from the client and the client knows the name of the security profile because it is configured in CM to use that specific profile. There is no negotiation as such for what profile to use, it is based on set configuration. If the documentation says FQDN for security profile(s) that would be a slight misrepresentation as it is the name of the profile that needs to be in the SAN of the certificate and that is not related to an actual FQDN.

[david.alfaro1]

Hello Roger,

I appreciate your explanation. Let me see if I understood correctly. Therefore when the remote endpoint is going to try to establish a TLS session with CUCM throughout Expressway-C, then the endpoint invokes the profile using the name of this profile using its name in format FQDN (in this case nothing to do with DNS lookups and stuff like that of course) to be understandable for the expressway-C and then this one can relay the TLS communications with CUCM. Please let me know if I catched up the idea or not. If this is correct, it is invoked using some particular HTTP(S) method from the remote endpoint, if no, so how ?

Kind regards,

[Roger Kallberg · Accepted solution]

That would be how I understand it. I don't know how it is invoked, that would be a question to address to the development team of the application or possibly someone at TAC might know.

[david.alfaro1]

Thank you Roger, with your explanation I have reached a better understanding about this configuration.

Best regards

---