VCF Microsoft CA compatibility investigation¶

This is the research-only work package for #1042, tracked in #1050. Research date: 2026-10-25. No appliances were contacted, credentials obtained, certificates issued, or enrollment/renewal tests performed for this report.

Recommendation: adapter implementation gate not satisfied; lab validation required. The official evidence makes a narrow AD CS Web Enrollment investigation worthwhile, but does not establish an implementable VCF wire contract or Atlaso interoperability. Missing evidence is neither a technical NO-GO nor proof that a non-Microsoft implementation is supported. The release sequence now delivers the experimental Atlaso-managed renewal path first under #1052; the MSCA adapter investigation is deferred to Release 1.1, #1053. That scheduling decision does not change this report's technical conclusion. Keep #1042 open for live acceptance and the remaining renewal outcome.

Atlaso currently provides on-demand appliance certificate replacement. VCF Certificate Trust distributes public trust. Neither establishes VCF-native enrollment or automatic renewal. An experimental Microsoft CA compatibility adapter would remain unsupported unless Broadcom independently confirms support for that configuration; technical success alone cannot establish vendor support. The VCF-integrated OpenSSL CA is not a generic external OpenSSL enrollment protocol and is not an emulation target.

Evidence rules and sources¶

Use these evidence classes in every matrix and future lab result:

• Documented: an official source states the requirement for its named product/version.
• Repository: current Atlaso code implements the behavior; this is not external interoperability evidence.
• Hypothesis: a candidate exchange or relationship to investigate, not an implementation requirement.
• Untested: no observation from an identified lab build. An inaccessible document remains unavailable evidence.

All sources below were retrieved on 2026-10-25. The Broadcom KB pages are mutable and several expose no update date; record their article IDs and environment statements rather than inventing revision dates. Recheck sources when the lab build is selected. Microsoft browser enrollment guidance does not describe VCF's machine client.

The release-note and CA-configuration TechDocs links reached from B1/B2 could not be retrieved during this research. Version-specific API entry pages for 9.1 and 9.1.1 also could not be retrieved. These access failures establish neither that documentation is absent nor that an API is unsupported. Obtain accessible version-matched documentation or the appliance's supported API specification before making requests. No API availability is assigned from latest.

Version and protocol matrix¶

No row below has lab-confirmed Atlaso compatibility. Keep the VCF Operations, SDDC Manager, fleet-management component, and Microsoft CA plugin versions separate; a product-family label is insufficient.

/certsrv/, /certsrv/certfnsh.asp, /certsrv/certnew.cer, and /certsrv/certnew.p7b are candidate observation paths. Only the limited source statements above are documented here. Do not implement the four paths as an assumed complete contract. M1 explicitly distinguishes CA Web Enrollment from Certificate Enrollment Web Service; do not substitute the latter, general Active Directory emulation, ACME, SCEP or EST for an observed VCF dependency.

Certificate origin and renewal ownership¶

A3's unpinned configuration model includes microsoftCertificateAuthoritySpec with serverUrl, username, secret and templateName. These suggest configuration inputs, not how VCF binds an issued certificate to its CA. A4's example also includes a secret field: even a read-only CA-config response must be filtered inside the trusted consumer before anything is persisted or displayed. Do not download complete configuration responses into reports or shell output.

A2 exposes type, autoRenewInfo, autoRenewState and displayAutoRenewState; its example contains type: MSCA, autoRenewInfo.autoRenewStatus: DISABLED and autoRenewState: ENABLED together. Treat these as separate observations, not equivalent booleans. Examples are not normative state-machine definitions or proof of a functioning scheduler.

For each lab stage, record certificate resource identity, issuer/root fingerprints, leaf fingerprint, VCF-reported CA type, every available renewal field and a sanitized reason code. Record absent fields as absent, not false. Then correlate those observations with VCF's own task history and the certificate actually served over TLS. A subject/issuer name match, successful replacement, or changed UI label is insufficient to establish native auto-renewal.

The unresolved question is whether a correctly authenticated Web Enrollment exchange is sufficient for VCF to retain CA origin and schedule renewal, or whether additional AD CS/plugin state is required. Do not edit VCF databases or plugin binaries to force classification. Preserve VCF's native status for externally imported Atlaso certificates. If a future Atlaso-managed controller is selected, its ownership/status must remain distinct from VCF-native renewal.

