Cloud Builder Certificate Requirements

1453
8
Jump to solution
03-16-2021 12:36 PM
Labels (1)
timbkennedy
New Contributor III

I am trying to figure out what the certificate requirements are when deploying to Microsoft Azure.

I understand that I need a private .pfx version of the certificate. I also understand that the CNAME attribute for the alias used, e.g. myarcgisenterprise.mycompany.com, needs to point at the domain name of the Public IP address, e.g. myarcgisenterprise.eastus.cloudapp.azure.com.

However whats unclear to me is whether the public ip domain name (i.e. myarcgisenterprise.eastus.cloudapp.azure.com) also need to be added as a subject alternative name on the certificate? If not how do you get that domain trusted so when you browser to it you don't get an 'untrustworthy' note? Do any of the internal server names need to be included?

0 Kudos
1 Solution

Accepted Solutions
ChristopherPawlyszyn
Esri Contributor

Typically when I'm deploying an ArcGIS Enterprise stack using the Cloud Builder for Microsoft Azure application, I'll have the PFX file for my DNS alias available ahead of time. That certificate only needs to include CN and SAN entries for the DNS alias (example.domain.com), since the <name>.<region>.cloudapp.azure.com address is only used in the CNAME record for DNS resolution purposes.

Defining the domain name in the SSL certificate step in the Cloud Builder application essentially sets the WebContextURL for Portal as well as the Services URL defined during federation of the associated hosting ArcGIS Server site. This should be done during the deployment steps for version 2 (10.8+) sites since the process to update those URLs would require unfederation and refederation as well as updating the hostname restriction and SSL certificate on the Azure Application Gateway listener manually.

If you know what <name> you're going to use, you can setup the CNAME record beforehand or configure that while the deployment is completing in the Cloud Builder application. Once complete, you and your clients should always be using https://example.domain.com/portal/... and https://example.domain.com/server/... to access the resources and should always get a valid SSL connection if a valid public CA-signed certificate is used during the deployment process.

View solution in original post

8 Replies
DiegoLlamasOlivares
New Contributor III

Hello,

 

What I have done when install a base deployment using cloudbuilder and i check the option do not use certificate. 

Once installation is done, I check that public domain is done and certificate is created for that domain, in godaddy i do a canonic name or use azure URL and say, my public url is going to re direct this azure url. So every time i try to hit my portal https://dllamas.com/ it will re direct to azure.cloud.com. Once the redirection of url is done, I use cloud builder certificate option with my pfx file and run it. But first the redirection using azure url or public IP should be done. 

 

Hope this help.

 

timbkennedy
New Contributor III

Thanks @DiegoLlamasOlivares - that is definitely helpful.

A quick quick question on that workflow - when you go to https://myarcgisenterprise.eastus.cloudapp.azure.com after importing the .pfx file, does it appear as a secure endpoint or does it show certificate error messages?

0 Kudos
DiegoLlamasOlivares
New Contributor III

After importing pfx, you dont see any more the azure url, you will hit your public url, but if you hit azure url, that url will not be secure, unless you create a certificate for that specific url. 

ChristopherPawlyszyn
Esri Contributor

Typically when I'm deploying an ArcGIS Enterprise stack using the Cloud Builder for Microsoft Azure application, I'll have the PFX file for my DNS alias available ahead of time. That certificate only needs to include CN and SAN entries for the DNS alias (example.domain.com), since the <name>.<region>.cloudapp.azure.com address is only used in the CNAME record for DNS resolution purposes.

Defining the domain name in the SSL certificate step in the Cloud Builder application essentially sets the WebContextURL for Portal as well as the Services URL defined during federation of the associated hosting ArcGIS Server site. This should be done during the deployment steps for version 2 (10.8+) sites since the process to update those URLs would require unfederation and refederation as well as updating the hostname restriction and SSL certificate on the Azure Application Gateway listener manually.

If you know what <name> you're going to use, you can setup the CNAME record beforehand or configure that while the deployment is completing in the Cloud Builder application. Once complete, you and your clients should always be using https://example.domain.com/portal/... and https://example.domain.com/server/... to access the resources and should always get a valid SSL connection if a valid public CA-signed certificate is used during the deployment process.

View solution in original post

timbkennedy
New Contributor III

Thanks for the explanation - very helpful.

Is there a reason setting the CNAME beforehand is important? I plan to use Azure Front Door so the CNAME will in the end point at the Front Door as opposed to the Application Gateway.

The main thing I'm actually running into is Front Door not trusting the backend which is why I'm trying to figure out a way to ensure the infrastructure is trusted.

0 Kudos
ChristopherPawlyszyn
Esri Contributor

I just attempted a deployment without configuring the CNAME record to point to the <subdomain>.<region>.cloudapp.azure.com endpoint and it failed on the ArcGIS Server deployment process. Having the CNAME available beforehand is therefore a necessary step and not doing so will prevent a successful deployment.

Due to the way Azure Front Door routes traffic, and the requirements of Portal to only support a single DNS, I think the Cloud Builder application is not going to be compatible with your intended use case. With that being said, you may be able to break the federation of the deployed site and update the URLs to use the correct Front Door URL while still maintaining a trusted endpoint on the Application Gateway, but the header rules on the Application Gateway would have to be reconfigured accordingly as well. Modifications of that level would prevent the site from being managed/upgraded by the Cloud Builder application in the future, so it seems like a catch 22.

Thinking out loud, is there a method by which the Front Door configuration can resolve DNS differently than via public DNS? If that is the case, the Front Door service could resolve to the Application Gateway while clients would resolve to the Front Door service for the same target host and the same SSL certificate could be used for both.

timbkennedy
New Contributor III

I was hoping to simply point Front Door at the Application Gateway but it looks like it might take some figiting to get it working.

Front Door has a standard endpoint in the format https://<domainname>.azurefd.net and you can add your own domains by adding a CNAME with the Front Door endpoint and registering it. You can either use a built in Front Door certificate, or point it at a custom certificate in Key Vault.

I'm going to give it a go anyway as it's how envisioned deploying the software (global availability is essential) - I will report back if I am successful!

DavidHoy
Esri Contributor

So @timbkennedy ,

how did you go?

0 Kudos