Files
certctl/internal/scep/intune/doc.go
T
shankar0123 7e4d423561 feat(scep-intune): parser + validator for Microsoft Intune Connector challenge format
Phase 7 of the SCEP RFC 8894 + Intune master bundle. Adds the
internal/scep/intune package that validates Microsoft Intune Certificate
Connector signed challenges embedded in SCEP CSR challengePassword
attributes. This is the parsing/validation foundation; Phase 8 wires it
into the SCEP service dispatcher.

What's included:

  * doc.go — package architecture (Intune cloud → Connector → certctl
    SCEP server) + 'what this package is NOT' guard rails. We do NOT
    implement full JOSE: no JKU / kid / x5c trust, no JWKS fetch.
    Trust anchor is operator-supplied at startup and pinned. The
    package does NOT call Microsoft's API directly — the Connector
    already did that; we validate its signed attestation.

  * trust_anchor.go — LoadTrustAnchor(path) reads a PEM bundle of
    Intune Connector signing certs. Skips non-CERTIFICATE PEM blocks
    (operators sometimes paste chains with the priv key by mistake).
    Rejects empty bundles + expired certs at startup with an
    operator-actionable message including the cert subject. SIGHUP
    reload lands in Phase 8.5; today it's load-once-at-boot.

  * claim.go — ChallengeClaim struct + DeviceMatchesCSR helper.
    Set-equality semantics for SAN-DNS/SAN-RFC822/SAN-UPN: the CSR
    must carry EXACTLY the claim's elements, no extras and no missing.
    Empty claim slice = no constraint on that dimension.
    Per-dimension typed errors (ErrClaimCNMismatch /
    ErrClaimSANDNSMismatch / ErrClaimSANRFC822Mismatch /
    ErrClaimSANUPNMismatch) so audit logs surface the failure
    dimension without string-matching. extractUPNSans is stubbed to
    return nil with documented fail-closed behavior — non-empty UPN
    claims fail the equalSets check (correct behavior; the rare deploy
    that pins UPN SANs hot-fixes the ASN.1 walker per the inline
    comment).

  * replay.go — ReplayCache: bounded in-memory cache of seen nonces
    with TTL. Sized for 100,000 entries (60-min Connector validity ×
    25 RPS Intune fleet steady-state ≈ 90,000 challenges/hour with
    headroom). sync.Map for concurrent read/write; janitor goroutine
    wakes every TTL/4 to evict expired entries; at-cap O(N)
    oldest-eviction (rarely fires; janitor keeps the cache below
    cap). Redis-backed variant deferred to V3-Pro.

  * challenge.go — the load-bearing piece:

    - ParseChallenge(raw) splits the JWT-like compact serialization
      into header/payload/signature and base64url-decodes each.
      Tolerates both padded + unpadded encodings (some Connector
      builds emit padded; RFC 7515 §2 says unpadded; we accept both).
      Validates the header parses as JSON before returning so the
      malformed-signal lands earlier in the pipeline.

    - ValidateChallenge(raw, trust, expectedAudience, now):
        1. ParseChallenge
        2. JWS signature verify over (segment0 || '.' || segment1)
           — re-derived from the raw on-wire bytes, NOT
           re-base64-encoded, per RFC 7515 §3.1 (re-encoding could
           produce a byte-different input than what was signed)
        3. Signature alg dispatch:
             RS256: rsa.VerifyPKCS1v15(SHA-256)
             ES256: tries fixed-width r||s (JOSE-canonical) first,
                    falls back to ASN.1 DER (older Connectors)
             alg=none: explicit reject with audit-log-friendly
                       message (RFC 7515 §3.6 attack vector)
             HS*/PS*: rejected as 'unsupported alg' (no shared
                      secret in our threat model)
        4. Version-detection prelude (versionedChallenge struct +
           versionUnmarshalers map). Today's format is v1 (no
           explicit version field; absence IS the v1 signal). Adding
           v2 = adding a parser + a registration line; v1 path stays
           untouched. Defends against the inevitable Microsoft format
           change at ~30 LoC + 2 tests cost vs. a P0 incident.
        5. Time bounds (iat / exp); audience pin (skipped when
           expectedAudience == "").

      Replay protection is the CALLER's job (handler glues parser +
      cache; validator stays stateless + testable).

  * Typed errors: ErrChallengeMalformed / ErrChallengeSignature /
    ErrChallengeExpired / ErrChallengeNotYetValid /
    ErrChallengeWrongAudience / ErrChallengeReplay /
    ErrChallengeUnknownVersion. errors.Is-friendly so the handler
    can audit failure dimension.

