- release_dir now points to CERTInext/bin/Release (no framework moniker) — fixes Archive Files step in CI
- product_ids populated with all 7 supported CERTInext product codes
- ca_plugin_config: added missing required/optional fields (AccountNumber, RequestorName, RequestorEmail, RequestorIsdCode, RequestorMobileNumber, SignerPlace, SignerIp, DefaultProductCode); removed deprecated Username/Password
- AuthMode description corrected to 'AccessKey' / 'OAuth' (was 'ApiKey' / 'Basic' / 'OAuth2')
- OAuth field names aligned to code: OAuthTokenUrl, OAuthClientId, OAuthClientSecret
- enrollment_config: added DomainName, SignerName, SignerPlace, SignerIp; removed deprecated ProfileId/ValidityDays
- configuration.md: rename heading to "Certificate Template Creation Step"; drop unimplemented SANFormat parameter

…heading

- release_dir: remove net8.0 framework moniker — fixes Archive Files step in CI
- product_ids: populate with supported SSL/TLS product codes (838-846)
- docsource/configuration.md: rename to "Certificate Template Creation Step"; remove doc-tool TODO stub

GetProductIds now returns ProductName (e.g. "DV SSL") instead of the
numeric ProductCode so the Command UI dropdown shows meaningful labels.
EnrollmentParams.ProductCode no longer falls back to the gateway
ProductID since names cannot be passed to the CERTInext API — operators
must set ProductCode explicitly on every template.
Manifest product_ids updated to match the descriptive naming convention.

GetProductIds now returns a static list so the CI doc tool (which uses
reflection, not a live API call) can populate integration-manifest.json
correctly without resetting product_ids to [].

A DefaultProductCodes map in Constants.Products resolves the selected
product name (e.g. "DV SSL") to its production numeric code ("838")
automatically, so operators no longer need to look up and enter codes
manually. ProductCode template param remains available as an explicit
override for sandbox environments or non-standard codes.

…reflection

… 1-month products

- Add DV Wildcard UCC (841), OV Wildcard UCC (845), EV UCC (847) to product
  table, Constants.Products, DefaultProductCodes map, GetProductIds, manifest
- Note DV SSL 1 Month and DV SSL Wildcard 1 Month as portal-visible but not
  returned by GetProductDetails API and unsupported by this plugin
- Update integration test table: 841/845/847 blocked on EMS-918; 843/844 not
  yet tested; 1-month products marked not supported

…Format param

- Remove redundant '## Architecture' heading from configuration.md before
  the architecture.md include (pre-rendered file already starts with that heading)
- Remove SANFormat from the enrollment parameters table (not implemented)

…ANFormat constant

- architecture.md used 'signature' but the CERTInext API field is 'authKey' and
  the parameter names are requestTs/requestTxnId — now consistent with API docs
  and configuration.md
- SANFormat constant in Constants.EnrollmentParam was never used in any code path
  and was already removed from documentation; no other CA plugin has this param

)

* fix: P1-P3 improvements — OAuth auth, sync CompleteAdding, Ping enabled check, renewal window, retry logic, IDisposable, GroupNumber config, nested product response model

* test: add unit tests for P1-P3 fixes; update MockCertificateData to nested product response format

* test: rewrite integration tests — remove stale hardcoded-order tests, add lifecycle test, make empty-account resilient

* docs: add GroupNumber field, per-account product code note, AgreementAcceptance and DCV findings

* chore: refactor Makefile — extract all API targets into scripts/; add generate-order-149-fresh, probe-endpoints, get-field-details targets

* docs: add cross-plugin analysis, certinext improvement plan, and API findings from sandbox exploration

* chore: add V2 API Makefile targets and scripts; ignore analysis/ directory

Adds 21 make targets covering every CERTInext V2 operation (ssl-certificates,
private-pki-certificates, catalog, groups, orgs, domains, reports). Each target
delegates to a corresponding script under scripts/v2/ which sources the new
scripts/lib/certinext-v2-auth.sh for CERTInext-native SHA256 token exchange.
Adds analysis/ to .gitignore so scratch docs and support emails are never committed.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* feat(constants): add Dcv constants and Config DCV key names

