Certificate selection for virtual host servers

A method, system, and apparatus are directed towards dynamically managing certificates for a virtual host server. A certificate may be uniquely associated with each of the websites hosted on the virtual host. In one embodiment, the certificate is an X.509 certificate. Also, the certificate may be managed by a network device residing between a client and the virtual host server. When the client that is browsing one of the hosted websites, the network device may store a persistence record that maps client information to the hosted website. The client may employ an SSL protocol to establish a secure connection. When a certificate associated with the hosted website is to be provided, the network device uses the persistence record to determine which hosted website the client was browsing, selects, and provides the appropriate certificate to the client.

FIELD OF THE INVENTION

The present invention relates generally to network communications, and more particularly, but not exclusively, to a system and method for managing secure connections for a virtual host server.

BACKGROUND OF THE INVENTION

The increasing popularity of the Internet has led to the emergence of online merchants, online libraries, and even online medical and insurance businesses, along with people who wish to share information with one or more of their friends. Each of these uses of the Internet may employ a website that is configured to enable access to information by others. Each of the website owners may also desire to provide secure communications and access to at least some of the information and activities associated with their website. Moreover, for various reasons, these website owners may desire to have a domain name that is uniquely associated with their website.

Today, websites may be made available using a variety of server implementations. For example, some individuals, and businesses, may select to implement a shared server to host their website. Such shared hosting of websites, also called virtual hosting, typically employs a server that is configured to host more than one domain name while sharing computing resources, such as bandwidth, memory, or the like. Such a configuration may, depending on the speed and configuration of the server, be able to host thousands of websites, each with individual domain names, but employing the same Internet Protocol (IP) network address.

However, many implementations of virtual hosting may have problems with respect to providing secure communications between an end-user and a hosted website. For example, a traditional method of providing secure communications between the end-user employing a web browser and a website is to establish an encrypted connection. Encrypted connections may be implemented using a variety of secure communication protocols, including Secure Sockets Layer (SSL) protocol, Transport Layer Security (TLS) protocol, or the like. These protocols typically include a handshaking procedure where the website may be authenticated by the client device. In one such procedure, the server device provides a digital certificate for the website to the client device.

In a virtual hosting environment, however, the particular hosted website that is to be requested may not be known during the handshaking procedure. Thus, the virtual host server may not know which digital certificate is to be provided for authentication of the hosted website. One proposed solution has been to assign a unique IP address to each of the hosted websites. However, because of the expense of registering and maintaining such global IP addresses, as well as other reasons, this solution may not always be appropriate. Thus, it is with respect to these considerations and others that the present invention has been made.

DETAILED DESCRIPTION OF THE INVENTION

Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment, though it may. As used herein, the term “or” is an inclusive “or” operator, and is equivalent to the term “and/or,” unless the context clearly dictates otherwise. The term “based on” is not exclusive and allows for being based on additional factors not described, unless the context clearly dictates otherwise. In addition, throughout the specification, the meaning of “a,” “an,” and “the” include plural references. The meaning of “in” includes “in” and “on.” As used herein, application layer refers to layers 5 through 7 of the seven-layer protocol stack as defined by the ISO-OSI (International Standards Organization-Open Systems Interconnection) framework.

Briefly stated, the invention is directed towards a system, apparatus, and method for dynamically managing certificates for websites on a virtual host server. A certificate may be uniquely associated with each of the websites hosted on the virtual host server. In one embodiment, the certificate is an X.509 certificate, such as those described in Request for Comments (RFC) 2459 available at the Internet Engineering Task Force's (IETF) website. In one embodiment, the certificates may be managed by a network device, such as a traffic management device, residing between a client and the virtual host server. When the client that is browsing one of the hosted websites opens a webpage that is configured to direct the client to establish a secure connection, the network device may store a persistence record associated with the client and the hosted website. The persistence record may include client information such as its source network address, including an IP address and/or a port address. The client may then be redirected to establish the secure connection. The redirection may include an HTTP status code that is sent by the hosted website or the traffic management device. During establishment of the secure connection, a certificate associated with the hosted website may be employed. The network device uses the persistence record to determine which hosted website the client was last browsing. The network device may then select and provide a certificate associated with the last accessed host website for use by the client to authenticate the hosted website. As used herein, it should be clear that a reference to a hosted website includes virtual hosting of any portion of a website. Moreover, although the invention is illustrated using hosted websites, the invention is not so limited. Thus, for example, the invention may be used for virtual hosted content sites, or other virtually hosted resource sites that employ a secure communication protocol using certificates, without departing from the scope or spirit of the invention.

