The information about the certificate requirements for CUCM conference bridge shared in this post are not entirely accurate. CUCM needs to trust the certificate that is being used for the Web Admin, not call bridge. If your CUCM and CMS are both signed by the same CA, and CUCM trusts the issuer, then the communicates will progress past any cert related issues. If CUCM does not trust the CA that signed your webadmin certificate, then upload the Root CA cert chain or the web admin certificate to the CUCM CallManager-Trust store only. You DO NOT need to upload anything to the Tomcat-Trust.
Ok, thank you. Regarding the certs we need for CMS, we have a working example in another region but they already have server certificates issues for the CUCM servers and so on because they integrate with LDAP, but the CUCM cluster I manage never integrated with LDAP so we only use the default certificates on CUCM. My hope is that I can keep it as simple as possible by not needing to get a server certificate issued for each CUCM server, etc. So that's my interest in using a non-secure SIP trunk to CMS.
Anyway, I have one followup question for you. Are you saying I only need to upload the root CA root certificate that also was responsible for signing the CMS server certificate? If so, I have that and I assume you're saying on CUCM when I upload that root CA certificate, for the 'certificate purpose' I would select CallManager-trust?... and I don't need the whole chain, just the root CA certificate that has a file extension of .cer? If I expand the p7b file which is the chain I downloaded, I see an issuing CA cer file type and a root CA cer file type.
Whoooo i got the answer. It need to configure FQDN on trunk pointing to CMS, CUCM and CMS need to trust each other's certificate. The certificate's CN of CMS should be the same as FQDN.
Forgot to mention that in both certificates (for CMS and CUCM) the fields "SSL Client" and "SSL Server" were set to "Yes", as prescribed by the docs.
So, the certificates seem to be fine.
Yes, see the screenshot.
Docs tell us to indicate CN of the CMS ("X.509 Subject Name = enter the CN of the Call Bridge certificate."), so in this case I have cms.test.lab
Then I chose this profile while creating the secure SIP trunk that I used in the CFB configuration.
Well, the reason turned out to be very trivial - I issued a certificate for webadmin with CN=test.lab rather than cms.test.lab. I focused on callbridge certificates which were issued with correct CN and forgot to check out certs for webadmin.
Hello silverfank, thanks a lot for your info, but was the trunk up before you fixed certificates? I have set the secure trunk up, it seems to be fine:
Time In Full Service: 0 day 0 hour 7 minutes
I provided FQDN (cms.test.lab) rather than IP address for CMS in the trunk settings. Also I uploaded both CUCM and root CA certificates to the CUCM. I issued the certificate for CMS with CN=cms.test.lab and applied it to Callbridge in the CMS.
So, the trunk seems to be operational, but the conference bridge still not registering. How did you fix this problem, if did?
If the SIP Trunk is up but the Conference Bridge is yet not registered, most likely it's because CUCM doesn't trust the WebAdmin of the CMS.
What did you put in the field HTTP Interface Info ? Was it the IP address or the FQDN of CMS ?
CUCM needs to trust CMS Web Server so it needs to contact it with its correct Subject Name.
In our case, since we didn't want to use DNS for CUCM (so putting the FQDN in the HTTP Interface Info is not an option), we tweaked again the certificate and put the IP address of CMS as Subject Alternative Name. After that, the CUCM trusts WebAdmin only with its IP address.
Here's our final working certificate.
In fact, you can notice that it's still a certificate issue by doing a packet capture on CMS with the command "pcap a" and open it with Wireshark, you would notice a SSL handshake error in the beginning of the trace.
Hello Mohamed, thanks a lot for your feedback, the problem was incorrect CN for webadmin cert, indeed. See my answer above in the thread.