When you create a Web listener that listens for HTTPS requests,
you must provide a digital certificate that is installed on
Microsoft Internet Security and Acceleration (ISA)
Server 2006, to be used by the listener. ISA Server checks
what certificates are available on the computers running ISA Server
services, and displays a list of certificates for you to select
from while creating the listener. This topic describes how the list
of certificates is generated.
ISA Server looks in the local computer certificate store to
create the list of certificates. Each certificate's validity is
checked according to the following criteria:
Common name. The common name on the certificate must
match the public name of the Web site being published. The common
name of a certificate refers to the identity that the certificate
is supposed to be verifying. This identity must match the identity
that the client is expecting to receive. For example, if ISA is
publishing the internal site msweb under the public (externally
accessible) name of msweb.microsoft.com using client-side Secure
Sockets Layer (SSL), when a user types
https://msweb.microsoft.com into a browser, the browser will
expect to receive a certificate from ISA Server with a common name
that matches what the user typed: either msweb.microsoft.com or
*.microsoft.com. (The asterisk, or *, is part of a wildcard
certificate that will match any subdomain of microsoft.com.)
Server certificate. There are many types of certificates
possible, but a server certificate is necessary to establish an SSL
connection.
Expiration date. The certificate's expiration date must
be in the future. Certificates bind an identity to a particular
public key that is bound to a private key. Security is guaranteed
only as long as the private key is not known to an adversary. Thus,
certificates have an expiration date so that a compromised private
key does not permanently affect the security of a server. Browsers
will typically display a warning when receiving a certificate from
a server after its expiration date, although users can choose to
ignore this warning.
Validity date. The certificate's Valid-from date must be
in the past.
Private key. ISA Server must have a private key that
matches the public key in its certificate. Certificates bind
identities to public keys. Public keys are derived from private
keys mathematically by a special algorithm that is difficult to
reverse. (For example, it is statistically impossible to determine
the private key that generates a particular public key with
knowledge of only the public key and the algorithm used to generate
it.) Private keys are used to encrypt information over an SSL
connection, and public keys are used to decrypt that information. A
private key is not strictly part of a server certificate. However,
ISA Server will be unable to transmit encrypted information to the
client without the matching private key of the certificate used to
establish the connection with the client.
Array member installation. For Enterprise Edition, ISA
Server checks whether valid certificates have been installed on all
array members. When using an array of ISA Server computers to
publish a Web site, a valid certificate must be installed on all
array members.
Get
latest ISA Server content at ISA
Server Guidance.
Send
feedback about this page.