Setting up SSL |
|
Release 9.3 |
This topic describes how to set up your Internet Information Server (IIS) Web server to serve Web pages and other resources via Hypertext Transfer Protocol Secure (HTTPS). HTTPS is the standard approach for secure communications between client and server over the Internet. HTTPS enables the communication to be encrypted so that if it is intercepted, the third party cannot easily view and use the information. You should ensure that any sensitive information transferred to your server is secured through HTTPS. Any login should use HTTPS, as should pages that transfer data that you do not wish to be viewed by parties other than the end user.
To serve pages and other resource via HTTPS, you must obtain and install a certificate for Secure Sockets Layer (SSL) on the IIS server. Normally you obtain the SSL certificate from a certificate authority (CA) that is generally recognized by browsers and other Internet-capable client software. If the certificate is issued by a CA that is recognized by the browser, the communication with the server occurs with no special action required by the user. Hence for production servers, obtaining a CA-issued certificate is highly recommended. See Obtaining and installing an SSL certificate from a certificate authority for information.
Once you have an SSL certificate installed, you can access Web pages and other resources on the server using HTTPS. If the resource carries sensitive information, it is recommended that you require clients to use HTTPS to use the resource. See Requiring the use of HTTPS for details.
For development and testing purposes, using a self-signed SSL certificate may be adequate. Browsers and other clients will not automatically accept such certificates and will display a warning message for the certificate. See Using a self-signed SSL certificate for details.
This section outlines the procedure for obtaining and installing an SSL certificate from a certificate authority (CA). For complete information, please consult your system administrator, outside consultant, or other resources on security. See this page at Microsoft for more information on using SSL in IIS: Using SSL to Encrypt Confidential Data.
After the certificate is installed, clients can access pages and other resources using the HTTPS protocol. You can also require that HTTPS be used when accessing a resource.
If you later need to remove an SSL certificate, please refer to IIS documentation on tools such as HTTPCfg (for Windows XP/Server 2003) or netsh (for Vista/Server 2008).SSL requests to the Web server are sent to a specific port on the server. A port (or TCP port) tells the destination machine what program will handle the request. By default, Web servers handle SSL requests on port 443. If the default port is used, then clients do not need to specify the port in the request. If a non-default port is set on the Web server, then URLs must include it, for example, https://gis.example.com:8443/mywebapp.
You can use a non-default SSL port for your IIS Web site, but you should set it before installing ArcGIS Server (specifically, the ArcGIS Server Web applications, or ArcGIS instance). If you install your ArcGIS Server instance, and then configure SSL to non-default port, you may need to update the SSL port value in ArcGIS Server. Likewise, if you change the SSL port after configuring security for your ArcGIS Server, then you will need to update ArcGIS Server with the new port number.
You only need to update the SSL port in ArcGIS Server if you have enabled or intend to enable security for GIS Web services, and the security will use tokens. The services security will use tokens if you store users in SQL Server or a custom provider.
To update the ArcGIS Server instance with a new or non-default SSL port number:
<add key="SSLPort" value="443" />
You should require clients to use HTTPS to access Web pages and resources with sensitive data. This includes login pages but may also include whole Web applications.
Using HTTPS adds overhead to communications between client and server. Use or require HTTPS only for resources that should not be disclosed to third parties.
If you want to require HTTPS for an ArcGIS Server service or folder, you can use ArcGIS Server to require HTTPS. For details, see Requiring HTTPS for folders and services in the topic Securing Internet connections to services.You can also use the IIS Web server to require HTTPS (SSL) for a Web application, Web page or other resource:
Note that if clients request a page or resource via HTTP when it requires HTTPS, they are not automatically redirected to the HTTPS URL of the resource. It is possible to programmatically redirect such requests (search Internet resources for a variety of developer resources), but no out-of-the-box tools are available. Make sure your users are aware that they need to use https:// to access the resource.
For development and testing, a self-signed SSL certificate may be adequate. Using a self-signed certificate is not recommended for production sites. Browser users will see a security warning when loading a resource from a site that uses a self-signed certificate. You should not trust any self-signed certificate unless you are certain of the identity of the server and organization you are connecting to. In addition to browser issues, some server applications may have problems working with self-signed certificates. Some tips are included in the steps below for some server applications, but for other types of applications, you may need to install the certificate for the server in a way that the server and application recognize it.
Self-signed certificates can be generated in a number of ways. Consult texts on security, security experts, or Web sites for options.
On Windows Server 2008 and Windows Vista, the IIS Manager has a built-in tool for generating a self-signed SSL certificate.
For Windows Server 2003 and Windows XP, the following procedure uses the SelfSSL tool in the IIS 6.0 Resource Kit to create and install a self-signed SSL certificate.
Download and install the IIS 6.0 Resource Kit from Microsoft.
Install at least the SelfSSL tool. Other tools are optional.
This tool is supported on Windows Server 2003 and Windows XP. Other platforms may require a different tool.
b) Type the command to create and install a certificate. This example creates a certificate good for 365 days, for the server as www.example.com, and which will be trusted by the local browser:
SelfSSL /V:365 /N:CN=www.example.com /T
The name (N) argument must be set to the name that users will enter for the server. See the SelfSSL Help for more information on options, such as installing on a nondefault IIS Web site.
The certificate will only be recognized when requested with the
name as specified with the N argument above (or the machine name,
if N is not specified). For example, if the machine name "myserver"
default is used and the client requests the page with the fully
qualified domain name "myserver.example.com", the client will warn
that the name on the certificate does not match the request.
Installing the self-signed certificate on client computers
With a self-signed certificate, the client will display a warning at the start of each session with the server. If you create a Web ADF application that uses a secured service on a server with a self-signed certificate, the service may not work in the application. To avoid these security warnings and issues, you can export the certificate from the server and import it at client machines. This should only be done for internal test and development purposes, not for production sites. To export the certificate:
Once the certificate is available, import it at a client machine.
On Windows XP and Server 2003:
On Windows Vista or Server 2008:
Once you perform these steps, Internet Explorer and other IE-based clients can use https with the server without warnings. Browsers other than Internet Explorer may require a separate acceptance of the certificate.
If the GIS Web services will be access from an ArcGIS Server Java Web ADF application, you will need to install the certificate into the Java Manager's Java Runtime Environment (JRE), using the keytool. Any redeployment of the application to a different Web server will require adding the certificate to the Web server's JRE.