• Main Menu
  • The Certificate Enrollment Process


    While encryption can be a robust security technology, users have to implement a public key infrastructure (PKI) to make it beneficial and trusted within an organization. The Windows 2000 and Windows Server 2003 PKI implementation resides in Certificate Services. A public key infrastructure is the collection of technology, protocols, services, standards, and policies that control the issuing and management of public and private keys using digital certificates. Certificates are the core of the PKI. Encryption is used to protect data messages as they are transmitted over the network and digital signatures verify the identities of these messages’ senders. Public key encryption encrypts data. In public key encryption, each user has a private key that is kept secret and is never sent over the network and a public key that can be publicly distributed. The public and private key pair encrypts and decrypts data. The public key encrypts the data into an unreadable or scrambled format. Only the private key in the key pair can decrypt the data to a readable format.the certificate enrollment process

    Digital certificates distribute the public key. A digital certificate associates a public key with an entity such as an individual or organization because it contains the public key for the user or organization, additional information on the user or organization, and information on the entity that issued the certificate. The entities that issue and manage digital certificates are called certificate authorities (CAs). Nobody can forge certificates because the CA digitally signs the certificates and the signature is applied to a hash of the certificate.
    In Windows 2000, Windows XP, and Windows Server 2003, the Data Protection API deals with certificates. The X.509 standard, Public-key, and Attribute Certificate Frameworks specify certificate formats for PKI implementations. A digital certificate usually contains a version number that identifies the X.509 standard version used for the certificate, the certificate’s serial number, the CA that issued the certificate, the signature algorithm identifier that defines the CA’s algorithm used for the digital signature of the certificate, the certificate’s validity period, the entity to which the certificate was issued, the certificate’s intended uses, the user’s public key, and the certificate revocation list’s (CRL) location.

    To make certificates useful or trusted, users have to obtain a certificate from a trusted entity called a certification authority (CA). A CA issues and manages certificate use within the PKI. A CA can be an external third party such as VeriSign or users can deploy their own internal CAs. Users can also combine internal and external CAs. Users can consider the process of designing and deploying CAs as the initial step in implementing a PKI solution within the organization. Once the CAs are created, users can obtain a certificate from a CA manually or automatically.
    Manually requesting certificates from the CA occurs when the user explicitly asks the CA to issue a certificate. Certificates are automatically requested when an application requests and obtains a certificate as a background process, with no user intervention.

    An Overview of the Certificate Enrollment Process

    The terminology that describes the process whereby users request certificates is certificate enrollment. A user has to submit the request for a certificate in a special format. The format should be able to specify the identity of the user requesting the certificates. The CA issues the certificate only after the certificate requester is verified.
    The PKCS #10 standard, Certification Request Syntax Standard is usually the format used to submit certificate enrollment requests to the CA. The information included in a PKCS #10 certificate enrollment request is listed below:

    • The requester’s public key, which the CA should sign.
    • The distinguished name of the requester.
    • The digital signature, which is the hash of the request encrypted with the requester’s private key.
    • The hashing algorithm used for the creation of the digital signature.

    When a user submits a request to a CA for a certificate, the request is first sent to the Cryptographic Service Provider (CSP), which is installed on the user’s computer. The CSP creates the private and public key pair for the request. The public key is added to the other certificate request information and is then passed on to the CA.

    Once the CA receives the enrollment request, the CA performs the following tasks:

    • Decrypts the digital signature in the certificate request with the public key in the particular request.
    • Performs a hash on the request using the hash algorithm that the requester utilized. The identity of the requester or user that submitted the certificate enrollment request is validated when the hash that the CA calculated corresponds to the hash in the decrypted signature.
    • The CA then digitally signs the user’s public key.
    • It next adds this to an X.509 certificate.
    • The certificate is submitted to the user that requested certificate enrollment.
    • The user publicizes copies of its X.509 certificate to entities that can use it to encrypt data that will be transmitted to the user.
    • These entities authenticate the user’s X.509 certificate by verifying the digital signature that the CA added to the certificate.

    Windows Server 2003 certificate services provide the following certificate enrollment methods:

    • Automatic Enrollment
    • Web Enrollment
    • Manual Enrollment

    Before looking at the factors that influence the certificate enrollment method chosen, look at the types of CAs that can be configured.

    • Enterprise CAs: Enterprise CAs are integrated in Active Directory, and publish certificates and CRLs to Active Directory. Enterprise CAs can only issue certificates to users and computers within Active Directory. Enterprise CAs utilize the information in the Active Directory database to automatically approve or deny certificate enrollment requests.
    • Stand-alone CAs: Stand-alone CAs are not dependent on Active Directory to issue certificates to users. Therefore, if the user requests a certificate from a stand-alone CA, the request has to contain all the information on the user that the CA will need to process the certificate request. By default, stand-alone CAs do not automatically respond to certificate enrollment requests. However, users can configure stand-alone CAs to issue automated certificates.

    The certificate enrollment method chosen depends on the following factors:

    • The type of CA from which the certificate is being requested.
    • Whether the CA and user requesting the certificate can communicate over the network.

    Computers that are not connected to the network cannot use the auto-enrollment method. A requirement of the auto-enrollment method is that the certificate requester directly communicates with the enterprise CA.

    If requesting certificates from a standalone CA, use one of the following tools or utilities:

    • The Certificates snap-in: To use the Certificates snap-in to submit certificate requests to the CA, users need to have permissions to install and configure the Microsoft Management Console (MMC) snap-in.
    • The Certreq.exe command- line utility: This command-line tool is not ideal for end user use or to request certificates. The tool should be used to perform certificate administrative tasks that cannot be performed with Group Policy settings.
    • The Web enrollment possess: This is the simplest method that end users can use to request certificates from the CA.

    If requesting certificates from an enterprise CA, use one of the following tools or utilities:

    • The Certificates snap-in
    • The Certreq.exe command- line utility
    • The Web enrollment process
      When using one of the above methods, specify whether certificates must be manually approved or whether they can be auto-enrolled. To enable auto-enrollment, grant the Auto-enroll permission on the certificate template for those users and groups that should receive a certificate.
    • Group Policy: If running Windows XP and Windows Server 2003, use Group Policy to automatically enroll users and computers without any user intervention. The requirement is that Version 2 certificate templates are used for issuing certificates. The Auto-enrollment Settings policies configure auto-enrollment with Group Policy.

    The Automatic Enrollment Method

    Auto-enrollment makes it possible for an organization to configure the CA to automatically issue certificates to users and computers. Auto-enrollment can be defined as the process by which certificates can be obtained, updated, and stored for users and computers, without administrator and end user intervention.

    The auto-enrollment feature also enables the centralized management of certificates, including:

    • Certificate enrollment
    • Certificate renewal
    • Modifying certificates
    • Superseding certificates

    In a Windows Server 2003 PKI implementation, users can enable the auto-enrollment feature through:

    • Automatic Certificate Request Settings: This is a Group Policy setting located under the Computer Configuration/Windows Settings/Security Settings/Public Key Policies/Automatic Certificate Request Settings node in the Group Policy Object (GPO) Editor snap-in. Use Automatic Certificate Request Settings to issue certificates based on Version 1 certificate templates to computers running Windows 2000, Windows XP, or Windows Server 2003.
    • Auto-enrollment Settings: Auto-enrollment Settings utilize a grouping of Version 2 certificate templates and Group Policy settings to enable client computers running Windows XP and Windows Server 2003 to enroll user certificates or computer certificates automatically at user log on. The Group Policy setting for computer certificates is located under the Computer Configuration/Windows Settings/Security Settings/ Public Key Policies node, and the Group Policy setting for user certificates is located under the User Configuration/Windows Settings/Security Settings/Public Key Policies node. The default configuration is that user auto-enrollment and computer auto-enrollment are enabled. While this policy’s primary option is Enroll Certificates Automatically, users can choose to renew and revoke certificates automatically as well. Users can also select to update certificate template types automatically.

    The Web Enrollment Method

    In order for the Web enrollment method to be used, the Internet Information Server (IIS) service must be running on the CA server and the web request feature must be installed and enabled. The Web enrollment interface enables users to perform the following tasks:

    • Request a certificate from the CA
    • Request the CA’s certificate revocation list (CRL)
    • Request the CA’s certificate
    • Check a pending certificate request’s status
    • The Web enrollment interface can also be used for smart card certificate enrollment

    The Web enrollment feature utilizes the CertSrv directory that points at WindowsSystem32CertSrv, which contains the ASP pages and other files used for obtaining a certificate. In addition to this directory, the Web enrollment feature utilizes the CertEnroll directory that contains the Certificate Revocation List (CRL) that the CA issued and the CertControl directory that contains the ActiveX controls utilized for Web enrollment.

    The Manual Enrollment Method

    If one’s environment includes client computers running operating systems prior to Windows 2000, manually enroll these clients for certificates. This is because these older client operating systems do not include support for Group Policy, and therefore do not support the automatic enrollment method. Manual certificate enrollment can occur via the Certificates snap-in, the Certreq.exe command-line utility, or the Web based interface.

    When using the Web based interface for the manual enrollment method, IIS has to be running on the CA server. When Certificate Services is installed, the Web Enrollment application is automatically installed.
    Use the Certificates snap-in to manually request certificates from a computer that is configured as an enterprise CA. The snap-in includes the Certificate Request Wizard that guides the user through the certificate enrollment process.

    If the Certificates snap-in is used to request and obtain an Administrator certificate, users would be able to perform the following administrative tasks:

    • Encrypt data and e-mail messages
    • Digitally sign the certificate trust list and messages

    The Certreq.exe command-line utility enables users to script the certificate enrollment process. Users can also retrieve and accept certificate requests with this utility.

    How to Request a Certificate with the Web Enrollment Method

    1. Connect to the CA server with Internet Explorer 5.0 or above and the Administrator account.
    2. Use the following URL: http:// <servername>/certsrv.
    3. Enter the appropriate user name and password if one is not automatically authenticated.
    4. The Web based interface for manually requesting certificates opens and the Welcome page is displayed.
    5. Click the Request A Certificate option.
    6. On the following page, click Advanced Certificate Request.
    7. Click the Create And Submit A Request To This CA option.
    8. On the Advanced Certificate Request page, in the Certificate Template list, choose Basic EFS.
    9. Check the Enable Strong Private Key Protection checkbox.
    10. Click Submit.
    11. When the Potential Scripting Violation warning dialog box appears, click Yes.
    12. When the Creating A New RSA Exchange Key dialog box opens, click Set Security Level.
    13. Click High then Next.
    14. Enter a strong password in the Password and Confirm text boxes.
    15. Click Finish.
    16. Click OK.
    17. When the Certificate Issued page appears, click Install This Certificate.
    18. On the Potential Scripting Violation warning dialog box, click Yes.

    How to Request a Certificate with the Certificates Snap-in (manual enrollment)

    1. Click Start and Run and enter mmc in the Run dialog box. Click OK.
    2. From the File menu, click Add/Remove Snap-In.
    3. Click Add.
    4. When the Add/Remove Snap-In dialog box opens, click Certificates. Click Add.
    5. Click My User Account.
    6. Click Finish, Close, and OK.
    7. In the Certificates snap-in, expand Certificates and click Personal.
    8. Right-click Certificates, and on the shortcut menu, click All Tasks then click Request New Certificate.
    9. The Certificate Request Wizard starts.
    10. On the Welcome page, click Next.
    11. When the Certificate Types page appears, click User.
    12. Enable the Advanced checkbox. Click Next.
    13. When the Cryptographic Service Provider page opens, check the Enable Strong Key Protection checkbox. Click Next.
    14. On the Certificate Authority page, click Next.
    15. Enter a name in the Friendly Name text box. Click Next.
    16. On the Completing The Certificate Request Wizard page, click Finish.
    17. Click OK to install the issued certificate.
      /ol>

    How to Configure Auto-enrollment

    Before one can configure auto-enrollment, configure the domain controller as an enterprise root CA or as an enterprise subordinate CA.

    1. Use the steps below to configure the domain controller as an enterprise CA:
      1. Place the Windows Server 2003 CD-ROM in the CD-ROM drive.
      2. Click Install optional Windows components.
      3. Select Certificate Services in the Wizard Components page.
      4. When a message appears warning that the CA server’s name cannot be modified, click Yes to acknowledge the warning message. Click Next.
      5. In the CA Type page, select Enterprise Root CA. Click Next.
      6. Specify a common name for the CA.
      7. Specify a validity period for which certificates that the CA issued are valid. Click Next.
      8. Accept the default location settings for the database file and database log. Click Next.
      9. Click Yes if an ASP warning message is displayed in order to acknowledge the message.
      10. Click Finish.

      Use the steps below to configure the CA for auto-enrollment:

      1. Open the Certification Authority console by clicking Start, Administrative Tools, and Certification Authority.
      2. Right-click Certificate Templates and click Manage from the shortcut menu, this opens the certificate templates management tool.
      3. To create a certificate template for auto-enrolled users, right-click User Template and select Duplicate Template from the shortcut menu.
      4. When the Properties of the New Template dialog box opens, enter a name for the template in the Template Display Name field.
      5. Click the Security tab.
      6. Specify the users and groups that should be able to auto-enroll. Assign the users/groups the Enroll and Auto-enroll permission.
      7. Click OK. Close the certificate templates management tool.
      8. In the Certification Authority console, right-click Certificate Templates, click New, then click Certificate Template to Issue from the shortcut menu.
      9. Select the User Auto-enrollment certificate template.
      10. Click OK.
      11. Open the Active Directory Users and Computers console by clicking Start, Administrative Tools, then Active Directory Users and Computers.
      12. Right click the particular domain and select Properties from the shortcut menu.
      13. Select the Group Policy tab. Click Edit.
      14. Expand User Configuration, Windows Settings, Security Settings, then Public Key Policies.
      15. Double-click Auto-enrollment Settings.
      16. When the Auto-enrollment Settings Properties dialog box opens, ensure that the Enroll Certificates Automatically option is selected.
      17. Enable the Renew expired certificates, update pending certificates, remove the revoked certificates checkbox, and enable the Update certificates that use the certificate templates checkbox.
      18. Click OK to complete the certificate auto-enrollment configuration.

    Got Something To Say:

    Your email address will not be published. Required fields are marked *

    6 comments
    1. Brian

      7 September, 2011 at 7:09 pm

      I am looking into installing a Standalone CA into our AD infrastructure.  The concern one of my colleagues has is that, because our internal and external domains are the same (let’s say mydomain.com for both), would our users run into problems if we have certificates from both external CAs and the new internal one?  How does the root CA resolve for mydomain.com for internal users?  Would it start looking for the internal one instead of the external third-party?

      Reply
    2. John Wesley

      12 August, 2011 at 6:28 am

      Monday eveing,
      For the last week, I have been looking and looking for a site similar to this site.  I am considered the “IT” for an office that I work at.  I really don’t consider myself all that knowledgeable, but compared to the others, I’m the “Go to person.”  Here is my problem:  There is one Server and it is running Windows 2003.  There are 7 (seven) workstations, each running Windows XP Pro. We are not in a domain, but rather, a “Workgroup.” 
      In evenings, and weekend, myself and another person can and do access the Server via Windows Remote Desktop feature.  We also have a “Static IP” for doing this. 
      Two of the computers are now set up to take Credit Cards.  The bank that we are working with concerning the Credit Cards, let us know, that because of our RDP ability, we have to now “Configure Terminal Services to Utilize SSL for authentication of the Server.”  They are calling the situation “The man in the middle” issue.
      So, after doing some research, I believe that I have to purchase a SSL Certificate, and in turn, install it.  We are not a Domain Network, nor a Web Server,  but rather, as I said above, we are in a “Workgroup.” 
      Can someone please find out what I now need to do, and how to “use it”  concerning the implementing of this feature.

      Sincerley,
      John wesley

      Reply
    3. Liza

      4 March, 2011 at 6:27 pm

      I would  like to issue certificates to users who do not always sit at the same computer all the time. My problem is I create a certificate at one computer to day they sit at another one next week and try to digitally sign a document it says that my certificate is not valid unless I try to find the one that I created the certificate on.  Is there anyway around this problem. I have windows server 2003 sp2 on my certificate server (domain controller with AD) and windows XP  on the clients. Any assistance will be appreciated.

      Reply
    4. Liza

      3 March, 2011 at 1:51 pm

      If I have users who work at different computers at different times how can I issue them with a certificate that they can use at different computers or without having them create a new certificate every-time they sit  at another computer?  I am presently using windows server 2003 w/sp2 and clients running windows XP.
       

      Reply
      • Phil Cummings

        4 August, 2011 at 3:02 pm

        For users who use different computers or access via a gateway such as Citrix, implement Credential Roaming, and the users will access the certificates stored in their Active Directory containers.

        Reply
    Microsoft Networking
    } 210 queries in 0.500 seconds.