Symptom
The plugin's init log line (CERTInextCAPlugin.cs:244-259, "CERTInext plugin initialized...") logs ApiUrl, AuthMode, Enabled, credential-presence flags (ApiKeyPresent, etc.), PageSize, IgnoreExpired, SubmitNonDnsSans, DcvEnabled, DcvTxtRecordTemplate, and DNS-validator-factory presence — but not OrganizationNumber, DefaultProductCode, or GroupNumber, not even as a boolean presence flag the way credentials are.
The per-order submission log line similarly logs product code, domain, and additional-domain count, but never whether organizationDetails/delegationInformation were included on the order.
This makes these three fields undiagnosable from gateway logs alone. OrganizationNumber in particular is called out in its own code comment (CERTInextClient.cs:1501-1503) as "the single biggest factor in how quickly CERTInext releases an order from Pending System RA" — yet there is currently no way to confirm from a support log whether it's set, without going into Command's connector configuration UI directly.
How this was found
While triaging a live support escalation (UCSD): several OV UCC orders were observed sitting in pending-approval state for multiple days in the gateway trace log, a pattern matching what happens when OrganizationNumber is unset. There was no way to confirm this from the log — had to ask whoever has Command access to check the connector config directly.
Severity
Low/Medium — pure observability gap, not a functional defect. But it materially slowed down triage of a real customer issue.
Fix
Not fixed here. Add OrganizationNumberPresent, DefaultProductCodePresent, and GroupNumberPresent (boolean presence flags, not raw values) to the plugin-initialized log line, mirroring the existing ApiKeyPresent-style pattern.
Files
CERTInext/CERTInextCAPlugin.cs:244-259 (init log line)CERTInext/Client/CERTInextClient.cs:1495-1510 (order submission — organizationDetails/delegationInformation)
Symptom
The plugin's init log line (
CERTInextCAPlugin.cs:244-259, "CERTInext plugin initialized...") logsApiUrl,AuthMode,Enabled, credential-presence flags (ApiKeyPresent, etc.),PageSize,IgnoreExpired,SubmitNonDnsSans,DcvEnabled,DcvTxtRecordTemplate, and DNS-validator-factory presence — but notOrganizationNumber,DefaultProductCode, orGroupNumber, not even as a boolean presence flag the way credentials are.The per-order submission log line similarly logs product code, domain, and additional-domain count, but never whether
organizationDetails/delegationInformationwere included on the order.This makes these three fields undiagnosable from gateway logs alone.
OrganizationNumberin particular is called out in its own code comment (CERTInextClient.cs:1501-1503) as "the single biggest factor in how quickly CERTInext releases an order from Pending System RA" — yet there is currently no way to confirm from a support log whether it's set, without going into Command's connector configuration UI directly.How this was found
While triaging a live support escalation (UCSD): several OV UCC orders were observed sitting in pending-approval state for multiple days in the gateway trace log, a pattern matching what happens when
OrganizationNumberis unset. There was no way to confirm this from the log — had to ask whoever has Command access to check the connector config directly.Severity
Low/Medium — pure observability gap, not a functional defect. But it materially slowed down triage of a real customer issue.
Fix
Not fixed here. Add
OrganizationNumberPresent,DefaultProductCodePresent, andGroupNumberPresent(boolean presence flags, not raw values) to the plugin-initialized log line, mirroring the existingApiKeyPresent-style pattern.Files
CERTInext/CERTInextCAPlugin.cs:244-259(init log line)CERTInext/Client/CERTInextClient.cs:1495-1510(order submission — organizationDetails/delegationInformation)