docs(enroll): scope the CERTInext SAN measurements to the sandbox

The probe ran against sandbox-us, but the comments and the non-DNS warning read as
though the behaviour were established generally. The customer this fix is for is on
production, so the distinction matters.

* The non-DNS finding (CERTInext accepts an email/IP/URI verbatim as an order domain
  rather than rejecting it) is explicitly sandbox-only and flagged unverified on
  production. The operator-facing warning no longer promises a parked order — it names
  the offending SANs and says the order will either be rejected or fail validation,
  noting what the sandbox did.

* The CN-collapse finding is likewise marked sandbox-only, which strengthens rather than
  weakens the case for de-duplicating on our side: we should not depend on undocumented
  CA behaviour we have not seen in production.

* The CSR-SAN finding — CERTInext ignores the CSR's subjectAltName entirely — is noted as
  corroborated by production independently of the probe: the report that prompted this
  work was a production UCC order whose CSR carried the SANs and whose certificate came
  back holding only the CN.

* Probe header now says how to re-run against production, and warns that product
  numbering is per-account (Constants.Products holds defaults, not guarantees).

No functional change.

Author: spbsoluble

CERTInext.IntegrationTests/SanSubmissionProbeTests.cs

@@ -19,8 +19,16 @@
 // and issuance to complete.
 //
 // ---------------------------------------------------------------------------------------
-// MEASURED RESULTS — sandbox-us, account 4951571271, product 844 (OV SSL UCC), 2026-08-12.
-// (Product 840 / DV UCC is not enabled on that account: "Invalid Product Code".)
+// MEASURED RESULTS — SANDBOX ONLY: sandbox-us, account 4951571271, product 844 (OV SSL UCC),
+// 2026-08-12. (Product 840 / DV UCC is not enabled on that account: "Invalid Product Code".)
+//
+// These are sandbox observations. Re-run against production before treating B or C as
+// settled there — point ~/.env_certinext at the production account and set
+// CERTINEXT_SAN_PROBE_PRODUCTS to a UCC code that account can actually order (product
+// numbering is per-account; the codes in Constants.Products are defaults, not guarantees).
+// Finding A and the CSR-SAN result below are separately corroborated by production: the
+// customer report that prompted this work was a production UCC order whose CSR carried the
+// SANs and whose issued certificate held only the CN.
 //
 //   A. CONFIRMED. additionalDomains is what puts extra names on the order. Submitting
 //      CN + extra1.<cn> registered BOTH domains.

CERTInext/CERTInextCAPlugin.cs

@@ -2130,11 +2130,14 @@ private static int MapRevocationReasonStringToCode(string reason)
         /// reaches the order.
         ///
         /// Parsing the CSR here is not redundant with sending the CSR to CERTInext.
-        /// CERTInext ignores the CSR's subjectAltName extension outright — measured in
-        /// <c>SanSubmissionProbeTests</c>: a CSR carrying two DNS names, submitted with
-        /// <c>additionalDomains</c> omitted, produced an order with only the CN registered.
-        /// Re-submitting the CSR's names through <c>additionalDomains</c> is the only way a
-        /// SAN that exists solely in the CSR reaches the issued certificate.
+        /// CERTInext ignores the CSR's subjectAltName extension outright — measured on the
+        /// US sandbox in <c>SanSubmissionProbeTests</c>: a CSR carrying two DNS names,
+        /// submitted with <c>additionalDomains</c> omitted, produced an order with only the
+        /// CN registered. Production behaves the same way: the customer report that prompted
+        /// this fix was a production UCC order whose CSR carried the SANs and whose issued
+        /// certificate held only the CN. Re-submitting the CSR's names through
+        /// <c>additionalDomains</c> is the only way a SAN that exists solely in the CSR
+        /// reaches the issued certificate.
         ///
         /// History (UCC SANs silently dropped): the gateway keys this dictionary
         /// <c>dnsname</c>, not <c>dns</c>. <see cref="MapSanType"/> did not recognize
@@ -2212,22 +2215,27 @@ void Add(string type, string value)
             // them would issue a certificate silently missing names the subscriber asked for,
             // which is the worse failure.
             //
-            // Measured behaviour (SanSubmissionProbeTests, product 844, 2026-08-12): CERTInext
-            // does NOT reject these at order placement. It accepts the order and registers the
-            // value verbatim as an order domain — an email address, an IP literal and a URI all
-            // came back as domainVerification keys. The order then cannot pass domain validation,
-            // so it parks pending instead of failing fast. Say that plainly, because "the
-            // enrollment did not error but the order will never issue" is the confusing case.
+            // Measured on the US SANDBOX only (SanSubmissionProbeTests, product 844,
+            // 2026-08-12): CERTInext did NOT reject these at order placement. It accepted the
+            // order and registered the value verbatim as an order domain — an email address, an
+            // IP literal and a URI all came back as domainVerification keys. The order then
+            // cannot pass domain validation, so it parks pending instead of failing fast.
+            //
+            // Production is UNVERIFIED for this case and may reject the order outright instead.
+            // The warning below therefore describes the sandbox outcome as the expected one
+            // without promising it: either way the operator is told which SANs are the problem,
+            // which is the part that matters for diagnosis.
             var nonDns = result.Where(s => !string.Equals(s.Type, "dns", StringComparison.OrdinalIgnoreCase)).ToList();
             if (nonDns.Count > 0)
             {
                 _logger.LogWarning(
                     "{Count} requested SAN(s) are not DNS names: {Sans}. CERTInext's additionalDomains " +
-                    "field takes domain names, and it accepts these verbatim rather than rejecting them — " +
-                    "the order will be created but is not expected to pass domain validation, so it will " +
-                    "sit pending rather than issue. They are submitted rather than dropped on purpose: a " +
-                    "visibly stuck order is preferable to a certificate issued without names the subscriber " +
-                    "requested. Remove them from the CSR or the enrollment pattern if the order should proceed.",
+                    "field takes domain names, so this order will either be rejected outright or be " +
+                    "created and then fail domain validation and sit pending — on the US sandbox it was " +
+                    "accepted verbatim and parked pending. They are submitted rather than dropped on " +
+                    "purpose: a visible failure is preferable to a certificate issued without names the " +
+                    "subscriber requested. Remove them from the CSR or the enrollment pattern if the " +
+                    "order should proceed.",
                     nonDns.Count, string.Join("; ", nonDns.Select(s => $"{s.Type}:{s.Value}")));
             }
 

CERTInext/Client/CERTInextClient.cs

@@ -1487,11 +1487,12 @@ private static string ExtractCnFromSubject(string subject)
         /// before we get here.
         ///
         /// <paramref name="domainName"/> is the value already going out as the order's primary
-        /// domain, and Command normally includes the CN in the SAN set as well. CERTInext was
-        /// measured to collapse that repetition itself (SanSubmissionProbeTests: CN submitted
-        /// twice came back registered once), so excluding it here is defence in depth rather
-        /// than a correctness requirement — it keeps the submitted body matching what we log
-        /// and avoids depending on undocumented CA-side de-duplication.
+        /// domain, and Command normally includes the CN in the SAN set as well. On the US
+        /// sandbox CERTInext was measured to collapse that repetition itself
+        /// (SanSubmissionProbeTests: CN submitted twice came back registered once), but that is
+        /// undocumented and unverified against production — which is exactly why we exclude it
+        /// here rather than relying on CA-side de-duplication. It also keeps the submitted body
+        /// matching what we log.
         /// </summary>
         private List<string> BuildAdditionalDomains(
             System.Collections.Generic.List<SanEntry> sans,