Tests (94.8% coverage):

  * challenge_test.go (18 tests): happy-path RS256 + ES256
    fixed-width + ES256 DER; TamperedSignature; TamperedPayload;
    Expired; NotYetValid; WrongAudience; EmptyExpectedAudience
    disables check; RotatedTrustAnchor; EmptyTrustBundle;
    AlgNoneRejected; UnsupportedAlg (HS256); MissingAlg;
    VersionV1ExplicitOK; VersionUnknownRejected;
    MixedTrustBundle iter (skip key-type mismatches without
    surfacing as Signature err); NonJSONPayloadButValidSignature;
    Malformed cases (empty, missing dots, bad base64, non-JSON
    header — 9 sub-cases); PaddedBase64Tolerated.

  * claim_test.go (13 tests): per-dimension matching across CN +
    SAN-DNS + SAN-RFC822 + SAN-UPN; nil guards; case-insensitive DNS
    (RFC 4343); dedupe set-equality; empty claim = no constraint;
    UPN stub canary; normaliseSet edge cases; equalSets length
    mismatch.

  * replay_test.go (11 tests): first-fresh; duplicate-rejected;
    past-TTL-fresh; Sweep-evicts-expired; empty-nonce
    short-circuits; at-cap LRU eviction; default-cap=100k;
    Close-idempotent; TTL=0 disables janitor; concurrent-race-free
    (50 goroutines × 200 inserts); empty-nonce twice is fresh both
    times (we don't cache empties).

  * trust_anchor_test.go: HappyPath single + multi cert; SkipsNonCertBlocks
    (priv key + cert mix); EmptyBundleRejected; OnlyKeyBlocksRejected;
    ExpiredCertRejected (with subject CN in error); MalformedCertRejected;
    LoadTrustAnchor disk + EmptyPath + MissingFile.

  * fuzz_test.go: FuzzParseChallenge with seed corpus covering both
    the well-formed and the obvious-malformed shapes. Survived 187k
    execs in 21s without panic on the local burst; CI runs 5 min.

Verification:

  * gofmt -l ./internal/scep/intune: clean
  * go vet ./internal/scep/intune/...: clean
  * staticcheck ./internal/scep/intune/...: clean
  * go test -count=1 -cover ./internal/scep/intune/...: 94.8%
    (target was ≥85%)
  * go vet ./internal/... ./cmd/...: clean (no rest-of-repo regressions)
  * No new CERTCTL_* env vars (those land in Phase 8 with the
    config gate); G-3 docs-drift CI guard not triggered.
  * No new HTTP routes; openapi-parity guard not triggered.

Phase 8 will:
  - Add SCEPProfileConfig.Intune* env vars + preflight gate
  - Wire the validator into the SCEP service dispatcher
    (Intune-shaped challenges → validator; static → existing path)
  - Trust-anchor SIGHUP reload mirroring cmd/server/tls.go::watchSIGHUP
  - Per-claim rate limit + audit metrics

Refs: cowork/scep-rfc8894-intune-master-prompt.md::Phase 7
      cowork/scep-rfc8894-intune/progress.md
2026-04-29 14:38:35 +00:00

57 lines
2.7 KiB
Go

// Package intune handles the Microsoft Intune dynamic-challenge format
// embedded in SCEP CSR challengePassword attributes when the SCEP server
// is sitting behind the Microsoft Intune Certificate Connector.
//
// SCEP RFC 8894 + Intune master bundle Phase 7.
//
// Architecture context:
//
// Intune cloud
// ↓ (device cert request)
// Intune Certificate Connector (on customer infra)
// ↓ (SCEP CSR with challenge signed by Connector)
// certctl SCEP server ← THIS PACKAGE validates the Connector's signed challenge
// ↓ (issue cert)
// issuer connector (local CA, Vault, EJBCA, etc.)
//
// The Connector's signed challenge is a JWT-like blob (compact
// serialization, header.payload.signature) where the payload is a JSON
// object containing the device + user claim, the expected CN + SANs,
// expiry, and a nonce. The signature is over header+"."+payload using
// the Connector's installation signing key — the operator extracts that
// key's certificate and configures it as certctl's trust anchor at
// startup.
//
// This package does NOT call Microsoft's API directly. The Connector
// already did that; this package validates the Connector's attestation.
//
// What this package is NOT:
//
// - NOT a full JWT (JOSE) implementation. It parses + verifies one
// specific format with a fixed set of supported algorithms (RS256,
// ES256). No JWKS fetch, no JKU header trust, no kid-based key
// rotation — the operator-supplied trust bundle IS the trust
// anchor, and the validator tries each cert in the bundle until
// one verifies.
// - NOT a generic SCEP-shape detector. The handler dispatches to this
// package only when the configured SCEPProfile has IntuneEnabled=true
// AND the inbound challengePassword "looks Intune-shaped" (length +
// dot-count heuristic landed in Phase 8).
// - NOT a Microsoft API client. The Connector's role is to talk to
// Microsoft; certctl's role is to validate the Connector's signed
// attestation. The replacement target this whole bundle eliminates
// is NDES, NOT the Connector.
//
// References:
//
// - https://learn.microsoft.com/en-us/mem/intune/protect/certificate-connector-overview
// - https://learn.microsoft.com/en-us/mem/intune/protect/certificates-scep-configure
// - smallstep/step-ca Intune integration (community reverse-engineering of the format)
// - HashiCorp Vault PKI Intune integration (same)
//
// The format details land in this package from a combination of
// Microsoft's published Connector behavior + community implementations
// that have reverse-engineered the JWT shape. Cite the implementation
// references in the parser code's doc comment when you change format.
package intune