Add Constants.Dcv subclass with dcvMethod codes (1=DNS TXT, 2=HTTP,
3=Email), dcvStatus values (0=Pending, 1=Validated, 2=Rejected), and
the default TXT record hostname template. Add DcvEnabled,
DcvTxtRecordTemplate, and DcvPropagationDelaySeconds to Constants.Config.

* feat(api): add GetDcv and VerifyDcv request/response DTOs

Add GetDcvRequest, DcvRequestDetails, and VerifyDcvRequest for the
GetDcv/VerifyDcv endpoints. Add GetDcvResponse, DcvResponseDetails,
VerifyDcvResponse, TrackOrderDomainVerification (with JsonExtensionData
for heterogeneous per-domain entries), and DomainVerificationDetail.
Wire DomainVerification onto TrackOrderResponseDetails.

* feat(client): add GetDcvAsync and VerifyDcvAsync

GetDcvAsync posts to GetDcv and returns the token (and file/email
fields) for a domain on an existing order. VerifyDcvAsync posts to
VerifyDcv to ask CERTInext to check the published DNS TXT record.
Both methods follow the existing pattern: BuildMetaAsync, retry,
auth-failure detection, DeserializeOrThrow, meta.status check,
structured logging with OrderNumber and Domain context.

* feat(config): add DcvEnabled, DcvTxtRecordTemplate, DcvPropagationDelaySeconds

Add three DCV-related fields to CERTInextConfig with documented defaults
(false, _emsign-validation.{0}, 30 s) and corresponding UI annotations
in GetCAConnectorAnnotations. Guards the DNS DCV path so operators must
explicitly opt in before any DNS plugin interaction occurs.

* feat(enroll): inject IDomainValidatorFactory; add DNS DCV orchestration

Bump IAnyCAPlugin to 3.3.0-PRERELEASE-78770-979f582005 to gain access
to IDomainValidatorFactory, IDomainValidator, and IDomainValidatorConfigProvider.

Add a primary constructor accepting IDomainValidatorFactory (gateway
injects this at startup) alongside the existing parameterless fallback.
Add DomainValidatorConfigProvider inner class.

Add PerformDcvIfNeededAsync: reads pending-DCV domains from TrackOrder,
skips if the order is already issued, validates domain FQDNs, calls
GetDcvAsync per domain, resolves the DNS plugin via
ResolveDomainValidator(domain, 'dns-01'), stages the TXT record, waits
for propagation, triggers VerifyDcv, then cleans up in a finally block.
EnrollNewAsync calls this when DcvEnabled=true and the factory is present,
then re-fetches the post-DCV certificate status before returning.

* test(client): add WireMock unit tests for GetDcvAsync and VerifyDcvAsync

Add GetDcvSuccessJson, GetDcvFailureJson, VerifyDcvSuccessJson, and
VerifyDcvFailureJson helpers to MockCertificateData. Add seven tests
covering: successful token retrieval, meta-failure response, 401
authentication failure, successful verification, meta-failure on verify,
401 on verify, and 500 on verify.

* chore(scripts): add get-dcv/verify-dcv probe scripts and Makefile targets

Add scripts/get-dcv.sh and scripts/verify-dcv.sh mirroring the
track-order.sh pattern. Both scripts source ~/.env_certinext and
certinext-auth.sh, accept ORDER_NUMBER, DOMAIN_NAME, and optional
DCV_METHOD (default 1=DNS TXT), and use jq --arg for safe JSON
construction to prevent injection via user-supplied values.

Add get-dcv and verify-dcv Makefile targets with DCV_METHOD variable
and register both in .PHONY.

…S env var override

…roxy as HV3-specific

The register README presented cookie auth as 'the common case' using the HV3 lab
(intdev01.lab.kfpki.com) host/paths. Reframe: OAuth2 client_credentials against
/KeyfactorAPI is the typical path; cookie + /KeyfactorProxy + the /certinext-0
instance path are HV3-deployment-specific, not the norm.

…01, 0002)

0001 — Synchronize emitted issued/revoked records with no certificate body (the
order-report listing carries no PEM), so CERTInext-issued certs never reached
Command. Refetch the full cert via GetCertificateAsync for GENERATED/REVOKED
records whose body is missing, mirroring GetSingleRecord. Regression tests cover
issued + revoked refetch and the no-over-fetch boundary.

