Action Center installation error - Host Name blocage

Dear UiPath forum,

I’m soliciting you today as I’m encountering a blocking point when trying to install Action Center on-premise.

We are building an on-premise infrastructure hosted in MS Azure cloud, based on Orchestrator and the Action Center layer. This infrastructure will be composed of two distinct environments : Development and Production each relying on a modest single node implementation with a Web Server and a Data Base server.

  • So far we managed to successfully configure and install the DEV environment and Orchestrator is operational (v2020.10.5), reachable via a CNAME redirection from our organization public domain : https://devcloud.myorganization.com with the proper IIS bindings and so is the Identity Management portal https://devcloud.myorganization.com/identity.

  • Our Prod Orchestrator will be accessible via https://cloud.myorganization.com following same logic.

  • Our SSL Certificate is of type Wildcard, meaning that it covers all URLs following this structure *.myorganization.com and it stipulates “Issued to : *.myorganization.com”

  • During Orchestrator installation we defined the Host Name as "*.myorganization.com" the SSL Certificate as "*.myorganization.com" and Orchestrator public URL as "https://devcloud.myorganization.com" and the installation went just fine we’ve been able to administrate tenants and run robots since then.

  • The Action Center layer will be installed on the same server as Orchestrator with a URL like https://devcloud.myorganization.com:444 or https://devactioncenter.myorganization.com but the installer doesn’t let me reach that URL definition step.

Now, The problem I’m encountering today is that during Action Center Installation (UiPathActionCenter.msi v20.10.1) there is no way it’ll let me pass the first step of the AC installer (AC Installer doc) :

  1. For the SSL Certificate I’ve mentionned the same "*.myorganization.com"
  2. For the Port I mention "444" (as it must be different than the one used by the Orchestrator which is set to 443 when AC is installed on same server)
  3. For the Host Name, regardless of the value I’m trying to provide ("*.myorganization.com" or "myorganization.com" or "devcloud.myorganization.com"…) I always get this error message :

image

Would some of you have insights regarding this situation ?
Any help appreciated,
Cheers, Florent.

Hi Florent,

It seems like the Hostname Mentioned doesn’t match the Subject or Subject Alternative Names.
Could you try the Installation with the Certificate Thumbprint Value and Hostname as actioncenter.myorganization.com ?

If this doesn’t work, then we can schedule a call between 11am-4pm GMT+530 to address this issue.

Please let me know.

Thanks
Ayushya Jaiswal

1 Like

Hi Ayushya,

Thanks a lot for taking the time to reply and suggest actions.

In between my post and your reply we have been able to be in contact with the support who helped us a great deal and managed to solve our problem with a smart workaround that I’ll detail below for further reference if any other user would encounter the same phenomenon :

  • First observation is that Action Center for a reason that will be investigated by the support didn’t seem to react very well to a wildcard certificate (here *.myorganization.com)

  • The idea of the workaround is to provide Action Center with values and a certificate that will “trick it” to go to the next installation steps, finalize it and afterwards revert the newly created website bindings to our wildcard trusted certificate :

  1. We issued a self-signed certificate on our server with the following script and made sure to store the certificate in both Personal and Trusted Root Certificate Authorities :
    New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -NotAfter (Get-Date).AddYears(2) -FriendlyName "ActionCenterCert" -Subject "CN=devcloud.myorganization.com" -DnsName devcloud.myorganization.com -HashAlgorithm SHA256 -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider"

  2. We filled in the value devcloud.myorganization.com in the Host Name and SSL Certificate fields of the Action Center installer’s first step (along with port 444) and it recognized the self-signed certificate and allowed us to go the the next steps.

  3. From there we could pick application pool, enter the Orchestrator URL, deducing the Identity and Action Center URLs. Installation went till the end successfully.

  4. Last step was to change, in the newly created UiPath Action Center website in IIS, the bindings and change the ActionCenterCert self-signed certificate to the trusted *.myorganization.com one.

And voilà :face_with_monocle:

Hope this may help in the future,
Cheers, Florent.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.