The secure connection may be established using any of a variety of secure communications protocols that employ certificates, including SSL, TLS, or the like. The SSL protocol is described in Netscape Communications Corp, Secure Sockets Layer (SSL) version 3 (November 1996). The TLS protocol is derived from SSL, and is described in Dierks, T., and Allen, C., “The TLS Protocol Version 1.0,” RFC 2246 (January 1999), is available at the IETF website. As used throughout this application, including the claims, SSL refers to SSL, TLS, and all secure communications protocols derived therefrom.

By employing the persistence record to determine the certificate to provide to the client, associated with the present invention overcomes the problem that an HTTP header indicating which URI the client is seeking to access may not be available during the establishment of the secure connection. Without such knowledge about which URI the client is seeking to access during the secure connection, it would be unclear which certificate should be presented.

Illustrative Operating Environment

FIG. 1illustrates an environment in which the invention may operate. However, not all of these components may be required to practice the invention, and variations in the arrangement and type of the components may be made without departing from the spirit or scope of the invention.

As shown in the figure, system100includes client devices102-104, network105, traffic management device (TMD)106, and server108. Client devices102-104are in communication with TMD106through network105. TMD106is in further communication with server108. Also shown in the figure, server108includes a plurality of hosted websites Wa, Wb, and Wc. Although not shown, TMD106may be in communication with server108through a network infrastructure that is similar to network105. For example, in one embodiment, TMD106, and server108might reside within a common local area network type of infrastructure, although the invention is not constrained to such a configuration.

Generally, client devices102-104may include virtually any computing device capable of connecting to another computing device and receiving information. Such devices may also include portable devices such as, cellular telephones, smart phones, display pagers, radio frequency (RF) devices, infrared (IR) devices, Personal Digital Assistants (PDAs), handheld computers, wearable computers, tablet computers, integrated devices combining one or more of the preceding devices, and the like. Client devices102-104may also include other computing devices, such as personal computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network devices, and the like. As such, client devices102-104may range widely in terms of capabilities and features. For example, a client device configured as a cell phone may have a numeric keypad and a few lines of monochrome LCD display on which only text may be displayed.

In another example, a web-enabled client device may have a touch sensitive screen, a stylus, and several lines of color LCD display in which both text and graphics may be displayed. Moreover, the web-enabled client device may include a browser application enabled to receive and to send wireless application protocol messages (WAP), and/or wired application messages, and the like. In one embodiment, the browser application is enabled to employ HyperText Markup Language (HTML), Dynamic HTML, Handheld Device Markup Language (HDML), Wireless Markup Language (WML), WMLScript, JavaScript, EXtensible HTML (xHTML), Compact HTML (CHTML), and the like, to display and send a message. Moreover, the browser application may be configured to communicate over network105using a secure connection where the content may be encrypted. Thus, in one embodiment, the browser application may be configured to employ such communications procedures (protocols), including, but not limited, to SSL, TLS, or the like, to establish a secure connection.

Client devices102-104also may include at least one client application that is configured to receive content from another computing device. The client application may include a capability to provide and receive textual content, graphical content, audio content, alerts, messages, and the like. Moreover, client devices102-104may be further configured to communicate a message, such as through a Short Message Service (SMS), Multimedia Message Service (MMS), instant messaging (IM), internet relay chat (IRC), mIRC, Jabber, and the like, between another computing device, and the like.