0002 — DCV-during-sync attempted every pending order on every pass, making a full
scan O(pending) and pathologically slow with a large/abandoned backlog. Bound it:
  - DcvSyncMaxOrderAgeHours (default 24): only recently-placed pending orders are
    DCV-eligible during sync; old ones age out instead of being retried every pass.
  - DcvSyncMaxPerPass (default 50): cap DCV attempts per pass.
  - fastSync short propagation delay on the sync path (Enroll keeps the full wait).
Gate is a pure helper (EvaluateDcvSyncEligibility) with exhaustive unit tests.

Emit-side observability — completion summary now reports GeneratedWithBody /
GeneratedNoBody / Revoked / Pending plus the DCV gate counts, with a per-record
Debug line. Carries OrderDate from the order report onto the sync model for
stateless age filtering.

195/195 unit tests green; full scan validated bounded (~3 min).

Gateway hosts on anygateway-rest 25.5.0 ship IAnyCAPlugin 3.2.0; a plugin built
against 3.3.0-PRERELEASE loads but its AnyCAPluginCertificate records are not
persisted by the 3.2 host (issue 0003). This branch builds against 3.2.0 so the
contract matches, at the cost of DCV (the v3.3-only IDomainValidatorFactory).

- CERTInext.csproj: IAnyCAPlugin 3.3.0-PRERELEASE -> 3.2.0; SUPPORTS_DCV define
  documented (left undefined).
- CERTInextCAPlugin.cs: fence all DCV/IDomainValidator(Factory) code with
  #if SUPPORTS_DCV — the factory ctor, DomainValidatorFactory property, the Enroll
  DCV block, PerformDcvIfNeededAsync. TryRunDcvDuringSyncAsync no-ops (returns false)
  so the 0001 body-refetch + 0002 gate keep working; SetDomainValidatorFactory(object)
  stays as a logged no-op for host compatibility.
- Test csprojs: exclude DCV-only files (DcvTests, FakeDomainValidator, integration
  DCV lifecycle + DNS validators) unless SUPPORTS_DCV is defined.
- SmokeTests: use the (client, config) ctor instead of the fenced factory ctor.

Solution builds clean (0 warnings); 172 unit tests pass (23 DCV tests excluded).

Info-level sync logs were too sparse to debug gateway-side behavior. Add:
- Per-record Trace in Synchronize: listed vs mapped status, order date, whether a
  body was present in the listing.
- DCV-gate decision Trace per pending order (decision, age, attempted-so-far, cap).
- Body-refetch Debug: before the refetch and the resulting cert byte count.
- MethodEntry/MethodExit bumped from Trace to Debug across the plugin (Keyfactor
  logger helpers), and added to EnrollNewAsync and TryRunDcvDuringSyncAsync.

172 unit tests pass; builds clean against IAnyCAPlugin 3.2.0.

…audit logging

Addresses a refetch bug the new logging surfaced, plus compliance-audit findings:

- Refetch metadata loss: GetCertificateAsync returns the body but NOT Subject /
  ProfileId / OrderDate, and the refetch replaced `current` wholesale — so issued
  certs synced with a null Subject (visible in logs: "Subject=(null)") and, worse,
  a null ProductID (ProfileId feeds AnyCAPluginCertificate.ProductID). Carry the
  listing's Subject/ProfileId/OrderDate across the refetch.
- DCV summary honesty (issue 0003 / SOC2 CC7.3): only report DCV attempt counts when
  DCV is actually operational (DcvEnabled AND a DNS-provider factory injected). On a
  host that doesn't supply one (e.g. IAnyCAPlugin 3.2.0) the summary now says DCV is
  "not active" instead of a misleading Attempted=N — the gate is gated on dcvOperational.
- Aged-out audit (audit H-1): SkipByAge orders are logged at Information with
  CARequestID/OrderDate so abandoned pending orders are auditable in production.
- skippedWithBody counter in the completion summary so it's visible whether any
  body-carrying cert was skipped (expected 0).

172 unit tests pass; builds clean against IAnyCAPlugin 3.2.0 (0 warnings).

…84/521, Ed25519, Ed448)

Every existing CSR helper hardcoded RSA-2048, so only RSA-2048 was ever
exercised end-to-end. AlgorithmMatrixTests adds a parameterized BouncyCastle
CSR generator and two layers (submission/CSR-validity scope, no DCV):

