FlightCheck: Add check for Workday SOAP/REST integration certificate validity and expiry

[GrahamMcMynn]

Missing FlightCheck Validation

Frequency: This misconfiguration has been observed in 1 customer incident(s).

What should be checked

Customers using certificate-based auth on the Workday integration (common with SSO setups like Okta/Ping) hit hard-to-diagnose authentication failures when the certificate is misconfigured, expired, or out of sync between Power Platform and Workday. FlightCheck should validate the certificate end to end.

Suggested implementation

• Checkpoint ID: WD-CONN-102
• Category: Workday
• Priority: HIGH
• Validation logic: For certificate-authenticated Workday connectors:
  1. Read the public certificate registered on the Power Platform connection.
  2. Read the matching public certificate uploaded to the Workday tenant (via Workday integration system metadata where exposed, or a customer-supplied artifact).
  3. Compare thumbprints; warn on mismatch.
  4. Warn if NotAfter is within 30 days; fail if expired.

Context

This gap was identified by analyzing resolved customer incidents for the Employee Self-Service Agent service. Customers hit this issue because the FlightCheck tool did not warn them about the misconfiguration before deployment.

[GrahamMcMynn]

The flightcheck-issue-responder cannot implement this check autonomously. Reason:

Blocker: No captured cassette or vendor-documented contract exposes the certificate metadata this check would compare on either side of the integration (Power Platform connection cert Workday tenant cert), and the Workday-side path that would expose it is the WQL admin surface that is documented as a known-blocker for runtime FlightCheck checks.

Detail:

The suggested implementation needs three pieces of data:

1. Public certificate (thumbprint, NotAfter) on the Power Platform Workday connection. The �alidated-tier endpoint GET /providers/Microsoft.PowerApps/scopes/admin/environments/{env_id}/connections is captured in tests/fixtures/cassettes/flightcheck_pp_admin.yaml, but the captured connectionParameters / connectionParametersSet shapes only expose username, instance name, OAuth token URIs, ClientId, and ResourceUri no thumbprint, x5t, notAfter, publicKey, or certData field appears in the cassette for any connection. The lone aadcertificate strings in the cassette are service-name tokens inside Entra token-refresh error messages, not certificate metadata. Per flightcheck/AGENTS.md ("Don't invent endpoint URLs, methods, or response shapes") and tests/AGENTS.md ("you may not write FlightCheck integration tests against APIs whose contracts you have not verified"), the responder cannot assume cert fields are exposed by this endpoint without a real capture against a cert-auth Workday connection.

2. Matching public certificate on the Workday tenant. Per the ## Suggested implementation block, this would come from "Workday integration system metadata where exposed." Workday tenant config metadata is the Workday SOAP / Workday WQL API surface in the registry. The captured WQL data sources in workday_wql_admin.yaml (allWorkers, oAuth20RefreshTokenDataSource, publicWebServices, allSecurityGroups, allCustomReports, allIntegrationSystemsAudited) do not include certificate fields. The catalog mentions allPGPPublicKeys (file-encryption keys, not SSO/SOAP certs) and cybersourceCertificate (payments processor, irrelevant to ESS), but neither is captured with sample data and neither matches the cert auth path the issue is about. More importantly, the WQL admin surface is currently a documented known-blocker for runtime FlightCheck checks: tests/fixtures/cassettes/INDEX.md "Workday WQL config-validation pattern" and flightcheck/AGENTS.md "Things you must NOT do" both explicitly say do not build a runtime check on the WQL cassette without first resolving the chicken-and-egg OAuth API Client registration problem. The 2026-05 SOAP-admin capture attempt also confirmed Get_API_Clients / Get_Authentication_Policies are not on the publicly-exposed SOAP service list, so the SOAP fallback isn't available either.

3. Workday tenant cert exposure via integration system metadata even if WQL were unblocked, no captured WQL data source exposes the API client's signing/encryption certificate, and the tenant-config rows we'd need (Get_API_Clients, Get_Authentication_Policies) are in the "Endpoints we'd like cassettes for" section of INDEX.md, not the captured set. The vendor doc tier (documented) doesn't help either: there's no MS Learn or Workday public doc that exposes a documented response shape for "read the cert installed on a registered API client" because that surface area is gated behind Workday Community login and per-tenant WSDL.

The "or a customer-supplied artifact" alternative in the suggested implementation moves the check from "automated FlightCheck" into "interactive customer questionnaire," which is outside the current FlightCheck runner contract checks read API responses through runner.<client>, not from prompts.

What's needed to unblock:

Either (a) capture a cassette against a real Power Platform Workday connection that uses certificate-based auth, confirm whether the BAP connections endpoint exposes cert thumbprint / NotAfter for that auth mode, and add the row to the Confirmed cassette endpoints table in tests/fixtures/cassettes/INDEX.md then re-open this issue scoped to the cert-expiry-only half of the check (skip the cross-tenant thumbprint comparison); or (b) resolve the WQL chicken-and-egg auth blocker per the four workarounds in the WQL section of INDEX.md AND add a new captured WQL data source (or a new Get_API_Clients SOAP cassette) that exposes the Workday-side certificate metadata. Path (a) is much cheaper and would still catch the most common failure mode the issue describes (expired or about-to-expire cert on the Power Platform side); the cross-tenant thumbprint match is what's actually structurally blocked.