In one embodiment, client devices102-104may be configured such that an end-user may operate the computing device to make requests for data and/or services from other computers on the network. In one embodiment, client devices102-104may employ a network interface unit (sometimes called a transceiver), such as described below, to communicate information with another computing device. Often, the requested data resides in computing devices such as server108. In this specification, the term “client” refers to a computer's general role as a requester of data or services, and the term “server” refers to a computer's role as a provider of data or services. In general, it is possible that a computer can act as a client, requesting data or services in one transaction and act as a server, providing data or services in another transaction, thus changing its role from client to server or vice versa. In one embodiment, at least one of client devices102-104is a computing device that is not operated by an end-user.

Network105may further include any of a variety of wireless sub-networks that may further overlay stand-alone ad-hoc networks, and the like, to provide an infrastructure-oriented connection. Such sub-networks may include mesh networks, Wireless LAN (WLAN) networks, cellular networks, and the like. Network105may also include an autonomous system of terminals, gateways, routers, and the like connected by wireless radio links, and the like. These connectors may be configured to move freely and randomly and organize themselves arbitrarily, such that the topology of network105may change rapidly.

Network105may further employ a plurality of access technologies including 2nd (2G), 2.5, 3rd (3G), 4th (4G) generation radio access for cellular systems, WLAN, Wireless Router (WR) mesh, and the like. Access technologies such as 2G, 3G, and future access networks may enable wide area coverage for mobile devices with various degrees of mobility. For example, network105may enable a radio connection through a radio network access such as Global System for Mobile communication (GSM), General Packet Radio Services (GPRS), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (WCDMA), CDMA2000, and the like. In essence, network105may include virtually any wired and/or wireless communication mechanisms by which information may travel between one computing device and another computing device, network, and the like.

Additionally, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, data signal, or other transport mechanism and includes any information delivery media. The terms “modulated data signal,” and “carrier-wave signal” includes a signal that has one or more of its characteristics set or changed in such a manner as to encode information, instructions, data, and the like, in the signal. By way of example, communication media includes wired media such as twisted pair, coaxial cable, fiber optics, wave guides, and other wired media and wireless media such as acoustic, RF, infrared, and other wireless media.

TMD106may include virtually any device that manages network traffic. Such devices include, for example, routers, proxies, firewalls, load balancers, cache devices, devices that perform network address translation, any combination of the preceding devices, and the like. TMD106may, for example, control the flow of data packets delivered to and forwarded from one or more servers, such as server108. TMD106may direct a request for a resource to a particular server based on network traffic, network topology, capacity of a server, content requested, and a host of other traffic distribution mechanisms. TMD106may receive data packets from and transmit data packets to the Internet, an intranet, or a local area network accessible through another network. TMD106may recognize packets that are part of the same communication, flow, and/or stream and may perform special processing on such packets, such as directing them to the same server so that state information is maintained. TMD106also may support a wide variety of network applications such as Web browsing, email, telephony, streaming multimedia and other traffic that is sent in packets.

TMD106may receive requests from one or more of client devices102-104. TMD106may select a website hosted on server108to forward the request. In one embodiment, each of the hosted websites may resolve to a single IP address. TMD106may also receive a response from the hosted website and provide the response to the requesting client device.

TMD106may also be configured such that a secure connection, such as an SSL connection, TLS connection, or the like, may be established between TMD106and one of client devices102-104. In one embodiment, the secure connection terminates at TMD106rather than continue through to server108. TMD106may store certificates for each of the websites virtually hosted on server108for use, at least in part, in establishing the secure connection. In one embodiment, the certificates are X.509 digital certificates. However, the invention is not constrained to certificates in this format, and other certificate formats may be employed, without departing from the scope or spirit of the invention.

TMD106may receive a request a secure webpage from one of client devices102-104. As part of its response, TMD106may store information associated with a website that the requesting client device had last accessed, prior to the client device being directed to establish a secure connection. TMD106may also store information about the requesting client device, including a source IP address, a source port address, or the like. When the client device requests the secure connection, TMD106may employ the stored information to identify and provide a certificate associated with the hosted website for the secure webpage. The client may then employ the provided certificate in part to authenticate the hosted website. TMD106may employ a process substantially similar to that described below in conjunction withFIG. 4to perform at least some of its actions.

TMD106may be implemented using one or more personal computers, servers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, radio frequency (RF) devices, infrared (IR) devices, integrated devices combining one or more of the preceding devices, and the like. Such devices may be implemented solely in hardware or in hardware and software. For example, such devices may include some application specific integrated circuits (ASICs) coupled to one or more microprocessors. The ASICs may be used to provide a high-speed switch fabric while the microprocessors may perform higher layer processing of packets. An embodiment of a network device that could be used as TMD106is network device200ofFIG. 2, configured with appropriate software. The BIG-IP® family of traffic managers, by F5 Networks of Seattle, Wash., are examples of TMDs.

Server108may include any computing device capable of communicating packets with client devices102-104through TMD106. Each packet may convey a piece of information. A packet may be sent for handshaking, i.e., to establish a connection or to acknowledge receipt of data. The packet may include information such as a request, a response, or the like. Generally, packets received by server108will be formatted according to TCP/IP, but they could also be formatted using another transport protocol, such as User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), NETbeui, IPX/SPX, token ring, and the like. Moreover, the packets may be communicated between server108, TMD106, and client devices102-104employing HyperText Transfer Protocol (HTTP), HTTPS, and the like.

In one embodiment, server108is configured to operate as a virtual host web server. That is, server108is configured to host more than one domain name or website, each using the same IP address. As shown, server108is virtually hosting websites, Wa, Wb, and Wc. However, the number of websites that server108is not constrained to three and more or less websites may be virtually hosted by server108, without departing from the scope of the invention. Moreover, at least one of the hosted websites includes a webpage that is configured such that communications with it are, at least in part, through a secure connection over a network.

However, server108is not limited to web servers, and may also operate a messaging server, a File Transfer Protocol (FTP) server, a database server, content server, and the like. Additionally, server108may be configured to perform different operations. Thus, for example, server108may be configured as a messaging server, and a database server. Thus, at least one of websites Wa, Wb, or Wc may represent other than a website. Moreover, while server108may operate as other than a website, it may still be enabled to receive an HTTP communication.

Devices that may operate as server108includes personal computers, desktop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, servers, and the like.

Although the above configuration illustrates certificate management and secure connection termination actions being performed within TMD106, the invention is not so limited. Thus, in one embodiment, the certificate management and secure connection termination actions may also be performed within server108, be distributed across server108and TMD106, or even be distributed across another network device, without departing from the scope or spirit of the invention.

Moreover, while only a singular server is illustrated in communication with TMD106, the invention is not so constrained. For example, a plurality of servers may be in communication with TMD106. Each of the servers in the plurality may in turn operate as a virtual host server, and/or provide other services as described above in conjunction with server108.

Illustrative TMD Environment

FIG. 2shows an exemplary network device200that may operate as TMD106ofFIG. 1. It will be appreciated that not all components of network device200are illustrated, and that network device200may include more or less components than those shown inFIG. 2.

As illustrated inFIG. 2, network device200includes a central processing unit (CPU)202, mass memory, and a network interface unit212connected via a bus204. Network interface unit212includes the necessary circuitry for connecting network device200to various networks, including network105ofFIG. 1, and is constructed for use with various communication protocols including the TCP/IP and UDP/IP protocol. Network interface unit212may include or interface with circuitry and components for transmitting messages and data over a wired and/or wireless communications medium. Network interface unit212is sometimes referred to as a transceiver, Network Interface Card (NIC), or the like.

In one embodiment, network device200includes one or more Application Specific Integrated Circuit (ASIC) chip226connected to bus204. As shown inFIG. 2, network interface unit212may connect to204bus through at least one ASIC chip. ASIC chip226can include logic that enables at least some of the actions of network device200. For example, in one embodiment, ASIC chip226can be employed to perform packet processing functions on incoming and/or outgoing packets. In one embodiment, ASIC chip226performs logic for network monitor220and/or redirect coordinator224. In one embodiment, network device200includes one or more field-programmable gate arrays (FPGA) (not shown), instead of, or in addition to, ASIC chip226. A number of actions for the network device can be performed by ASIC chip226, an FPGA, CPU202with instructions stored in memory, or any combination of actions performed by the ASIC chip, FPGA, and CPU.

Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include RAM206, ROM214, EEPROM, flash memory and/or any other memory architecture, CD-ROM, digital versatile disks (DVD) and/or any other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage and/or any other magnetic storage devices, and/or any other medium that can store information that can be accessed by a computing device.

