Any communication sent over a computer network can potentially be intercepted, deciphered, or altered. To secure network communication in ArcGIS Enterprise, the use of HTTPS is recommended and enforced by default.
HTTPS encrypts communication to and from a web server. This facilitates secure network communication by identifying and authenticating the web server to each web client that communicates with it. The use of HTTPS helps ensure the privacy and integrity of all transmitted data.
To create an HTTPS connection between a web server and a client, the web server requires a server certificate. A certificate is a digital file that contains information about the identity of the web server. It also contains the encryption technique to use when establishing a secure channel between the web server and the client. A certificate must be created by the owner of the website and digitally signed.
Esri recommends several best practices regarding server certificates. These best practices pertain to all ArcGIS Server sites and to the ArcGIS Enterprise portal, but should also be considered with other components of your deployment.
Replace self-signed certificates with CA-signed certificates
After installation of ArcGIS Server and Portal for ArcGIS, these components are automatically configured with self-signed certificates. These certificates, which are signed only by the owner of a website, enable HTTPS communication without needing additional steps. But most web browsers will not initially trust your ArcGIS Enterprise deployment’s URLs. As a result, you and your users will have to suppress browser warnings, which can arouse suspicion and alarm.
It’s recommended that you configure your deployment with certificates signed by a third-party certificate authority (CA) as soon as possible. CA-signed certificates provide assurance to your users’ web browsers that your sites should be trusted. To obtain one, you make a certificate signing request (CSR) to the CA.
If you already have a CA-signed certificate, you can configure ArcGIS Server with the certificate, then import it into the portal.
You can also request a CA to sign a self-signed certificate, configure the new certificate with ArcGIS Server, then import it into the portal.
Note:
Ensure root and intermediate certificates are present
When a client application checks your CA-signed certificate, it must also validate the CA itself. This is done using root and intermediate certificates, which belong to the CA. The root certificate establishes the identity of the CA, and the intermediate certificate strengthens its credibility for issuing end-entity certificates such as yours. If the root and intermediate certificates are present, browsers and client applications can trust that your certificate was indeed signed by a valid CA.
ArcGIS Enterprise automatically trusts root and intermediate certificates signed by many popular CAs. If your organization is using a custom CA, or if you have a specific intermediate certificate you want to add to your deployment, you can use the importRootOrIntermediate operations in the ArcGIS Portal Administrator Directory and in the ArcGIS Server Administrator Directory.
Include a Subject Alternative Name in your certificates
Some browsers, including Google Chrome, do not trust certificates that don’t contain a subject alternative name (SAN, of which there can be multiple). If your ArcGIS Enterprise deployment is configured with certificates that don’t have a SAN value, users accessing your sites will receive trust warnings.
Certificates created by IT administrators will usually have one or more SAN values, but the Windows makecert command and the commonly used IIS Manager application do not provide the ability to configure a SAN. You should use an alternative tool to generate your domain certificates, which are signed by your organization’s internal CA.
If you are creating your own domain certificate on Windows, Esri provides a script to create a domain certificate that contains SAN values. Certificates generated using this PowerShell script can then be trusted by Chrome and other web browsers.
Understand and address the name mismatch issue
Because ArcGIS Enterprise may be deployed across multiple machines and potentially multiple domains or subdomains, it’s important to know the cause and potential solution to the name mismatch issue. This occurs when a user browses to a URL in a site that does not match the Common Name, or more recently a Subject Alternative Name value, provided by the site’s certificate. In other words, if the certificate presented by a web page is granted for a different URL than the one the user is accessing, the browser will flag an error.
As with self-signed certificates, users can choose to accept and trust the URL despite the error. But it is an alarming error for users who are unfamiliar with your site, as well as an inconvenience to encounter frequently.
It’s a best practice to immediately add each new domain and subdomain your organization uses, as SAN values to your CA-signed certificate. This proactive approach ensures users will not encounter name mismatch errors.
For example, consider an agency that deploys ArcGIS Enterprise components across two subdomains, https://water.example.com and electricity.example.com. The agency uses a CA-signed certificate, with SAN values matching “water.example.com” and “electricity.example.com.” They launch a new site at https://recycling.example.com. The IT administrator should add a “recycling.example.com” entry to the SAN parameter in the site certificate.
Scan for security issues using Esri scripts
To help you identify common security risks in your ArcGIS Enterprise deployment, Esri provides scripts checking for security best practices in your portal and server sites. The serverscan.py and portalscan.py scripts are built-in to the software and can be run at any time. Among the items examined by the scripts is a check for whether the component is using a self-signed certificate.
It’s helpful to run the scans shortly after installing each component, after upgrading to new versions, and after any significant changes to your deployment or its IT components. For example, you should rerun the serverscan.py script if your organization has recently replaced its server certificates or has changed the URLs of a site.