[GrahamMcMynn]

The flightcheck-issue-responder re-ran on the retry label and is still BLOCKED. Nothing material has changed about the cert-metadata exposure since the previous run.

Blocker: Same as the prior run no captured cassette and no vendor-documented contract expose the certificate metadata (thumbprint / notAfter / x5t / public key) that this check would need to compare on either side of the integration (Power Platform connection cert Workday tenant cert). The WQL admin surface that would expose the Workday-side cert remains a documented known-blocker for runtime FlightCheck checks per tests/fixtures/cassettes/INDEX.md.

Detail what changed since 2026-05 and what didn't:

What landed (does not unblock this issue):

• dataverse_workday_connection_refs_full.yaml and _simplified.yaml plus WD-PKG-001 / WD-CONN-012 for Workday install-flavor detection (PR flightcheck: WD-PKG-001 + WD-CONN-012 — detect Workday install flavor #123). Connection references in Dataverse point at the underlying connection via connectionid but do not carry certificate metadata themselves; a grep for thumbprint|notAfter|certificate|x5t|certData|publicKey against both new cassettes returns no matches.

What did not change:

1. Power Platform side no cert-auth Workday connection has been captured. The captured cassette flightcheck_pp_admin.yaml covers GET /providers/Microsoft.PowerApps/scopes/admin/environments/{env_id}/connections but contains no Workday connection rows at all (only an env-description-level mention), and no captured connection's connectionParameters / connectionParametersSet shape exposes cert fields for any connector. The lone aadcertificate strings in the cassette are service-name tokens inside Entra token-refresh error messages (lines ~2657-2673), not certificate metadata. No new recorder targeting a cert-auth Workday connection exists in tests/captures/ (record_flightcheck_pp_admin.py is unchanged), so the BAP-side question "does this endpoint expose thumbprint / notAfter for a cert-auth connection?" is still unanswered.

2. Workday side WQL auth blocker is still documented as unresolved. The "Workday WQL config-validation pattern KNOWN BLOCKER" section of tests/fixtures/cassettes/INDEX.md and the equivalent section of flightcheck/AGENTS.md both still explicitly forbid building a runtime check on the WQL cassette without first solving the chicken-and-egg OAuth API Client registration problem. None of the captured WQL data sources (allWorkers, oAuth20RefreshTokenDataSource, publicWebServices, allSecurityGroups, allCustomReports, allIntegrationSystemsAudited) expose the API client's signing/encryption certificate. The 2026-05 SOAP-admin capture attempt also still applies Get_API_Clients / Get_Authentication_Policies were not on the publicly-exposed SOAP service list, so the SOAP fallback isn't available either.

3. No documented-tier path exists. There is no MS Learn or Workday public doc that exposes a documented response shape for "read the cert installed on a registered Workday API client" because that surface is gated behind Workday Community login and per-tenant WSDL. The Power Platform Admin (BAP) API surface is documented in the registry, but its MS Learn / programmability docs do not document a cert-metadata field on /connections responses and per flightcheck/AGENTS.md ("Don't invent endpoint URLs, methods, or response shapes") the responder cannot assume one exists without a real capture.

The "or a customer-supplied artifact" alternative in the ## Suggested implementation block moves the check from "automated FlightCheck" into "interactive customer questionnaire," which is outside the current FlightCheck runner contract checks read API responses through runner.<client>, not from prompts.

What's needed to unblock:

Either (a) extend tests/captures/record_flightcheck_pp_admin.py (or add a new wrapper) to capture against a real Power Platform environment that has a Workday connection using certificate-based auth, eyeball the captured cassette for whether connectionParameters / connectionParametersSet / a sibling field exposes thumbprint / notAfter / x5t for cert-auth connections specifically, and if so add the row to the "Confirmed cassette endpoints" table in tests/fixtures/cassettes/INDEX.md then re-label retry and the responder will scope the check to cert-expiry-only on the Power Platform side (skipping the cross-tenant thumbprint comparison, which would still be structurally blocked); or (b) resolve the WQL chicken-and-egg auth blocker per one of the four workarounds in the WQL section of INDEX.md AND add a new captured WQL data source (or a Get_API_Clients SOAP cassette via path 3) that exposes the Workday-side certificate metadata, then re-label retry for the full thumbprint-comparison check. Path (a) is far cheaper and would still catch the most common failure mode the issue describes (expired or about-to-expire cert on the Power Platform side); the cross-tenant thumbprint match is what's actually structurally blocked. If path (a) capture comes back showing the BAP endpoint does NOT expose cert fields for cert-auth connections either, the issue should be closed the API surface needed simply does not exist.