Network device200may also include an input/output interface (not shown) for communicating with external devices or users.

Network device200can also be implemented as one or more “blades” where the term “blade” refers to one of multiple electronic circuit boards or cards that are installed in a hardware chassis with a backplane. An exemplary blade may include one or more processors, volatile and non-volatile memory, interfaces suitable for communicating information to and from the blade, and other components for enabling the operation of one or more applications. A blade may also include a specialized interface for the backplane and other interfaces, such as a USB port, FIREWIRE port, serial port, RF interface, IR interface, Ethernet interface, IDE controller, and the like. An application running on a blade may employ any of these interfaces to communicate information to other applications running on other blades and/or devices coupled to the blade server. Network device200can also be implemented as a combination of blades and additional components in the chassis.

The mass memory generally includes random access memory (“RAM”)206, read-only memory (“ROM”)214, and one or more permanent mass storage devices, such as hard disk drive208. The mass memory stores operating system216for controlling the operation of network device200. The operating system216may comprise an operating system such as UNIX, LINUX™, Windows™, or the like. In one embodiment, the mass memory may store program code and data for implementing Virtual Host Manager (VHM)220, persistence store222, and certificate store224.

Certificate store224is configured to store and manage certificates associated with each of the websites or domain names hosted on a virtual host server, such as server108ofFIG. 1. The certificates may include any of a variety of formats. For example, in one embodiment, the certificates employ the X.509 digital certificate format. Example embodiments of certificate store224are illustrated inFIG. 3, described further below.

Persistence store222is configured to store and manage information about a client device and which hosted website the client device last accessed. The information about the client may include any of a variety of information, including but not limited to a source IP address, a source port number, or the like. The information about which hosted website was last accessed may include a Universal Resource Indicator (URI) associated with the hosted website, a domain name, a port number associated with the hosted website, or the like. Moreover, the information included for the hosted website is sufficient to enable a mapping between the website and its certificate stored in certificate store224. Example embodiments of persistence store222are illustrated inFIG. 3, described further below.

VHM220is configured to manage, in part, the selection of a certificate for use in establishing a secure connection. When a client device, such as client devices102-104ofFIG. 1, sends a request for a secure webpage hosted on a virtual host server, VHM220determines which hosted website the client device is currently accessing. This may be determined, for example, by examining a URI request from the client device. VHM220may also examine various network information to determine an IP address, a port address, and the like, associated with the client device. VHM220may store the last accessed hosted website information, and client information in persistence store222. VHM220may then provide a redirect message to the client device that directs the client device to initiate a secure connection. In one embodiment, the redirect message may include a301, or302HTTP redirect status code, or the like. Such redirects may also include a URI to which the client is redirected.

In one embodiment, when the client device ‘calls back’ requesting a secure connection, it may employ an HTTPS protocol command, requesting that an SSL, TLS, or similar, secure connection be established. The request may employ, for example, an SSL handshake protocol.

As an example, one embodiment of an SSL handshake protocol is herein described. The example, however, is not intended to limit the invention. Such example SSL handshake protocol may include a sequence of communications, typically starting with an initial connection phase where both parties (the client device and network device200) communicate ‘hello’ messages. In one embodiment, the client device initiates the handshake sequence by sending a CLIENT-HELLO message. Network device200may receives the CLIENT-HELLO message, process it, and respond with a SERVER-HELLO message. As part of the SERVER-HELLO message VHM220may select and provide a certificate associated with the hosted website that the client device last accessed. VHM220may determine the appropriate certificate by receiving client information associated with the CLIENT-HELLO message, such as an IP address, port number, or the like. VHM220may then employ the client information to search persistence store222for the certificate associated with the hosted website the client device last accessed. VHM220may then provide the identified certificate for use in establishing the secure connection. To complete the SSL handshake, the client device, may generate a master key using information in the SERVER-HELLO message, and provide the master key to network device200in a CLIENT-MASTER-KEY message. Network device200may then send a SERVER-VERIFY message to the client device to enable the client device to authenticate network device200.

