Let’s say for some reason you’re attempting to deploy the on-premises version of WebEx, and you need to put an SSL cert signed by Verisign, Comodo, Entrust etc. on it. Nowadays, any public CA signs their certs with an intermediate certificate, and due to some shortcomings of the WebEx management interface, there’s no way to easily add the intermediate/chain cert on the appliance.
If you’ve tried the method of creating a CSR via the appliance, and imported the signed cert after that, you can’t add the intermediate cert separately. But you can’t export the private key either. The documentation says that you can import a PKCS#12/PFX file with the compelte cert/key/chain in it, so that’s where I began. On a separate machine, I got together a new cert and private key, along with the chain cert ad exported those as a PFX. When trying to import it I get the error “The certificates do not form a valid certificate chain.” The docs indicate that the elements of the file need to be in a particular order, (but specify the wrong order).
After some trial and error I settled on creating/completing the signing request on another server, exporting the chain to a PFX file, then decomposing the elements with openssl (openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes) and appending each section in the following order to a new text (PEM) file. Also, note that the root cert is not included.
- Private Key
- Certificate matched to the Private Key
- Intermediate/Chain Cert
The documentation for this thing is frustratingly lacking, and incorrect in a number of places. (e.g. from the docs “Your public key must be at least 2048 bits.” <- sort of, in fact can only be 2048 bit, no less, no more if trying to import a PFX. Otherwise, ERROR. Public Keys in PKCS12 Archive must be 2048 bits in length.)
I’ve spent time off and on over months trying to track down why certain Office 2013 apps (Lync and Outlook) would unexpectedly prompt for passwords, at startup, or sometimes in the middle of normal operation. I’d looked at all sorts of things, internal and external authentication types, kernel mode authentication in IIS, whether there was a saved password, was the client loading a shared mailbox? None of these were the cause.
I finally stumbled upon an 2003 era document http://support.microsoft.com/kb/820281 which indicates that there can be a prompt if the LMCompatabilityLevel on the workstation is set below 2. Low and behold…
The workstations had this set in local group policy, so simply deleting the key restored the default of using LM level 3. As a more global, and permanent fix, the setting could be applied via Domain Group Policy.
Lync had been attempting to grab HTTP resources via a web proxy, and failing to pass credentials to it. Likewise Outlook was passing LANMAN instead of NTLM or NTLMv2 and failing. I’d looked at the traffic in Wireshark and used Outlook logging, but it wasn’t apparent in either case that this was the problem.