The following examples show situations where Certificate Server typically grants certificates to users within an organization so they can conduct secure communications across the Internet and gain access to the corporate intranet:

  • Branch offices where the Internet supplements or serves as a corporate wide area network (WAN).
  • Supplier or vendor relationship where intranet access granted to groups of users from key partners.

The Certificate Authority (CA) issuing the certificates can implement policies tailored to each particular case. An example of such a system would include the following:

  • Use an authenticated network session to receive certificate requests and transmit completed certificates.
  • Check that the Issuer Organization and Issuer Organizational Unit information, specified in certificate requests, correctly identifies the CA server organization (defined in the CA server configuration file).
  • Check that the Subject Common Name information specified in certificate requests matches the server name. The server name must be a DNS resolvable name.

Microsoft Certificate Server is designed for Web-based applications that require authentication and secure communications based on the Secure Sockets Layer (SSL) protocol.

Certificate Server can also support other certificate-based applications, such as secure e-mail like Secure/Multipurpose Internet Mail Extensions (S/MIME), a secure payment such as Secure Electronic Extensions (SET), and digital signatures like Microsoft Authenticode. In the case of SSL, an organization can use the certificate server to issue both server and client certificates in a standard X.509 version 3.0 format.

At the most basic level, the role of Certificate Server is to receive a PKCS #10 certificate request, verify the information in the request, and issue a corresponding X.509 certificate (or, possibly, certificate chain) in a PKCS #7 format. In the case of a user who wants to obtain a certificate for a Web browser, visiting a Web site and enrolling for a certificate typically generates a certificate request.

To enroll, the user enters identifying information (for example, name, address, e-mail) into an HTML form. Next, a key pair is generated, and the public key is sent to a PKCS #10 to the CA. If all identifying information meets the CA criteria for granting a request, the Certificate Server generates the certificate, which is downloaded to the user's browser.