Verisign Solutions for Securing Multiple Web Server and Domain Configurations

White Paper

VeriSign Solutions for Securing Multiple Web Server and Domain Configurations

VERISIGN SOLUTIONS FOR SECURING MULTIPLE WEB SERVER AND DOMAIN CONFIGURATIONS

As organizations and service providers enhance their Web sites and extranets with newer technology to reach larger audiences, server configurations have become increasingly complex. They must now accommodate multiple domains and subdomains, load balancing requirements, and SSL digital certificates to support authentication and encryption capabilities. This paper covers the usage of VeriSign SSL certificates for organizations securing multiple Web servers and/or multiple domains and subdomains.

Executive Summary For the Internet to fulfill its potential as a vehicle for commerce and electronic communications there must be a basic and commonly accepted framework for trust and security. Today, SSL certificates form that basis in most e-commerce applications, providing the following to end-users:

· The Right Site: Assurance that users are indeed doing business with a particular site · The Right Company: Positive identification of the organization with which users are communicating · Company’s Ongoing Existence: Representations regarding the existence of the organization and that it is a legitimate business · Privacy: Encryption of information exchanged online

To provide these functions, SSL certificates must be used in particular ways in specified configurations. Basic trust principles require careful consideration in using SSL certificates.

This document clarifies the proper use of SSL certificates in special network configurations, including:

1. Redundant server backups 2. Organizations running multiple servers to support multiple site names 3. Organizations running multiple servers to support a single site name 4. Service providers using virtual and shared hosting configurations

VeriSign’s recommendations for each of these scenarios involve a unique certificate per domain name per server where feasible. In shared hosting environments, VeriSign requires that service providers clearly understand both the implications involved with allowing third parties to use their certificate for securing e-commerce transactions and the limitations placed on the benefits that merchants would normally receive as part of a regular SSL certificate offering from VeriSign.

To specifically address the needs of service providers with large deployments of shared hosting customers, VeriSign will soon offer a Shared SSL authentication service for individual merchants and domains that will operate from a single shared certificate.

I. VeriSign Server IDs: Encryption and Authentication VeriSign is the leading supplier of trust services for the Internet and boasts the industry’s most thorough authentication practices available, as detailed in its Certification Practice Statement (www.verisign.com/repository/cps/). VeriSign is the only certification authority (CA) to pass the rigorous SAS 70 Type II Audit, which is performed annually by the consulting firm KPMG. VeriSign has been issuing SSL certificates, also called VeriSign Server IDs, since 1995. As a result, its authentication practices have evolved due to the experience of issuing nearly a quarter of a million Server IDs.

VeriSign’s practices ensure that sites utilizing Server IDs can offer their Web site visitors the highest degree of security and assurances when communicating over the Internet and passing sensitive information to their Web site or server. Once an organization has satisfied VeriSign’s authentication requirements, VeriSign will issue the Server ID, which provide two essential security components: encryption and authentication.

Encryption VeriSign Server IDs enable Secure Sockets Layer (SSL) technology, which encrypts communications between a Web server and a customer’s browser. SSL ensures that all communications between the client and server are virtually impenetrable to outsider attack and unavailable for any third party to access, intercept, or monitor.

Authentication An equally important feature of VeriSign Server IDs is that they assure end users of the identity of the organization to which they will be providing (and hence entrusting) sensitive data. Authentication assures Internet users that they are indeed communicating with the company (and domain name) listed in the certificate, not with an imposter spoofing the Web site to steal information from unsuspecting Web site customers. Authentication also allows end users to know precisely to whom they are entrusting their confidential information. For e-commerce Web sites, authentication provides end users with the name of the company that will be responsible for processing their payment and fulfilling their order. VeriSign enables this trust between Internet merchants and their customers by following very rigorous validation procedures when issuing Server IDs. These procedures include verifying the following facts:

· The company owns or has the right to use the domain name of its Web site. · The company has provided proof that it has the right to do business under the name listed in the Server ID. · The individual requesting the Server ID is authorized to a request the certificate on behalf of the organization.

3 Note: Additional restrictions are imposed on users requesting strong encryption products (128-bit SSL), as these are subject to regulations by the United States Bureau of Export Administration. VeriSign also offers its customers the NetSure Protection Plan with each Server ID. NetSure is an extended warranty program that protects VeriSign Server ID customers against economic loss resulting from the theft, corruption, impersonation, or loss of use of the VeriSign Server ID. NetSure is backed by Lloyd’s of London, one of the world's largest, A-rated insurance confederations. VeriSign Server IDs each come with up to $250,000 of NetSure Protection.