Existing Atlaso building blocks¶

Repository inspection used base commit cfcb5c95afeb16c88ecec7a66ac04334c79e532b. The following are reuse candidates, not an inbound enrollment authorization model. Source links are pinned to that commit.

Existing focused evidence includes the signed/bounded PKCS#10 case in tests/test_ca.py, SAN/root cases in tests/services/test_vcf_certificate_material.py, and uncertain-install/reservation cases in tests/services/test_vcf_certificates.py. These tests were inspected, not executed for this documentation work; none proves Web Enrollment interoperability. No incoming MSCA routes, request-ID registry, template-to-profile mapping, VCF-origin binding or VCF-managed renewal integration is supplied by this change.

Security requirements for a later proof of concept¶

Before a Phase 0 GO, review a model that binds a dedicated authenticated enrollment identity to exact allowed target identities, SANs, templates and existing enabled CA profiles. A submitted template or SAN is a request, not authority. Preserve CSR signature/key checks, issuance accounting and audit; never call a lower-level signer to bypass policy. Keep target keys on VCF/its native appliance and Atlaso's signing key inside Atlaso's existing custody boundary.

Require verified HTTPS, bounded request/response sizes and timeouts, rate/concurrency limits, durable request identity, replay/idempotency handling, and recovery after uncertain issuance. Define whether pending requests are supported from observed behavior. Deny unsupported routes/templates/targets by default. Authentication errors and failed CSR validation must not issue a certificate. Do not weaken shared CA profiles, enable anonymous enrollment, or disable TLS validation. This report supplies requirements, not a completed security design or approval to expose an enrollment listener.

Isolated-lab investigation procedure¶

This procedure is for a later, separately authorized lab session. It was not executed for #1050. Start with a real Microsoft CA baseline; the adapter comparison and negative adapter tests require a subsequent Phase 0 GO and Phase 1 implementation. Do not create an adapter merely to complete this runbook.

1. Establish ownership, versions and recovery¶

1. Select one disposable VCF-supported TLS component, initially a lab vCenter Machine SSL target if the exact installed VCF build supports its coordinated CA workflow. Record its resource/VM identity and dependencies. If unsupported, stop and record that prerequisite; do not substitute an unrelated certificate role.
2. Record Operations, SDDC Manager, fleet-management component and plugin versions/builds independently, plus Windows, IIS, AD CS roles, CA hierarchy, template identifier/schema and Atlaso commit/profile. Mark unavailable plugin version data explicitly and obtain the supported identification method before claiming a reproducible baseline.
3. Load the current VMware lifecycle procedure, certificate address-control procedure, and credential policy. Establish original ownership receipts, isolated network scope, permitted evidence locations and supported teardown before resource creation. Use the exact Atlaso 1Password Environment through the supported bounded helpers; never put credentials into commands or evidence.
4. Obtain version-matched CA configuration, certificate replacement, health and recovery instructions. Confirm supported backups and recovery access before modifying the target. Record current public leaf/chain, service health and VCF certificate status. Keep the existing clock authority; do not advance or roll back clocks.

2. Prepare the reference CA and safe observation¶

1. On the isolated real AD CS endpoint, verify trusted HTTPS with the correct hostname SAN. Apply the documented build-specific Basic-authentication and template permissions through the lab owner. Record the template's internal and friendly names separately. Do not apply B1's IIS settings to other services or production infrastructure.
2. Before enrollment, use IIS Manager → test website → Logging → W3C → Select Fields (M3). Retain only UTC date/time, method, URI stem, HTTP/substatus/Win32 result, and duration. Omit query strings, cookies, referrers, user agents, usernames and custom headers. Verify inherited logging, proxy logs and diagnostic tracing cannot persist secrets. Use only the isolated fixed-path enrollment endpoint; retain unexpected path content only as an unknown-path count.
3. Verify observation with synthetic non-secret traffic. Do not use HAR exports, TLS key logging, decrypted packet capture, verbose authenticated HTTP clients, full request/response dumps or unrestricted VCF support bundles. Filtering must happen before persistence, not as later redaction of a secret-bearing capture.
4. W3C logs establish method/path/status order only. To resolve form/query names, encodings, response MIME/body category, auth scheme and request-ID transitions, require an approved lab observer that emits only those allowlisted metadata fields and public certificate/CSR fingerprints. Exclude header values, cookies, credentials and raw bodies at source. If no safe observer exists, mark those protocol cells unresolved and stop short of a protocol-complete GO.

