Any communication sent over a computer network can potentially be intercepted, deciphered, or altered. To secure network communication in ArcGIS Monitor, 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.
There are several recommended best practices regarding server certificates. These best practices pertain to Monitor but should also be considered with other components of an enterprise GIS implementation.
Replace self-signed certificates with CA-signed certificates
Monitor Server is configured with a self-signed certificate by default. This certificate, which is signed only by the owner of a website, enables HTTPS communication without needing to perform additional steps. Most web browsers will not initially trust your Monitor 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 Monitor deployment 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 Monitor with the certificate.
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. The root and intermediate certificates (if necessary) must be present for browsers and client applications to trust that your certificate was signed by a valid CA.
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 Monitor 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 Microsoft Internet Information Server (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 Monitor may be deployed and accessed over 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 a SAN 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 all self-signed certificates, users can 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 that your organization uses as SAN values to your CA-signed certificate. This proactive approach ensures that users do not encounter name mismatch errors.
For example, consider an agency that deploys Monitor across two subdomains, https://water.example.com and https://electricity.example.com. The agency uses a CA-signed certificate with SAN values that match water.example.com and electricity.example.com. They launch a new subdomain at https://recycling.example.com. The IT administrator should add a recycling.example.com entry to the SAN parameter in the certificate.