To secure network communication between the ArcGIS Web Adaptor and ArcGIS Enterprise organization, use the HTTPS protocol.
The HTTPS protocol is a standard security technology used to establish an encrypted link between a web server and a web client. HTTPS facilitates secure network communication by identifying and authenticating the server as well as ensuring the privacy and integrity of all transmitted data. Since HTTPS prevents eavesdropping on or tampering with information sent over the network, it should be used with any login or authentication mechanism and on any network where communication contains confidential or proprietary information.
The use of the default HTTPS port 443 is appropriate for the vast majority of deployments. In rare cases, an ArcGIS Web Adaptor instance cannot use port 443 on its web server for organization-specific reasons. If this applies to your organization, see Use nondefault ports for the portal's ArcGIS Web Adaptor, which details additional steps to configure a workaround.
Enabling HTTPS on a web server requires a server certificate containing a public and private key. Each web server has its own method for importing or referencing a certificate in an HTTPS listener.
Also ensure that your web server is set to ignore client certificates to access secure services over HTTPS unless web-tier authentication through PKI-based client certificate authentication is configured.
Create or obtain a server certificate
To create an HTTPS connection between ArcGIS Web Adaptor and the organization, 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 organization. A certificate must be created by the owner of the website and digitally signed. There are three types of certificates—CA-signed, domain, and self-signed—which are explained below.
Certificates signed by an independent certificate authority (CA) assure clients that the identity of the website has been verified. A certificate authority is usually a trusted third party that can attest to the authenticity of a website. If a website is trustworthy, the certificate authority adds its own digital signature to that website's self-signed certificate. This assures web clients that the website's identity has been verified.
Use CA-signed certificates for production systems, particularly if your ArcGIS Enterprise organization is going to be accessed from users outside your organization.
When you use a certificate issued by a well-known certificate authority, secure communication between the server and the web client occurs automatically with no special action required by the organization administrator or clients who access it. There is no unexpected behavior or warning message displayed in the web browser, because the website has been verified by the certificate authority.
If the organization is located behind your firewall and you are unable to use a CA-signed certificate, use a domain certificate. A domain certificate is an internal certificate signed by your organization's certificate authority. Using a domain certificate helps you reduce the cost of issuing certificates and eases certificate deployment, because certificates can be generated within your organization for trusted internal use.
Users within your domain will not experience any of the unexpected behavior or warning messages normally associated with a self-signed certificate, because the website has been verified by the domain certificate. However, domain certificates are not validated by an external certificate authority, which means users visiting your site from outside your domain will not be able to verify that your certificate represents the party it claims to represent. External users will see browser warnings about the site being untrusted, which may lead them to think they are communicating with a malicious party and be turned away from your site.
A certificate signed only by the owner of the website is called a self-signed certificate. Self-signed certificates are commonly used on websites that are only available to users on the organization's internal (LAN) network. If you communicate with a website outside your own network that uses a self-signed certificate, you have no way to verify that the site issuing the certificate represents the party it claims to represent. You could be communicating with a malicious party, putting your information at risk.
Creating a self-signed certificate should not be considered a valid option for a production environment, as it will lead to unexpected results and a poor experience for all users of the organization.
When you set up the organization, you can use a self-signed certificate to do some initial testing to help you quickly verify that your configuration was successful. However, if you use a self-signed certificate, you will experience the following when testing:
- You will receive warnings about the site being untrusted when you access the organization from a web browser or desktop client.
When a web browser encounters a self-signed certificate, it typically displays a warning and asks you to confirm that you want to proceed to the site. Many browsers display warning icons or a red color in the address bar as long as you use the self-signed certificate. Expect to see these types of warnings if you configure the organization with a self-signed certificate.
- You cannot open a federated service in a map viewer, add
a secured service item to the organization, sign in to ArcGIS Server Manager on a
federated server, or connect to the organization from ArcGIS for Office.
To allow you to sign in from ArcGIS for Office, install the self-signed certificate to the Trusted Root Certification Authorities certificate store on the machine running ArcGIS for Office.
- You may experience unexpected behavior when printing hosted services and accessing the organization from client applications.
The above list of issues you will experience when using a self-signed certificate is not exhaustive. It is recommended that you use a domain certificate or CA-signed certificate to fully test and deploy an ArcGIS Enterprise organization.
Create an HTTPS listener
An application's ability to listen on privileged ports (1 through 1023) is typically restricted to those processes run by the root user. There are several ways to avoid running the web server as the root user. The following are examples:
- Add the CAP_NET_BIND_SERVICE capability to the service unit file or set on the application binary.
- Use the authbind package to allow a process or set of processes to listen on a particular port.
- Run the web server listener on a nonprivileged port and use firewall rules to reroute packets sent to the standard HTTP/HTTPS ports (80/443) to nonprivileged ports (for example, 8080/8443).
For more information, consult your web server's documentation.
When creating an HTTPS listener, the user running the web server will require permission to access the server certificate used for TLS communications on the specific port. If the HTTP listener is functional, but the HTTPS is not available, the web server log will indicate the reason the listener failed to bind to the port.
Test your site
After obtaining or creating a certificate that is bound to port 443, configure the Web Adaptor for use with the organization. You must access the ArcGIS Web Adaptor configuration page using an HTTPS URL such as https://webadaptorhost.domain.com/webadaptorname/webadaptor.
After you configure the Web Adaptor, test that HTTPS is working properly by making an HTTPS request to the organization, for example, https://webadaptorhost.domain.com/webadaptorname/home. If you are testing with a self-signed certificate, dismiss the browser warnings about untrusted connections. This usually involves adding an exception to your browser so that it will allow you to communicate with the site that is using a self-signed certificate.