VeriSign Server IDs provide the basis for trust on the Internet. VeriSign Server IDs were the first certificates commercially used on the Internet, and they are now in use at hundreds of thousands of Web sites. The importance of certificates is growing at an extremely fast rate. In fact, many state and national governments have already passed legislation that make digital signatures created with digital certificates issued through a licensed certification authority the equivalent of hand-written signatures. VeriSign is currently licensed as a CA in eight states in the United States as of March 2000.

II. Multiple SSL Certificate Implementations Several important elements in a certificate help ensure security and authenticity, as shown in Figure 1.

Figure 1: Important Elements in a Certificate

These elements contribute three fundamental trust principles to digital certificates.

1. Client applications, such as Web browsers, must be able to verify that the site the user is visiting is the site that has been certified. In practice, this means that the URL of the site matches the common name of the certificate that the site presents to the client application (usually, the site’s fully qualified domain name, such as www.samplecompany.com). 2. There must be tight binding between the organization listed in the certificate and the organization running the site. In practice, this means that the organization listed in the certificate should have the right to use the domain name in the common name and should be the entity with which the client is ultimately communicating or conducting business. It also means that the organization must have authorized the issuance of the certificate for a particular site. 3. There must be strong protection for the private key that corresponds to the certificate. In an SSL session, the client will use the public key in the certificate to send information to the server, which will ultimately be used to secure the session. Because any information encrypted with the server’s public key can be decrypted using the server’s private key, any configuration that compromises the server’s private key must be avoided.

Typically, implementing digital certificates for SSL is a fairly straightforward process, as one SSL certificate is required per domain name per Web server. However, some SSL certificate implementations frequently cause confusion and sometimes violate one or more of the above fundamental principles of secure e-commerce.

Private key security is fundamental to the security of SSL. Using the same certificate on multiple physical servers requires generating multiple copies of the same private key and storing those keys in multiple locations. When a private key is created and always stored in a single server, the key is reasonably well contained and auditable. When private keys are moved between servers, either by network or diskette, a new set of exposures and audit problems are created, increasing the likelihood of something going wrong and complicating the process of tracing who had access to a key in the event of compromise.

Following this logic, the chance of a problem arising increases significantly in relation to the number of servers in a given deployment. Therefore, VeriSign recommends that unique private keys are used on every server in a multi-server deployment, and that the private keys are generated from the hosting server. RSA announced prescriptions for applications that are vulnerable to the adaptive chosen ciphertext attack on PKCS #1 v1.5. Prescription #1 included the recommendation that “different servers should have different key pairs.” See http://www.rsa.com/rsalabs/pkcs1/prescriptions.html, June 26, 1998.

Copying the same certificate to multiple machines or enabling it for multiple users is a practice commonly referred to as “certificate sharing” and does not comply with

5 recommended best practices. Table 1 presents an overview of some common shared certificate scenarios and how each scenario related to the three basic trust principles.

Site Strong Binding Strong Binding Strong Private Configuration between Site Between Site Key Protection and Certificate and Common Name Organization in Certificate Fail-Safe YES YES YES Backup If both sites are not live at the same time Load NO YES NO Balancing Will also cause If organization Multiple Sites browser name owns all sites with Different mismatch error in Common Names some cases on Multiple Physical Servers Load YES YES NO Balancing Multiple Sites with the Same Common Name on Multiple Servers ISP Shared NO NO YES SSL Offerings Unless it is clear Unless it is clear that the ISP is that the ISP is guaranteeing the guaranteeing the services for all services for all companies for companies for which it is hosting which it is hosting Web sites. Web sites.

Table 1: Overview of Common Certificate Sharing Configurations Following are detailed discussions for each shared certificate configuration and VeriSign’s recommendations for providing the highest level of security for both the organization deploying the server and the end user accessing it.

A. Fail-Safe Backup When running a Web site for e-commerce or other applications, it is essential that the site is operational 100 percent of the time to maximize revenue and to provide visitors with

6 the best experience possible. This practice is accomplished primarily through the use of redundant servers. Typically, both servers contain identical files and applications and are used one at a time. If one server goes down for any reason, the other automatically picks up the load.

VeriSign Recommendation Certificate sharing is permissible in this scenario. When a customer has a standby server under the same control as the primary server and this secondary server is not used unless the primary server is down, it is permissible to use the same certificate. In this case, the secondary server is purely for backup purposes: VeriSign encourages the backup of the private key and corresponding certificate. However, when the secondary server is not under the same control as the primary server such that the server administrator cannot retain control of the private key, a separate certificate should be used for each server.