Although the SSL handshake protocol has been described, it should be clear that the invention is not limited to the SSL handshake protocol, and any of a variety of other protocols that may employ a ‘server-side’ certificate to establish a secure connection may be employed, without departing from the scope or spirit of the invention. In any event, VHM220may employ a process substantially similar to that described below in conjunction withFIG. 4to perform at least some of its actions.

In one embodiment, multiple client devices may employ a same source IP address. This may arise, for example, during a network address translation, use of a connection pool, or the like. In such situations, VHM220may also store information such as a port address associated with the hosted website that the client device last accessed. In this manner, each hosted website or domain name may have associated with it a unique port number. Thus, VHM220may employ destination port numbers to identify a website and to select and provide the appropriate certificate.

FIG. 3shows several embodiments of persistence stores and certificate stores that may be employed in the present invention. As shown, two possible embodiments are illustrated, stores300A and stores300B. Stores300A include persistence store322aand certificate store324a, while stores300B include persistence store322band certificate store324b.

Persistence store322aillustrates a mapping between client information302aand a virtual hosted website's information304a. Such client information is typically that information discernable prior to an SSL handshake. For example, as noted above, the client information may include source IP address, source port number, or the like. The client information may also include an IP Time To Live (TTL), TCP options useable at a session establishment time, a TCP timestamp advertised by a peer, or the like. Virtual hosted website's information304amay be a URI, domain name, or the like.

Client information302amay be mapped to virtual hosted website304a's information, when a client device seeks, for example, access to a secure webpage, source, or the like.

Certificate store324aillustrates a mapping between virtual hosted website's information304aand a digital certificate306athat is associated with the virtual hosted website. As stated above, one embodiment of digital certificate306ais an X.509 certificate.

In one embodiment, of the invention, certificate store324amay also include requirements (reqmnts)308athat indicate, a variety of requirements, and/or additional information associated with usage of the digital certificate. For example, in one embodiment, requirements308amay indicate whether virtual hosted website304amay request a client-side certificate during a secure communications handshake. Persistence store322billustrates another embodiment of a mapping between client information302band a virtual hosted website's information304b. As noted above, client information302bmay include any of a variety of information, including source IP address, source port number, or the like. Virtual hosted website's information304bas illustrated may represent a port number associated with a virtual hosted website. Client information302bmay be mapped to virtual hosted website304b's information, when a client device seeks, for example, access to a secure webpage, source, or the like. Moreover, certificate store324billustrates a mapping between virtual hosted website's information304band a digital certificate306bthat is associated with the virtual hosted website. Certificate store324bmay further include requirements (reqmnts)308bthat indicate, a variety of requirements, and/or additional information associated with usage of the digital certificate.

Generalized Operation

The operation of certain aspects of the invention will now be described with respect toFIGS. 4. Process400may be implemented, for example, within TMD106ofFIG. 1.

Process400begins, after a start block, at block402, where a request is received. In one embodiment, the request is an HTTP request for a webpage that is hosted on a virtual host server. This request may be forwarded by the TMD to the hosted website for which the requested webpage is associated. In one embodiment, a table mapping is employed to determine the address of the hosted website so that the request may be then forwarded by the TMD. Processing then continues to block404, where a response to the request is forwarded to the requesting client. In one embodiment, the response is received from the virtual host server, and forwarded to the requesting client. Processing then continues to decision block406, where a determination is made whether a request is received from the client indicating intent to access a secure webpage. This may take the form of a request for a webpage that is configured to direct the client to a secure webpage on the virtual host. In one embodiment, the request from the client includes a URI that the server or TMD associates with a response that directs the client to a secure webpage. In one embodiment, the request received at block402and the request at block406may be the same request. In another embodiment, the requests are different requests. In one embodiment, the webpage configuration includes an HTTP redirect instruction, which may be a META refresh HTML tag or an HTTP301or302status flag that is returned. In one embodiment, the virtual host server may provide the TMD with indication that the hosted webpage is secure; however, indication that the hosted webpage is secure may be obtained using a variety of other mechanisms. For example, in one embodiment, the client makes a request to a webpage that is arranged to redirect the client to the secure webpage. In any event, if a request for a secure webpage is not received, processing loops back to block402. However, if such a request is received processing flows to block408. It is noted, that although it is not illustrated, the client may select at any time to exit process400without requesting a secure webpage, requesting another webpage, or the like.

