Browser error when connecting to UCCX Sub that has SAN SSL Certificate

[Clifford McGlamry]

Customer is having issues with an existing UCCX 12.5 cluster, so we built a new UCCX cluster (12.5.1 SU3 ES06).

Replication is up, system seemed to be behaving, it's licensed, etc.   However the fun began when we started trying to put a SAN SSL Tomcat cert in place.

We have tried with both public and private CAs.  Both have the same issue.  I found that the SSL certs (Tomcat and tomcat trust) were not replicating to the sub.  The CSR would replicate, but when you attempted to load the certs, they did not.  

I was able to manually load the trust chain and get the Tomcat cert to load on the subscriber, and it seems happy about it.  However, none of the browsers I have tried are.  

All of them complain with an error like this:

This server could not provde it is subscriber.company.com: its security certificate is from publisher.company.com.  This may be caused by a misconfiguration or an attacker intercepting your connection.  

I cannot figure out why this is happening.  While I'm not a cryptography expert, I've been successful troubleshooting SSL issues for years.  I have never seen anything like this.  Yes, you can hit the button to proceed anyway, and it will go and function normally (I think), but the browser shows the insecure warning at the top.  

Has anyone ever seen thing or have any idea how it might be resolved?  I've been troubleshooting with the customer for over a week, and not making any headway.  Next step is TAC, but I kinda hate to pull them in on this if I can avoide it. 

[Jonathan Schulenberg]

Does the cert presented to the browser actually contain the SAN attribute with the subscriber FQDN?

It’s acting as if you didn’t choose multi-server cert when generating the CSR. Especially since it didn’t replace the Tomcat identity cert to the sub automatically.

[Clifford McGlamry]

Yep....cert is correctly configured.  Opened a TAC case and TAC spent several hours looking at it yesterday, and thus far have been unable to determine why this is happening.  Engineer has reached out to the BU to determine if there are any known bugs on this, and they have asked us to try some things.   Should be circling back with them later today hopefully. 

[Jared Nelson]

Hello Clifford, did you ever find the solution to this with TAC.  I currently have a tac case opened with this exact issue.  I believe the issue may have to do with the Primary UCCx node improperly defining the hostname of the secondary.  I've noticed in the SAN information on the signed -ms certificate that there is a space in front of the secondary nodes hostname.  Once I get more information from TAC I'll update as well.  

[Jared Nelson]

After working with TAC, I found a solution that would resolve this.  When generating the Tomcat CSR from the primary UCCx node, we toggled the distribution type from 'multi-san to 'node name', then back to multi-san.  Once the CSR is generated we signed this with our internal CA and the resulting -ms certificate no longer had a space in front of the Secondary UCCx node.  

Throughout this, the Secondary UCCx node was difficult to access via web-gui as the browser access was throwing HSTS warnings.  I had to apply the -ms certificate through base-64 within the CLI, followed by a system restart.  'set cert import own tomcat'.  For good measure I applied this to the tomcat trust as well 'set cert import trust tomcat'.  After all this I was able to access the web-gui without errors.  I'd strongly suggest looking up CLI 'set cert' commands to help with any certificate removal, listing, or application as this helped me.