- Csr_RoundTripsKeyAlgorithm: offline, always runs. Generates a CSR per key
  type, re-parses it, asserts the public-key algorithm/size round-trips and
  the request signature verifies. 10/10 pass.
- Enroll_AcceptsKeyAlgorithm: opt-in (CERTINEXT_ALGO_MATRIX=1; creates real
  sandbox orders). Asserts CERTInext accepts each algorithm at submission;
  a CA-side rejection becomes an explicit Skip carrying the CA's own message,
  so the matrix documents real CA support without failing on a limitation.

The 25.5.0 (no-DCV) and 26.x (DCV) targets differed only in the IAnyCAPlugin
package version and whether SUPPORTS_DCV was defined. Maintaining that as a
separate branch (feat/ianycaplugin-3.2-no-dcv) duplicated every fix. Replace it
with a single MSBuild property:

  DcvSupport=true  (default) -> IAnyCAPlugin 3.3.0-PRERELEASE + SUPPORTS_DCV  (26.x)
  -p:DcvSupport=false        -> IAnyCAPlugin 3.2.0, DCV fenced via #if         (25.5.0)

One property drives the package version, the compile constant, and DCV
test-file inclusion across all three projects. Verified both ways:
  default:            IAnyCAPlugin 3.3.0, 195 unit tests pass (DCV tests in)
  -p:DcvSupport=false: IAnyCAPlugin 3.2.0, 172 unit tests pass (DCV tests out)
both 0 warnings. The no-DCV branch is now redundant. See issue 0003.

Extract the parameterized BouncyCastle CSR generator + 10-type spec into a
shared KeyAlgorithms helper (used by both the offline submission tests and the
new DCV theory). Add DcvLifecycleTests.EnrollWithDcvOn_IssuesPerKeyAlgorithm:
for each key type (RSA 2048/3072/4096/6144/8192, ECDSA P-256/384/521, Ed25519,
Ed448) enroll a fresh scrup.org DV order with DCV on, drive it to issuance, and
assert the issued cert's public key matches the requested algorithm. Algorithms
CERTInext won't issue (rejected/FAILED/never-GENERATED) Skip with the observed
reason rather than hard-failing. Confirms issuance via targeted GetSingleRecord
polling instead of a full-account sync. Opt-in: CERTINEXT_ALGO_MATRIX_DCV=1.

Also null-forgive two asserted-non-null derefs in EnrollWithDcvOn_OrderIssued
(surfaced now that DcvLifecycleTests compiles on every build via DcvSupport).

…edits

First live run of the algorithm matrix skipped all 10: the supported algos
(RSA 2048/3072/4096, ECC P-256/P-384) failed on 'Insufficient Credits' while
the rest returned 'Invalid key size' / 'Something went Wrong'. The old Skip text
called every rejection 'likely an unsupported key algorithm', which is wrong for
the credit-blocked supported ones. Add KeyAlgorithms.ClassifyRejection so the
Skip reason distinguishes an unsupported algorithm from an account/credit
limitation, and report the CA's verbatim message either way.

…ext orders)

Wire up the CERTInext RejectOrder endpoint (orderDetails.{orderNumber,
rejectRemarks}) the existing POC scripts never covered — RevokeOrder targets
issued certs, RejectOrder cancels pre-issuance orders. reject-all-pending.sh
snapshots all pending orders (certificateStatusId 2/24) and rejects them,
preserving issued certs (status 9); dry-run by default, REJECT_ALL_PENDING=1
to fire. Note: cancelling pending orders declutters the account but does NOT
refund credits (verified — a real saveAndHold=0 order still hits EMS-1140).

The algo issuance matrix asserted the cert body immediately on GENERATED, but
CERTInext flips status to GENERATED a beat before GetCertificate returns the PEM
— so a fast-issuing order (ECDSA-P256, RSA-3072) could report GENERATED with an
empty body and fail the body assertion despite issuing fine. Wait for GENERATED
with a materialized body (slower-issuing RSA-2048/4096 + ECDSA-P384 already passed
because their DCV propagation gave the body time to land).