B. Certificate Usage on Multiple Servers High-traffic sites frequently employ redundant physical servers to ensure high-quality service. An increasingly common setup for higher-volume Web sites is to use a load balancing network device to distribute traffic to a farm of servers or to identical servers in different geographical locations. Common devices include round-robins, network switches, Cisco’s Local Director, and F5’s Big IP. Traffic distributors operate through the Domain Name Server (DNS) functions of the Internet. When a browser accesses a specific site, the site’s domain name is converted into an Internet IP address at a specific physical location. The traffic distributor intercepts this initial request and returns one of the IP addresses of the servers in the distributor’s farm or other company geographical locations. The distributor then redirects this initial traffic to a particular Web site location. The distributor selects the specific site based on several factors, including server load or operational state, browser location, and server location.

There are two basic configurations:

· The site has multiple physical servers, each of which hosts a virtual server with a slightly different hostname name (e.g.ww1.mycompany.com, ww2.mycompany.com , ww3.mycompany.com ). · The site has multiple physical servers, all of which have the same hostname (e.g. three servers are all called www.mycompany.com).

1. Varying Hostname Configurations In an environment where an organization is running multiple physical servers with different hostnames (e.g. ww1.mycompany.com, ww2.mycompany.com, ww3.mycompany.com), the organization should not try to secure all sites with the same certificate. This will cause a problem with the basic SSL set-up, as the client will detect that the URL of the site that it is visiting is different from the common name in the certificate.

7 VeriSign Recommendation Create a different certificate for each different physical server/fully qualified domain name combination. In situations where large numbers of servers must be managed, VeriSign’s OnSite for Server IDs solution can help reduce the administrative burden associated with running multiple certificates.

Exception Issue with Varying Hostname Configuration In some instances, the client (when using browser versions prior to Netscape 4.51 and IE 5.01) is presented with a dialog box (Figure 2) indicating that the domain name of the certificate does not match the domain name of the site being accessed. Most browsers are programmed to alert users of this potential security hazard. This dialog box may create the impression that the site is not secure, and so may prevent prospective customers from doing business with the site.

Figure 2: Certificate Mismatch Error Message

This situation can also occur in some configurations when multiple hostnames resolve to the same machine, for example, https://ww1.verisign.com and https://www.verisign.com.

VeriSign Recommendation In this case, the only current possible solution is to issue a “wild card” certificate of the form *.domain.com. VeriSign evaluates wild card certificate solutions for its customers on a case-by-case basis. For more information, please send e-mail to shared- [email protected].

2. Identical Hostname Configuration In this environment, multiple physical servers ensure high-availability service, but unlike the previous environment, all servers have the same hostname, or the common names for

8 the servers have not already been chosen and the administrator is not constrained by which names heor she can select for the servers.

VeriSign Recommendation Create a different certificate for each different server in the server farm. Since good PKI practices (and VeriSign’s internal systems) prohibit the issuance of two certificates with exact the same distinguished name, VeriSign recommends that each certificate have the same common name and the same organizational name, but slightly different organizational unit values.

For example:

Certificate 1 Certificate 2 Certificate 3 Hostname www www www Certificate www.mycompany.c www.mycompany.c www.mycompany.c Common Name om om om Certificate Mycompany, Inc. Mycompany, Inc. Mycompany. Inc Organization Field Certificate Machine Name 1 Machine Name 2 Machine Name 3 Organizational Server 1 Server 2 Server 3 Unit Field

