Notes on Internally-generated certificates:
Sometimes certs that customers get from their internal security team are not recognized because customers assume they can just use any old cert they get. The cert has to match the generated keypair or it won't work. Sometimes it does work, but it depends on how their internal processes are set up. If their security team generated the new cert based off of the old one it will work. If they just created a new cert using an internal CSR process it won't work and then they will need to proceed as if it's a first-time setup or as if they don't remember the keystore password so they will need to reinitialize the keystore and so on.
If you had HTTPS setup in the past, but you don't remember the keystore password from last time you would likely need to request a whole new cert. Also, if the certificate you received wasn't generated based on the original Certificate Signing Request (CSR) you would need to request a new one. This is one of the processes we hope we can improve in the future because this is always troublesome.
For Chrome, you will need to generate a valid CSR (keypair) that contains the SAN (Subject Alternative Name) and then submit that to your internal Certificate Authority otherwise it will generate an error in the browser, for example: NET::ERR_CERT_COMMON_NAME_INVALID.
For Chrome v58 or higher, all SSL Certificates must include a Subject Alternative Name (SAN) as the common name is ignored and SAN entries are used instead.
Then you can use either https://<hostname.domain.com> for OC or https://<hostname>/ if already allowed by DNS. That will allow you to implement a single SSL certificate to cover both cases.