CI uses Keyfactor's shared starter workflow, which runs a plain 'dotnet build -c
Release' with no -p args — so it built the DEFAULT variant. With DcvSupport
defaulting to true that shipped the IAnyCAPlugin 3.3.0-PRERELEASE / DCV build,
which does NOT persist on the current GA gateway (AnyCA Gateway 25.5.x ships
IAnyCAPlugin 3.2.0 — issue 0003) and pinned an official release to a prerelease
package. Flip the default to false so the plain CI build produces the no-DCV /
3.2.0 GA artifact; DCV is now the opt-in '-p:DcvSupport=true' build for 26.x.

Docs updated (docsource/): DcvSupport build-variant table in the developer guide
(default = no-DCV/3.2.0), host-matched mitigation in overview troubleshooting,
and the confirmed CERTInext key-algorithm envelope (RSA 2048/3072/4096 + ECC
P-256/P-384) on the KeyType template parameter.

The v5 bump dropped gpg_key/gpg_pass, but v5's starter.yml declares both as
required secrets — so the reusable-workflow call failed validation at startup
(startup_failure, run 27373820011). Add them back (the other dropped inputs/
secrets — entra, command_*, command_token_url/hostname/base_api_path — are all
required:false in v5, so they stay omitted).

….0 build)

The released default build targets AnyCA Gateway 25.5.x (IAnyCAPlugin 3.2.0);
the manifest still declared 24.2.0. Align it with the shipped artifact.

…trator style)

Switch CHANGELOG.md to the format used across the orchestrator repos: a '# 1.0.0'
version header with ## Features / ## Bug Fixes / ## Chores sections and
feat()/fix()/chore()-prefixed bullets. Fold in the v1.0 capabilities (DCV build
flag, bounded DCV sync, body-refetch fix, key-algorithm support envelope).

- configuration.md: Command 25.5.x / AnyCA Gateway REST 25.5.0 requirements;
  inline ApiUrl examples include the /emSignHub-API/ path; drop the false
  'CERTInext renew API' claim (renewal is a new GenerateOrderSSL order).
- overview.md: fix dead ../../issues/{7,8} links to GitHub URLs; 3.3.0 ->
  3.3.0-PRERELEASE; lead the TypeLoadException mitigation with the action.
- development.md: document reject-order/reject-all-pending + probe-products.
- QUICKSTART.md: warn that CERTInext only issues RSA 2048/3072/4096 + ECC
  P-256/P-384 (gateway key_algs is a permissive superset); '8 non-EV products';
  fix TypeLoadException remediation to 'deploy the no-DCV build'.
- INTEGRATION_TESTING/TESTING.md: .NET 8 or .NET 10 SDK; drop the removed
  GetOrderReport_ContainsKnownDraftOrder row.
- docs/reference/README.md: note the CERTInext key-algorithm limit.
- integration-manifest.json: tighten the Enabled field description.

README.md is doctool-generated from docsource/, so it is not edited here; CI
regenerates it. (net6->net8/net10 install text lands once doctooldotnet#17 merges.)

…t suite

The file documented a generic plugin template (X-API-Key auth, /api/v1/* endpoints,
AuthMode Basic/CertificateBased, cert-aaa-111) that bears no relation to the actual
tests. Rewrite it against the real project: HMAC-signed-body auth, the real CERTInext
endpoints (ValidateCredentials/GenerateOrderSSL/TrackOrder/GetOrderReport/GetCertificate/
RevokeOrder/GetDcv/VerifyDcv), AuthMode AccessKey/OAuth, and the real MockCertificateData
constants. (Documents 7 of the 11 test classes; the coverage/serial/redaction classes
can be added in a follow-up.)

Regenerated locally with the fixed doctool (Keyfactor/doctooldotnet#17) so the
install section lists the actual target frameworks (net8.0/net10.0) instead of
the stale net6.0/net8.0 the currently-released doctool emits. [skip ci] so CI's
(unpatched) doctool doesn't regenerate over it before the team reviews the PR;
once #17 ships, CI produces this automatically.

…p ci]

status prototype -> production, support_level kf-community -> kf-supported.
Regenerated README locally (status badge + Support section) with the fixed
doctool, preserving the net8.0/net10.0 install paths. [skip ci] so CI's
unpatched doctool doesn't regenerate over it before review.