In any event, if processing flows to block408, information about the website for which the client is currently accessing is obtained. As described above, this information includes the application layer information (sometimes referred to as post-SSL-handshake information), such as the domain name or the URI, which then may be used to drive the decision to present a particular SSL certificate later on. In one embodiment, a key to this table might comprise pre-SSL handshake information, for example the IP address, source port number, or the like. For example, in one embodiment, such information may be stored with a specifiable client source address mask, or the like. Storing of the mask, or the like, is directed towards managing of mega-proxies that may proxy clients through a series of changing source addresses. In one embodiment, a destination port number associated with the hosted domain name (hosted website) may also be stored. In one embodiment, the client information is stored within a persistence store with the mapping to the information for the hosted secure website that the client may be redirected towards. The client information and mapping may then be used later to locate the domain name associated with the last accessed website for the client.

In one embodiment, the TMD receives from the client a request for a webpage having one or more links to a secure resource associated with the virtual host server. In response to receiving this request, the TMD sends to the client the webpage. After determining that the webpage includes at least one link to the secure resource associated with the virtual host server, the TMD stores the information about the website, described above.

Process400continues next to block410, where a redirect message may be sent to the client that indicates that the client is to ‘call back’, requesting that a secure connection be established. The redirect message may explicitly include the original IP address that the client used to access the server. In one embodiment, the redirect is in the form of an HTTP status code, such as301, or302. However, the invention is not so constrained, and other forms of redirection messages may be employed that direct the client to request the secure connection. Processing then proceeds to block412, where the client ‘calls back’ requesting the secure connection be established. In one embodiment, the ‘call back’ is in the form of an HTTPS protocol prompt that requests initiation over port443. Such ‘call back’ is directed at initiating the SSL handshake, or a similar process. Thus, in one embodiment, the ‘call back’ initiates a CLIENT-HELLO message. The CLIENT-HELLO message may have associated with it client information, such as the client's source IP address, source port number, or the like. Typically, the client information used to determine the appropriate certificate may not be present in the CLIENT-HELLO, but may be incidentally carried along in packet frames used to transport the CLIENT-HELLO. In one embodiment, the message also includes a destination port number for the hosted website. In any event, the client information sought is the client information that was obtained above, at block408.

Process400proceeds next to block414, where a determination is made using, in part, the client information to locate the hosted website that the client last accessed. In one embodiment, a destination port number may be employed to locate the hosted website. Once the hosted website that was last accessed is identified, a certificate associated with the hosted secured website may be located and retrieved. In one embodiment, the certificate is located within a store using the client information as a sort key. Processing continues to block416, where the certificate may then be presented to the client, in part, for use in authentication of the hosted secure website. In one embodiment, the certificate is provided to the client during the SSL/TLS handshake, as part of the SERVER-HELLO message. Process400continues next to block418, where the SSL handshake is completed to establish the secure connection. Process400then returns to a calling process to perform other actions. Such other actions may include, for example, sending and receiving communications between at least the TMD and the client using the secure connection.

It will be understood that each block of the flowchart illustration, and combinations of blocks in the flowchart illustration, can be implemented by computer program instructions. These program instructions may be provided to a processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified in the flowchart block or blocks. The computer program instructions may be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer implemented process such that the instructions, which execute on the processor to provide steps for implementing the actions specified in the flowchart block or blocks.