With Windows Server 2008 R2 and Windows 7, a new functionality for certificate enrollment has been introduced: The Certificate Enrollment Web Services, which are mapped by two server roles:
- Certificate Enrollment Policy Web Service (CEP)
- Certificate Enrollment Web Services (CES)
The following is a description of the background to these roles, how they work, and the possible deployment scenarios.
Classic certificate request via LDAP and RPC/DCOM (MS-WCCE)
The functionality of the classic certificate request via RPC/DCOM is described in this article described, which should be read first to understand the common fundamentals.
Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.
In summary, the classic Certificate Enrollment process consists of two main steps:
- Query Active Directory via LDAP protocol for information relevant to Certificate Enrollment (certificate templates, and which certificate authorities offer them for application.
- Sending the certificate request via RPC/DCOM to the determined responsible certification authority.
However, this method has some disadvantages:
- It works only in the internal network.
- Domain connectivity is required.
- Membership in the same Active Directiory overall structure, or a trust position including replication of the relevant data is required.
- It is required that the RPC/DCOM network ports be exposed to all requestors, which can be a security risk.
- Authentication at the certification authority must be done via Kerberos.
Requesting certificates via Certificate Enrollment Web Services
Until now, certificates were requested classically via Lightweight Directory Access Protocol (LDAP) and Remote Procedure Call / Distributed Common Object Model (RPC/DCOM). This required clients (all entities requesting certificates from a certification authority) to connect to these network ports on the internal network.
The Certificate Enrollment Web Services, consisting of the Certificate Enrollment Policy Web Service (CEP) and the Certificate Enrollment Web Service (CES), now allow applications to be submitted via an HTTPS interface.
This enables new application scenarios such as:
- Applicants who are to apply for or renew certificates via the Internet.
- Applicants who are in a different overall structure to which there is no position of trust.
- Applicant in a demilitarized zone (DMZ).
- Applicant on the internal network, but without having to expose the certificate authority's RPC/DCOM ports to the network.
- Authentication now also with username/password and client certificate in addition to Kerberos.
- The possibility to authenticate for the renewal of a certificate with the previous certificate (Key based Renewal).
Step 1: Connection of the applicant to the CEP via HTTPS
The applicant connects to the Certificate Enrollment Policy Service via HTTPS. The information about where this is located is communicated to him via group policy using an enrollment policy.
The applicant authenticates to the CEP using one of the following three methods:
- Username and password
- Kerberos
- Client certificate
Step 2: Connecting the CEP to Active Directory via LDAP
The CEP takes over the LDAP query against the Active Directory on behalf of the client. The following information is queried.
- All pKICertificateTemplate Objects (certificate templates) in the Active Directory forest.
- All pKIEnrollmentService objects (enterprise certificate authorities) in the Active Directory forest.
- All msPKI-Enterprise-Oid Objects (Object Identifier) in the Active Directory forest.
This information is all stored in the Configuration partition of the Active Directory forest.
The pKICertificateTemplate and msPKI-Enterprise-OID objects can be used to determine whether the requester is authorized to request ("enroll") and whether an automatic request is to be made ("auto-enroll"). The default settings for making the certificate request are also determined here.
The pKIEnrollmentService objects can be used to determine the certification authorities that offer the certificate templates to be requested, as well as via which Certificate Enrollment Web Services the certification authority can be reached. For this purpose, the attributes certificateTemplates as well as msPKI enrollment server evaluated.
Step 3: Applicant connection to the CES via HTTPS
In the third step, a key pair and a certificate request are generated based on the requested information and sent to the responsible CES server via HTTPS.
The applicant authenticates to the CES again using one of the following three methods:
- Username and password
- Kerberos
- Client certificate
Step 4: Connection of the CES to the certification authority via RPC/DCOM
The CES now impersonates the logged-in user and performs the certificate request via RPC/DCOM in the user's security context.
The certificate authority can identify the user based on the impersonated Kerberos authentication and applies the settings specified in the corresponding certificate template with its policy module.
After issuing the certificate, the CES returns the certificate to the applicant.
Related links:
External sources
- Certificate Enrollment Web Services (Microsoft)
English 
Deutsch
6 thoughts on “Grundlagen Zertifikatbeantragung über Certificate Enrollment Web Services (CEP, CES)”
Comments are closed.