Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

CWMS SSL Certificates - Intermediate SSL cert chains and different CWMS versions

As you have probably read in official documentation, CWMS needs valid SSL certs installed for normal operation. If you use default self-signed SSL certs, you will keep getting warnings and errors and won't be able to join any meetings before you import those self-signed SSL certs to your end point. 

To avoid this annoying behavior, you should obtain publicly signed SSL certs. You can use SAN (Subject Alternative Name) or Wildcard SSL certs. 

Most of the PCs have intermediate/root certs of all the major Certification Authorities already imported in the Trust stores, so when you upload a single publicly signed CWMS SSL cert to your CWMS solution, the PC and the web browser know how to validate such cert and all will appear to be just fine.

However, iOS and Android mobile devices might still have a problem validating just CWMS SSL cert and will report SSL cert errors even though a valid publicly signed SSL cert has been installed to CWMS. 

To prevent this from happening, you would like to ensure that CWMS offers a full SSL certificate chain to any end point accessing the solution. That means, you would like to have both CWMS SSL cert and CA's Intermediate SSL Certs bundled together and uploaded to CWMS. 

To successfully create this SSL certificate bundle, you can follow these tips.

 

After generating Certificate Signing Request (CSR) on CWMS, using that CSR you will reach out to Public Certification Authority and request SSL cert for your CWMS solution.

1. You will receive a single SERVER SSL cert file for all your CWMS components. This SSL cert file contains just one SSL cert that includes all Subject Alternative Names listed in the CSR you generated.

In CWMS 1.x and 2.0, this cert file is placed at the top of the SSL cert bundle. 
However, in CWMS 2.5 and later, this SSL cert is placed at the bottom of the SSL cert bundle.

2. You will also receive INTERMEDIATE SSL CERT bundle from CA. This bundle usually includes three SSL certificates:

