cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7458
Views
30
Helpful
38
Replies
Highlighted

Re: CMS:

You might have to export the certificates a different way or convert them to the right format, Google is your friend here.
Highlighted
Enthusiast

Re: CMS:

Thanks

Highlighted
Cisco Employee

Re: CMS:

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.

 

 

Highlighted
Beginner

Re: CMS:

Hi!

Is it absolutely necessary to have a secure trunk between CUCM and CMS for ad hoc conferencing to work?
It is not necessary to have a secure SIP Trunk.
Is it possible to use a non-secure SIP trunk and still have ad hoc conferencing work?
Yes
Is this the key to making a non-secure trunk work for non-secure SIP trunks to CMS from CUCM (see quote below)?...so, just be sure to upload those certs from CMS to the CUCM and it will work with a non-secure SIP trunk between CUCM and CMS? I ask because it would make my life so much easier if I cna use a non-secure SIP trunk between CUCM/CMS.
Yes that’s the key, but let me explain. There’s no need to use a secure SIP trunk between CMS and CM. However, you still need an HTTPS secure connection between CM and CMS to communicate to allow CM to use Conferencing resources. As that communication is secured, then you need to generate an appropriate certificate for CMS, an upload to CM the CA root certificate that signed CMS cert in order to make CM trust the cert. There are several certificates that you might generate for CMS depending on what you will use. You should check de CMS deploy guide, there is an special guide dedicated to certificates.
Regards,
Martin



Highlighted
Enthusiast

Re: CMS:

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.

Highlighted

Re: CMS:

You don't need a new CUCM server certificate, but you do need to trust any intermediate/chain certificates *if* that's what the organisation uses (some CA's issue certs directly from root, some use an intermediate CA). Upload the root and any intermidiate CA certificates to both "Callmanager-trust" and "Tomcat-trust" on each CUCM server, then restart Callmanager and Tomcat services (noting that phones will re-register when you restart the service).
Highlighted
Enthusiast

Re: CMS:

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.

Highlighted
Beginner

Whoooo i got the answer. It

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.

Highlighted
Beginner

Forgot to mention that in

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.

Highlighted
Beginner

System -> Security -> SIP

System -> Security -> SIP Trunk Security Profile 

Have you enter CMS' CN certificate in X.509 Subject Name?

Highlighted
Beginner

Yes, see the screenshot.

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.

Highlighted
Beginner

Well, the reason turned out

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.

Highlighted
Beginner

Hello silverfank, thanks a

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?

Highlighted

Hello Tieken,

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.

Highlighted
Beginner

Hello Mohamed, thanks a lot

Hello Mohamed, thanks a lot for your feedback, the problem was incorrect CN for webadmin cert, indeed. See my answer above in the thread.

CreatePlease to create content
Content for Community-Ad

Cisco COVID-19 Survey