nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Cloud Builder Certificate Requirements

timbkennedy

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?

Find more posts tagged with

Microsoft Azure

Accepted answers

ChristopherPawlyszyn

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.

All comments

DiegoLlamasOlivares

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

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?

ChristopherPawlyszyn

DiegoLlamasOlivares

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.

timbkennedy

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.

ChristopherPawlyszyn

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

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!

DiegoLlamasOlivares

Hello @ChristopherPawlyszyn ,

What about if I am doing a deployment for enterprise 10.9 using cloud builder for azure and I select a self signed certificate fist and then, after the deployment i can add a certificate gis.domain.pr.gov and use that as https://gis.domain.pr.gov/portal and server, is it possible to fist use self signed and then apply the other certificate and redirect azure url as others versions of azure were able to do, Can I do that with this version?

Thanks,

DLL

ChristopherPawlyszyn

I don't think that same methodology has applied since the V2 sites were introduced at version 10.8. Since choosing the self-signed certificate option will build the federation using the <prefix>.<region>.cloudapp.azure.com URL, you'd have to manually break the federation to use a new URL.

As an alternative, you should create your own self-signed certificate (for your intended subdomain) and use that during the deployment process with the correct DNS alias defined, then update the certificate within the Microsoft Azure console for the Azure Application Gateway when it is available.

Renew an Azure Application Gateway certificate | Microsoft Docs
https://docs.microsoft.com/en-us/azure/application-gateway/renew-certificates

DiegoLlamasOlivares

Hello @ChristopherPawlyszyn ,

I have my wild card *gmtgis.net and my steps are, i select a public url. Esri support team recommended me to use my subdomain as it is. (gis.gmtgis.net) but in this step, this do not accept any dots before eastus.appcloud.com

I use my wildcard certificate..

I did this, and VM were created and portal and server were running in VMS but URLs gisgmtgis.eastus.cloudapp.azure.com or gis.gmtgis.net were not working.

Can I create my self-sign from any IIS web server I have? or where do you recommend to create it?

Thanks,

DLL

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.