Load Balancing For server farms that contain more than 10 servers, VeriSign recommends OnSite for Server IDs (http://www.verisign.com/server/prd/m/index.html). Server ID pricing is discounted from the SRP of retail Server IDs, and OnSite contains several features that enable simpler administration and management of multiple Server IDs.

For server farms with fewer than 10 servers, VeriSign recommends using the Secure Site Reseller Center at www.verisign.com/server/reseller/ and purchasing tokens for a discounted 5-pack of Server IDs. Each individual certificate will require individual processing and authentication.

Note: Organizations interested in using VeriSign’s strong-encryption Global Server IDs can obtain them through both OnSite for Server IDs and the Reseller Center. C. Shared SSL for Service Providers Many ISPs and Web host companies offer “Shared SSL” Web host plans as their entry- level plans for newer customers to the Internet. A shared SSL plan offers the use of a certificate that has been issued to the ISP and is typically registered to the ISP’s domain name: for example, http://secure.isp.com. Typically, entry-level customers are extremely price-sensitive, want ease of use, and are not interested in the technical requirements of their Web site. Additionally, the quantity of public IP addresses that ISPs have available sometimes limit ISPs that want to offer SSL IDS to their large shared hosting customer

9 bases. Additionally, some server software does not provide the functionality to allow dedicated certificates for virtual hosted customers.

However, the use of shared SSL reduces the overall trust delivered by the PKI implementation. This section explains common applications used by ISPs and VeriSign’s recommendations for ensuring that customer expectations are met when they are using shared SSL IDs.

Common Shared SSL Environments When a merchant at http://www.merchant.com uses a shared SSL certificate, it is often only for a payment page or another enrollment page that requires SSL to secure sensitive information. This secure page is primarily located at a different domain and/or server, such as https://secure.isp.com, or often at a specific directory on the ISP’s domain, such as https://secure.isp.com/merchant1/. When a merchant’s customers switch from a non- secure portion of the Web site to the secure section, they often do not notice that the implementing server and/or securing domain are changing unless they see the momentary “loading” message at the bottom of the browser (the URL at the top of their browser often does not change).

Transaction Liability However, the SSL certificate that is used to secure the transaction has been authenticated by the Certificate Authority with the ISP’s Organization Name, Organizational Unit and Common Name. Certificate-knowledgeable persons purchasing an item from the merchant over the SSL session understand that because the ISP has been authenticated for the Server ID securing the transaction, the ISP is responsible for processing the payment submitted to the Web site and for the fulfillment of any order that has been paid for through the Web site. In shared SSL applications, many end users think they are doing business with the merchant’s site (the URL is constant for the whole transaction) and are not aware that they are really doing business with the ISP’s site. In other words, users do not understand that the ISP is assuming liability for the transaction.

Warranty Protection Secondly, shared-SSL users forfeit any NetSure warranty protection that comes as a standard feature with all VeriSign Server IDs. Users receive up to $250,000 in NetSure protection, which guards against the fraud, misuse, theft or impersonation of their Server ID. However, the terms of the NetSure plan only include warranty protection for the organization listed in the certificate. In the event of a problem, the merchant would not be protected, as the certificate was issued to the ISP and not to the merchant. Furthermore, the ISP would not receive any protection, as the certificate was not being used by an organization other than the ISP.

Branding Benefits Thirdly, merchants using Shared SSL certificates are not able to take advantage of any of the value-added benefits that come with individual VeriSign Server IDs, including branding tools and other Web site services. Providing visual signs of assurance is vital to delivering trust to a merchant’s Web site customers, because it makes customers

10 comfortable in passing sensitive information over the Internet. VeriSign customers can leverage the VeriSign brand to make their customers feel even more confident doing business with their site, as the brand represents the site’s authenticity and is a sign familiarly linked to trust.

Note: As reported in a third-party survey by Cheskin/Sapient in 1999, VeriSign is a leading sign of trust on the Internet.

VeriSign’s Secure Site Seal allows a merchant’s customers to click the Seal and verify the certificate’s information and status in real time from VeriSign’s database. Also, every VeriSign customer who received their domain name from Network Solutions receives the VeriSign icon next to their listing in Network Solutions’ dot com directory, informing directory visitors that the site is secure. These important branding tools differentiate sites from their competitors that do not have a dedicated VeriSign Server ID securing their site.

VeriSign Recommendation VeriSign understands the purpose of shared-SSL plans for entry-level customers, both for ease of use and low cost. However, VeriSign does not want to educate less experienced Internet users about improper use of SSL and certificates, so the following requirements are included with the use of VeriSign SSL IDs in shared-SSL plans:

1. Merchants must communicate in writing to their customers that the site’s encryption is provided by their ISP and not by them. The ISP can accomplish this by providing the merchant with the ISP’s Secure Site Seal, which users can use to verify the SSL certificate for the Web site. 2. The ISP is responsible for guaranteeing that payment has been received and processed and for the fulfillment of any goods or of services that are rendered due after the transaction has been completed, unless other legal agreements are in place that state otherwise (VeriSign would have to review these documents to assure validity). 3. NetSure warranty protection is forfeited for merchants using shared-SSL plans. 4. ISPs must give merchants the opportunity to obtain a dedicated Server ID. 5. The ISP and VeriSign will work together to educate the merchant on the value of dedicated Server IDs. 6. The ISP may not charge the customer additional costs for using a VeriSign ID for shared SSL deployments.

VeriSign is confident that these requirements will address the needs of the ISP and their merchants, and still accurately communicate to merchants and their customers what level of security they are receiving on their transaction.

III. VeriSign Authentication Services Later in 2000, VeriSign will introduce Shared Hosting Authentication Services. These services allow ISPs to take advantage of the operating simplicity of using one Server ID per server to encrypt all communications for merchant customers virtually hosting on a

11 server. VeriSign will also allow the individual merchants to receive site authentication and to display a Seal indicating that they are VeriSign Authenticated Merchants.

When the merchant’s customers click on the Authenticated Merchant Seal, a splash page indicates that the merchant has proof of right to use the domain name and that it has authorized their service provider (ISP) to provide the SSL certificate for the site. Since the consumer is now made aware of this type of arrangement at the time of the purchase, the merchant can assume liability for the transaction and can take advantage of the NetSure Protection Plan.

For service providers, this service will address the limitations placed on the ISP from issuing dedicated certificates to each of their merchants, but will also provide a value- added service to the entry-level merchants looking to provide their customers with the highest degree of trust when conducting business with their Web site and establishing themselves as authentic.

For more information on this service, please e-mail [email protected].

IV. VeriSign Licensing Requirements The discussion above highlights a need to control the deployment of SSL certificates when securing multiple domains and Web servers to provide a trust infrastructure that can proliferate secure communications and e-commerce on the Internet. VeriSign has built these recommendations into the legal documents that form the basis for the VeriSign Trust Network, including:

1. Certification Practices Statement (CPS) 2. End User Subscriber Agreement 3. VeriSign ISP Program Agreement

Each of these are paraphrased with the relevant text below.

Certification Practices Statement (http://www.verisign.com/repository/cps/)

“7.3 Subscriber Duty to Prevent Private Key Disclosure: By accepting a certificate, the subscriber assumes a duty to retain control of the subscriber's private key, to use a trustworthy system, and to take reasonable precautions to prevent its loss, disclosure, modification, or unauthorized use.”

VeriSign Subscriber Agreement (http://www.verisign.com/repository/ssid_agree.html) The end user agrees to the Subscriber Agreement, when submitting its Server ID request for a certificate. The Subscriber Agreement states:

“1. Use Restrictions. You are prohibited from using your Server ID (i) for or on behalf of any other organization, (ii) to perform private or public key operations in connection

12 with any domain name and/or organization name other than the submitted by you during enrollment, or (iii) on more than one server at a time.”

Again, improper use automatically disqualifies customers from any coverage under the NetSure Protection Plan.

VeriSign ISP Program Agreement (http://www.verisign.com/repository/isp/agree_isp.html) “Use Restrictions. You and your Customer are prohibited from using your Customer’s Server ID (i) for or on behalf of any other organization, (ii) to perform private or public key operations in connection with any domain name and/or organization name other than the Customer’s name submitted by you during enrollment, or (iii) on more than one server at a time.

Software Piracy When offering Shared SSL, ISPs sometimes will charge end-user merchants for use of the VeriSign Server ID and the SSL that results from its deployment. This practice enables the ISP to profit from VeriSign’s product or service (the Server ID) and is similar to software piracy. Furthermore, this creates competitive issues in the ISP marketplace as Shared SSL providers typically offer their SSL plans for less than those that offer dedicated SSL IDs at suggested retail prices.

VeriSign does not support any behavior that resembles software piracy and takes violations of this type very seriously. Users are encouraged to report any known violations of VeriSign’s licensing requirements to [email protected], and service providers are not allowed to use VeriSign certificates in this fashion.

VeriSign is dedicated to promoting the highest trust available for e-commerce and is working with leading ISP and Web host companies to implement new products and services that enable the use of SSL while also addressing the special needs of service providers that have large customer deployments.

V. VeriSign Trust Network (VTN) Affiliates For customers located outside of the United States, please consult your local VeriSign affiliate to receive a copy of its policy for securing multiple servers and domains. Due to slightly differing product offerings and practices, specific recommendations from VeriSign affiliates may differ from the recommendations presented in this document.

VI. Conclusion SSL certificates form the basis for trust and security in most e-commerce applications by providing both encryption and authentication of the site and the company with which a client is communicating. As the Internet evolves and requires new configurations for securing high volume Web sites, for multiple domain names that resolve to one organization’s Web site, and for ISP and service providers that handle large deployments

13 of customers, VeriSign is committed to provide solutions that provide a solid trust infrastructure for the Internet, while addressing the specific needs of these new environments. VeriSign looks to continued participation from its customers, technology partners and service provider channels to guide future development of products and services that allow each Internet end-user to comfortably use the Internet as a secure medium for communicating and e-commerce.

VeriSign, Inc. 1350 Charleston Road Mountain View, CA 94043 Phone: 650-961-7500 Fax: 650-961-7300