The HTML5 interface is a sight for sore eyes. And if you're using 3.1(3b) as you should be (I started this post a long time ago, apparently), you've got a stable, responsive environment in which to create and apply policy to your servers. I'd never call managing anything in IT "fun," but managing things in UCS Manager is at least not "not fun." High praise, I know.
But you hate that it's using a self-signed cert. You have a CA (or at least you have access to one) and you'd like to issue a trusted cert to make Chrome and Firefox and modern browsers of all sorts stfu about missing subjectAltNames. So you set about the process of requesting a new certificate, and then you try to import the cert into UCS Manager. You set up a Trusted Point, copy the certificate chain into the too-too-tiny window, and save. So far, so good. But when you paste in your cert and associate it with the Trusted Point, you get an error complaining about not being able to split the certificate chain. It looks like this.
 |
| No SSL for you! |
Sometimes, this issue is easily solved by making sure that you've included the full certificate chain in your trusted point config. And since it's not obvious what you're supposed to do there, here's a tip: you have to copy and paste your certs into the same window.
But here's the rub: if you are certain you've correctly imported your cert chain and you're still getting errors about splitting the certificate chain, it's because you failed to fill in the Subject: field in your CSR. Trust me.
Historically, subjectAlternativeNames have been optional, or rather, optionally implemented. The notion of a subjectAlternativeName has been around for decades, but it wasn't until last year when browser developers started requiring a sAN to avoid the dreaded SECURITY WARNING message that we've all learned to subconsciously ignore. And by browser developers, I mean Google, makers of Chrome, the browser we fell in love with a decade ago and now hate as much as we hated IE4 when it killed Netscape Navigator.
But back to the point: you're getting this error because you didn't include a subjectAlternativeName in your certificate. So just go back and generate a new CSR from UCSM with the "Subject" field populated with the FQDN of your UCSM, and send that to your certificate authority. Then copy and paste the new cert, bask in the glory of a successful import, and browse to UCSM error-free, even from Chrome.
But here's the rub: if you are certain you've correctly imported your cert chain and you're still getting errors about splitting the certificate chain, it's because you failed to fill in the Subject: field in your CSR. Trust me.
Historically, subjectAlternativeNames have been optional, or rather, optionally implemented. The notion of a subjectAlternativeName has been around for decades, but it wasn't until last year when browser developers started requiring a sAN to avoid the dreaded SECURITY WARNING message that we've all learned to subconsciously ignore. And by browser developers, I mean Google, makers of Chrome, the browser we fell in love with a decade ago and now hate as much as we hated IE4 when it killed Netscape Navigator.
But back to the point: you're getting this error because you didn't include a subjectAlternativeName in your certificate. So just go back and generate a new CSR from UCSM with the "Subject" field populated with the FQDN of your UCSM, and send that to your certificate authority. Then copy and paste the new cert, bask in the glory of a successful import, and browse to UCSM error-free, even from Chrome.