TOP – Secondary Intermediate SSL cert
MIDDLE – Primary Intermediate SSL cert
BOTTOM – Root SSL cert   (you don't need Root SSL cert)

 

For a certificate chain to work properly, certs must be ordered sequentially like a daisy chain.

 

In CWMS 1.x and 2.0, the chain should look like this:

SERVER SSL CERT
SECONDARY INTERMEDIATE SSL CERT
PRIMARY INTERMEDIATE SSL CERT

 

Hence, to create SSL cert bundle on CWMS 1.x and 2.0 version levels, you would do the following:

A. Open SERVER SSL CERT in notepad,
B. Save the file as SSL cert bundle,
C. Open the INTERMEDIATE SSL CERT bundle in notepad,
D. Copy the top two SSL certs (secondary intermediate and primary intermediate) and paste these below SERVER SSL CERT as they are already in the correct order.
This action will create this required chain:

SERVER SSL CERT
SECONDARY INTERMEDIATE SSL CERT
PRIMARY INTERMEDIATE SSL CERT

E. Save this bundle and upload this bundle to your CWMS solution. 

 

In CWMS 2.5 and later versions, the chain is different and should look like this:

PRIMARY INTERMEDIATE SSL CERT
SECONDARY INTERMEDIATE SSL CERT
SERVER SSL CERT

 

Hence, to create SSL cert bundle on CWMS 2.5 version level, you would follow these steps:


A. Open a new blank file in notepad,
B. Open INTERMEDIATE SSL CERT bundle in notepad,
C. Copy the Primary Intermediate (MIDDLE CERT in the INTERMEDIATE SSL CERT bundle file) to the top of the blank notepad file,

D. Copy the Secondary Intermediate (TOP CERT in the INTERMEDIATE SSL CERT bundle file) below Primary Intermediate in the blank notepad file,
E. Open SERVER SSL CERT in notepad and copy its content to the very bottom of blank notepad file.

This action will create this required chain:

PRIMARY INTERMEDIATE SSL CERT
SECONDARY INTERMEDIATE SSL CERT

SERVER SSL CERT


F. At this time, save this new bundle file as CWMS SSL cert bundle and upload it to the system.

 

 

In case the CSR file was created outside of CWMS solution, and you also have externally created PRIVATE KEY that you will also need to import to CWMS, PRIVATE KEY will ALWAYS (regardless of the version) be placed at the VERY TOP (above all certs) in CWMS SSL cert bundle. 

 

I hope this will help.

Comments
Community Member

Hi,

We've recently upgraded to 2.5MR5 patch 1 and have hit an issue where the Webex Add-in gives an error about the security certificate. I suspect the certificate chain we've uploaded to CWMS 2.5 may be wrong, however, I'm not clear about your post above. The fix appears to be to arrange a txt file with the certificates in the order of :

PRIMARY INTERMEDIATE SSL CERT
SECONDARY INTERMEDIATE SSL CERT
SERVER SSL CERT

However our chain doesn't appear to have those certs. I've attached a screenshot showing how our chain seems to be arranged.

 

Can you advise how I need to order these please?

 

 

Cisco Employee

I am not sure if you are experiencing the issue with your CWMS SSL certificates or a different issue with DLL file validation. Can you please check this post and see if this is what you are experiencing: https://supportforums.cisco.com/discussion/12544906/webex-error-23-after-upgrade-25-mr5 ?

Thanks.

-Dejan

Community Member

Thanks for the quick reply - I don't think that is the bug we are experiencing.

 

The error we see it attached. This appears to be different to the .DLL bug.

 

If the attendee clicks 'connect anyway' the Webex session works fine, however, the error is causing some confusion and concern from our users as they're now suspicious our webex may have been compromised so we'd like to resolve ASAP.

 

Thanks again

Cisco Employee

Hi,

There are no real changes between 2.5 and 2.5 MR5 Patch 1 related to the order of SSL cert chain, so I would put a side the fact that you updated and actually focus on what you have installed on your CWMS. 

The screen shot of SSL cert doesn't provide us with the information about certificate chain that is actually uploaded to CWMS server. I can see you are using a wildcard SSL cert *.uhmb.nhs.uk. Can you please go to your CWMS Administration > Settings > Security > Certificates > Certificates on Primary DC and do an Export SSL certificate. Open that SSL cert in notepad and confirm what you see in there. If your Certification Authority (Trustis Healthcare) issues any intermediate SSL certs, those should be included. 

Also, when I go to meet.uhmb.nhs.uk I see the a little icon that shows me the SSL cert is signed using an old SHA1 algorithm. Not necessarily a problem, but is not most secure option. 

Still, let's first see what is installed on your CWMS and go from there.

-Dejan

Community Member

 

OK, the txt file containing the certificate chain we installed onto the CWMS server was in the format of :

  1. ROOT
  2. INTERMEDIATE
  3. WILDCARD

However, when I export the SSL Certificate as per your instructions below I'm only presented with the Wildcard cert??

To be sure I uploaded the whole chain again (restarted with maintenance mode) and then exported the SSL certifcate again. Once again I only got the Wildcard cert downloaded. Is this correct behaviour?

As an aside, we've just been looking at the issue with TAC and they're confident that obtaining an SHA2 signed Wildcard cert will resolve the issue??

Cisco Employee

Hi,

Normally, you don't need to upload root certs, just intermediate and server ones. Still, if you've done that and still experience the issue, then you would need to investigate on the client side what is it that is preventing the client from validating the SSL cert. It is possible that SHA1 is causing this on newer browsers. 

If you are working with TAC, I will let the engineer in charge drive the troubleshooting as he/she has access to the system and can have a better view of the system and the issue.

-Dejan

Community Member

Thanks Dejan - The fact we Import the full chain but only receive the wildcard certificate when we do the export is concerning me as this would indicate the chain isn't being imported or processed fully? Also, we don't actually get the error when using the CWMS web-page, the error only occurs as the Webex Add-in starts-up....

When I think about it more I suspect the TAC recommendation of importing a SHA2 compliant wild card certificate won't actually make a difference because that wouldn't explain why the error doesn't occur on computers that have had the intermediate certificate manually installed in their certificate store??? 

 

 

Cisco Employee

Hi,

 

When you updated to 2.5MR5 Patch 1, from what version did you update and what are the updates you applied and in what order?

 

-Dejan

Cisco Employee

One more thing, I checked your WebEx Site and the server is offering all the SSL certs, server cert and intermediate certs (if you go to www.sslshopper.com > SSLTools > SSL Checker and enter you WebEx Site URL you'll see it offers the entire chain correctly):

https://www.sslshopper.com/ssl-checker.html#hostname=meet.uhmb.nhs.uk

It appears that CWMS doesn't export the entire chain when you do it in Admin. I will open a sev4 bug for that one, as it is not a big deal but an inconvenience).

Anyways, your SSL certs on CWMS should be fine. I don't think SHA has anything to do with this, and I would still check that first reference I've sent you about DLL file signing.

Do your PCs have unrestricted access to the internet or they are in a somewhat  locked environment?

-Dejan

Community Member

Hi Dejan,

Our PC's have failry unrestricted access to the internet although we do run some webfiltering. I checked a few PC's and their Verisign certs all seem current so I'm not sure we're affected by the bug you mention near the top of this thread. Is there a way to positively confirm if a PC is being affected by this bug??

With reference to the upgrade path, we were running version 2.5 (build 2.5.1.29) and this problem wasn't occurring. We then updated to v2.5-MR5 (2.5.1.5033) which is when the problem started occurring. We then applied V2.5-MR5-patch 1 (build 2.5.1.5051) in the hope the problem would be resolved in that version but it's still occurring.

I notice that v2.5-MR6 is now available, but according to the release notes "This maintenance release is only intended for customers who currently have Cisco WebEx Meetings Server Release 2.5.1.29, 2.5.1.78, 2.5.1.132, 2.5.1.216, 2.5.1.227, 2.5.1.3009, 2.5.1.4378, or 2.5.1.5033 installed." It doesn't seem to apply to 2.5.1.5051.

 

Any ideas?

Cisco Employee

Hi,

Firstly, you are eligible for 2.5 MR6 update. In release notes, we list only Maintenance Releases and not individual patches or hotfixes, so if you want to update to MR6, you can definitely do it.

Still, I don't believe MR6 will resolve the issue for you, as there are no fixes that are relevant to your experience. 

After reviewing all the behavior and getting your feedback, I don't believe you are  affected with the issue I initially suspected at, especially if Verisign certs are all up to date.

At this point without http analyzer logs it would be hard for me to continue troubleshooting via forum. I would suggest you to continue working with TAC as you can provide the engineer with access to your system and perform live troubleshooting of the issue. 

-Dejan

Community Member

Thanks Dejan - we sent some HTTP analyser and Webex logs to TAC earlier today.

Once we get a resolution I'll put the detail in the thread for completeness.

Cisco Employee

Thank you. I think it would be good to have that information here for anyone else that might have the same problem.

Much appreciated.

-Dejan

Community Member

Hi Dejan - Just to let you know, we applied MR6 earlier today and it appears to of solved the intermediate certificate issue.

 

Interestingly, the release notes of MR6 appear to of been recently amended and now show a resolved caveat for CSCuu48189 "MR5 no longer sending intermediate certificate" (see http://www.cisco.com/c/en/us/td/docs/collaboration/CWMS/2_5/Release_Notes/Release_Notes.html#concept_C812C4DF96EF40E8921C850DA398FE89)

 

The fact the certificate is signed with an SHA1 algorithm wasn't affecting this issue, however, it's good that we're now aware of this and we are planning on replacing the certificate with an SHA2 compliant one as a matter of good practice.

 

Thanks again for your assistance and quick responses.

Cisco Employee

Thank you very much for the update. 

It is really strange that you've experienced this defect on 2.5 MR5 Patch 1 version level, because this defect is resolved in 2.5 MR5 Patch 1. I am not sure what 2.5 MR6 might have fixed in that regard, but I am glad to hear that the issue got resolved. Hopefully TAC engineer involved in the case was able to identify the root cause before you updated to 2.5 MR6.

Kind regards,

-Dejan

5771
Views
40
Helpful
51
Comments