ā03-28-2017 07:34 AM - edited ā03-18-2019 12:56 PM
I tried to register cms as conference bridge to CUCM but it doesn't register. my security sip trunk to CMS is up which i can see ping interval time.
I got this message from document
"1. Set up an incoming dial plan on the Meeting Server see the Cisco Meeting Server
Deployment Guide. For adhoc calls the rule should match against spaces."
Is it needed to configure dial plan on CMS? if so how to configure it?
ā09-01-2018 03:05 PM
ā09-01-2018 03:10 PM
Thanks
ā10-03-2018 07:04 AM - edited ā10-03-2018 09:39 AM
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.
ā09-02-2018 04:38 PM
ā09-02-2018 04:58 PM
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.
ā09-02-2018 05:38 PM
ā09-03-2018 04:41 AM
Ok, thanks again. I'll be sure to talk to the person in our group that knows much more about the certificates we use to be sure I upload the correct certs.
ā03-30-2017 07:55 AM
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.
ā05-21-2017 06:59 AM
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.
ā05-21-2017 07:31 PM
System -> Security -> SIP Trunk Security Profile
Have you enter CMS' CN certificate in X.509 Subject Name?
ā05-22-2017 02:26 AM
ā05-24-2017 02:12 PM
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.
ā05-21-2017 06:59 AM
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?
ā05-22-2017 03:50 AM
Hello Tieken,
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.
ā05-24-2017 02:15 PM
Hello Mohamed, thanks a lot for your feedback, the problem was incorrect CN for webadmin cert, indeed. See my answer above in the thread.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide