Skip to content

feat(enroll): native Windows autoenrollment via GPO (MS-XCEP/WSTEP), no third-party agent #108

Description

@Bugs5382

Windows Server and client machines should be able to get certificates from a CryptOS CA using only the tooling built into Windows, with no third-party enrollment agent installed. Enrollment is driven across the domain by Group Policy, the same way machines enroll against AD CS today.

On the CryptOS side this means exposing the two web services Windows autoenrollment expects. The enrollment policy service (MS-XCEP) tells a client what it may enroll for and where. The enrollment service (MS-WSTEP) takes the client's request over HTTPS and returns the issued certificate. Both run over HTTPS using an auth method the domain machine already has, such as Kerberos or a client certificate, so nothing extra has to be installed.

The client side is pure configuration. A Group Policy turns on certificate autoenrollment and points machines at the CryptOS policy service, pushed to the whole domain. This work has to include documenting that Group Policy setup, not just the server endpoints.

WSTEP is already one of the built-in protocol adapters named in the design decisions, alongside ACME, SCEP, EST, RFC 3161, and OCSP. This issue is the concrete Windows use case that drives the WSTEP and XCEP adapters.

Not scheduled. The auth model, template mapping, and any reuse of Active Directory are still open and tie into the separate AD redesign.

Activity

  1. self-assigned this
    on Jul 3, 2026
  2. added this to the v1.1.0 milestone on Jul 15, 2026
  3. added theissue type on Jul 15, 2026
  4. Bugs5382 commented on Sep 30, 2026

    @Bugs5382
    ContributorAuthor

    Design decisions (owner, 2026-09-30):

    • Authentication: Kerberos for first enrolment of domain-joined machines and users (a service account, an SPN and a keytab), plus the current certificate for renewals.
    • Templates: CryptOS profiles are published as the MS-XCEP templates by name. CryptOS stays the source of truth, and no AD template objects are needed.
    • Identity: the subject, the DNS name or UPN, and the SID extension (strong certificate mapping) are looked up in AD over LDAP for the authenticated account, never taken from the CSR.
    • Placement: the setup decides. The endpoints can run on the Issuing or Intermediate nodes that also serve SCEP and ACME, or on a dedicated node. A dedicated node is the suggested setup, and the docs carry a strongly worded callout against running both on one node, even though it's allowed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature (feat). Minor version bump.

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions