In this topic
- Creating an SSL certificate
- Binding the certificate to the website
- Testing your site
The SSL protocol is a standard security technology used to establish anencrypted link between a web server and a web client. SSL facilitates secure network communication byidentifying and authenticating the server as well as ensuring theprivacy and integrity of all transmitted data. Since SSL prevents eavesdropping on or tampering with informationsent over the network, it should be used with any login orauthentication mechanism and on any network where communicationcontains confidential or proprietary information.
To encrypt communication between the ArcGIS Web Adaptor and Portal for ArcGIS, the use of Secure Sockets Layer (SSL) on port 443 is required. No other port can be used. The use of SSL ensures that names, passwords, and other sensitive information cannot be deciphered as they are sent between the Web Adaptor and the portal. When you use SSL, you connect to your web pages and resources using the HTTPS protocol instead of HTTP.
You need to obtain an SSL certificate and bind it to the website that hosts the Web Adaptor. Each web server has its own procedure for loading a certificate and binding it to a website.
Creating an SSL certificate
To be able to create an SSL connection between the Web Adaptor and your portal, the web server requires an SSL certificate. An SSLcertificate is a digital file that contains information about theidentity of the web server. It also contains the encryptiontechnique to use when establishing a secure channel between the webserver and the portal. An SSL certificate must be created by theowner of the website and digitally signed. There are three types of certificates—CA-signed, domain, and self-signed—which are explained below.
CA-signed certificates
Certificate authority (CA) signed certificates should be used for production systems, particularly if your deployment of Portal for ArcGIS is going to be accessed from users outside your organization. For example, if your portal is not behind your firewall and accessible over the Internet, using a CA-signed certificate assures clients from outside your organization that the identity of the website has been verified.
In addition tobeing signed by the owner of the website, an SSL certificate may besigned by an independent CA. A CA isusually a trusted third party that can attest to the authenticityof a website. If a website is trustworthy, the CA adds its owndigital signature to that website's self-signed SSL certificate.This assures web clients that the website's identity has beenverified.
When using an SSLcertificate issued by a well-known CA, secure communication betweenthe server and the web client occurs automatically with no specialaction required by the user. There is no unexpected behavior or warning message displayedin the web browser, since the website has been verified by the CA.
Domain certificates
If your portal is located behind your firewall and using a CA-signed certificate is not possible, using a domain certificate is an acceptable solution. A domain certificate is an internal certificate signed by your organization's certificate authority. Using a domain certificate helps you reduce the cost ofissuing certificates and eases certificate deployment, since certificates can be generated quickly 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, since the website has been verified by the domain certificate. However, domain certificates are not validated by an external CA, which means users visiting your site from outside your domain will not be able verify that your certificate really 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 actually communicating with a malicious party and be turned away from your site.
Creating a domain certificate in IIS
In IIS Manager, do the following to create a domain certificate:
- In the Connections pane, select your server in the tree view and double-click Server Certificates.
- In the Actions pane, click Create Domain Certificate.
- In the Distinguished Name Properties dialog box, enter the required information for the certificate:
- For the Common name, you must enter the fully qualified domain name of the machine, for example, portal.domain.com.
- For the other properties, enter the information specific for your organization and location.
- Click Next.
- In the Online Certification Authority dialog box, click Select and choose the certification authority within your domain that will sign the certificate. If this option is unavailable, enter your domain certification authority in the Specify Online Certification Authority field, for example, City Of Redlands Enterprise Root\REDCASRV.empty.local. If you need help with this step, consult your system administrator.
- Enter a user-friendly name for the domain certificate and click Finish.
The final step is for you to bind the domain certificate to SSL port 443. See Binding the certificate to the website below for instructions.
Self-signed certificates
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 portal.
An SSL certificate signed only by the owner of the website iscalled a self-signed certificate. Self-signed certificates arecommonly used on websites that are only available to users on theorganization'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 really represents the party it claims to represent. You could actually be communicating with a malicious party, putting your information at risk.
When you first set up the portal, you might 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, beware that you will experience the following when testing:
- Web browser and ArcGIS for Desktop warnings about the site being untrusted. When a web browser encounters a self-signed certificate, it will typically display a warning and ask 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 are using the self-signed certificate. You should expect to see these type of warnings if you configure your portal with a self-signed certificate.
- Inability to open a federated service in the portal map viewer, adda secured service item to the portal, log in to ArcGIS Server Manager on afederated server, and connect to the portal from Esri Maps forOffice.
- Unexpected behavior when printing hosted services and accessing theportal from client applications.
- Inability to sign in to the portal from Esri Maps for Office unless the self-signed certificate is installed into the Trusted Root Certification Authorities certificate store on the machine running Esri Maps for Office.
Caution:
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 your portal.
Creating a self-signed certificate in IIS
In IIS Manager, do the following to create a self-signed certificate:
- In the Connections pane, select your server in the tree view and double-click Server Certificates.
- In the Actions pane, click Create Self-Signed Certificate.
- Enter a user-friendly name for the new certificate and click OK.
The final step is for you to bind the self-signed certificate to SSL port 443. See Binding the certificate to the website below for instructions.
Binding the certificate to the website
Once you've created an SSL certificate, you'll need to bind it to the website hosting the Web Adaptor. Binding refers to the process of configuring the SSL certificate to use port 443 on the website. The instructions for binding a certificate with the website vary depending on the platform and version of your web server. For instructions, consult your system administrator or your web server's documentation. For example, the steps for binding a certificate in IIS are below.
Binding a certificate to port 443 in IIS
In IIS Manager, do the following to bind a certificate to SSL port 443:
- Select your site in the tree view and in the Actions pane, click Bindings.
- If port 443 is not available in the Bindings list, click Add. From the Type drop-down list, select https. Leave the port at 443.
- If port 443 is listed, select the port from the list and click Edit.
- If port 443 is not available in the Bindings list, click Add. From the Type drop-down list, select https. Leave the port at 443.
- From the SSL certificate drop-down list, select your certificate name and click OK.
Testing your site
After binding the certificate to the website, you can configure your Web Adaptor for use with the portal. You will need to access the Web Adaptor's configuration page using an HTTPS URL such as https://webadaptor.domain.com/arcgis/webadaptor.
After you've configured your Web Adaptor, you should test that SSL is working properly by making an HTTPS request to the portal website, for example, https://webadaptor.domain.com/arcgis/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.
For more detail on testing your site with SSL, see the Microsoft instructions on how to set up SSL on IIS. To learn more about using SSL in your portal deployment, see Security best practices.
Feedback on this topic?