3. Observe real-MSCA enrollment and origin¶

1. In the version-matched Fleet Management → Certificates → Configure CA workflow, configure the real test Microsoft CA using documented inputs and verified trust. Record input field names and non-secret template/CA identity only. Never export the full configuration API response; A4 may contain secrets.
2. Select the one disposable component and invoke the documented native CA-backed generation/replacement workflow. Manual CSR download, external signing and import are not a substitute. Record UTC stage times, sanitized VCF task IDs, ordered CA exchanges and request-ID correlation. Do not overwrite an existing pending CSR.
3. Complete the protocol matrix from observations, including validation/configuration requests, leaf and chain retrieval, authentication challenges, encoding, template/CA selection, pending/denied behavior and bounded retries. Keep every unsupported or unobserved case explicit; a successful happy path does not define error semantics.
4. Independently obtain the served leaf and validate hostname, full chain, expiry, SANs, KU/EKU and CSR public-key match. Compare its fingerprint with the issued leaf and VCF task result, then verify component/integration health. From an authorized host with OpenSSL, this read-only example verifies the named TLS service using a reviewed public root:

openssl s_client -connect vcenter.lab.example:443 -servername vcenter.lab.example \
  -CAfile reviewed-lab-root.pem -verify_hostname vcenter.lab.example -verify_return_error </dev/null

Use actual independently verified lab names and public trust files. A successful handshake does not by itself prove exact leaf identity, complete application health, or issuance provenance; compare the public certificate separately. 5. Using the installed build's supported certificate-details interface/API, record the actual CA type and separate renewal fields before and after issuance. Filter inside the authenticated consumer; persist only the allowed public metadata and normalized status/reason codes. Do not assume A2's fields or states exist on the installed build.

4. Establish scheduler behavior and the adapter gate¶

1. On the real-MSCA baseline, enable native renewal through the documented supported control. Select an allowed short validity/template or supported lab scheduling control and a bounded observation window before issuance. If no safe acceleration exists, wait for the native threshold or record the test as pending; never alter clocks or hidden state.
2. Observe a second issuance and installation attributable to VCF's scheduler/orchestrator. Correlate trigger/task time, new CA request/serial and changed served fingerprint. Verify the renewed leaf, full chain and health again. Clicking manual replacement or a manual renew action alone does not prove scheduler ownership.
3. Record the exact protocol and a proposed narrow security model. A Phase 0 GO permits only a separately reviewed, opt-in lab adapter proof of concept when its required exchange and authorization design are sufficiently evidenced. A failing or incomplete real-MSCA reference must be diagnosed before attributing failure to an Atlaso adapter.
4. After that GO and a separate Phase 1 implementation, repeat steps 2–4 with the candidate Atlaso adapter and fresh disposable target state. Compare the entire exchange, origin classification, renewal eligibility and full scheduled second renewal. Do not claim Atlaso compatibility from the real-MSCA baseline alone.

5. Negative cases, recovery and evidence¶

Run each case separately on disposable state. Record result, sanitized reason, issuance count, pending request state, installed fingerprint and health. Inject malformed responses only through an approved lab test mechanism after the adapter exists; never patch the real CA or VCF binaries to fabricate behavior.

Preserve a sanitized result bundle outside disposal roots: ownership/source references, exact builds and API-spec version, source retrieval dates, completed matrices, allowed protocol events, public CSR/leaf/chain fingerprints, VCF task correlation, health evidence, negative-case results and recovery outcome. No arbitrary error strings or configuration exports belong in the bundle. Release only proven task-owned resources through their supported tools after downstream work no longer needs them; preserve ambiguous or recovery-pending state.

Decision record and next work¶

The next MSCA-specific work package is the isolated real-MSCA investigation for Release 1.1. Do not mark unperformed cases passed, classify missing lab access as technical failure, close #1042 on documentation delivery, or expose an experimental enrollment endpoint as a consequence of publishing this report. Release sequencing does not establish MSCA incompatibility, native renewal success, or Broadcom support.