@serve.zone/dcrouter 13.17.0 → 13.17.2

package/dist_ts/opsserver/handlers/certificate.handler.d.ts

@@ -0,0 +1,77 @@
+import type { OpsServer } from '../classes.opsserver.js';
+/**
+ * Mirrors `SmartacmeCertMatcher.getCertificateDomainNameByDomainName` from
+ * @push.rocks/smartacme. Inlined here because the original is `private` on
+ * SmartAcme. The cert identity ('task.vc' for both 'outline.task.vc' and
+ * '*.task.vc') is what AcmeCertDoc is keyed by, so two route domains with
+ * the same identity share the same underlying ACME cert.
+ *
+ * Returns undefined for domains with 4+ levels (matching smartacme's
+ * "deeper domains not supported" behavior) and for malformed inputs.
+ *
+ * Exported for unit testing.
+ */
+export declare function deriveCertDomainName(domain: string): string | undefined;
+export declare class CertificateHandler {
+    private opsServerRef;
+    constructor(opsServerRef: OpsServer);
+    private registerHandlers;
+    /**
+     * Build domain-centric certificate overview.
+     * Instead of one row per route, we produce one row per unique domain.
+     */
+    private buildCertificateOverview;
+    private buildSummary;
+    /**
+     * Legacy route-based reprovisioning. Kept for backward compatibility with
+     * older clients that send `reprovisionCertificate` typed-requests.
+     *
+     * Like reprovisionCertificateDomain, this triggers the full route apply
+     * pipeline rather than smartProxy.provisionCertificate(routeName) — which
+     * is a no-op when certProvisionFunction is set (Rust ACME disabled).
+     */
+    private reprovisionCertificateByRoute;
+    /**
+     * Domain-based reprovisioning — clears backoff first, refreshes the smartacme
+     * cert (when forceRenew is set), then re-applies routes so the running Rust
+     * proxy actually picks up the new cert.
+     *
+     * Why applyRoutes (not smartProxy.provisionCertificate)?
+     *   smartProxy.provisionCertificate(routeName) routes through the Rust ACME
+     *   path, which is forcibly disabled whenever certProvisionFunction is set
+     *   (smart-proxy.ts:168-171). The only path that re-invokes
+     *   certProvisionFunction → bridge.loadCertificate is updateRoutes(), which
+     *   we trigger via routeConfigManager.applyRoutes().
+     */
+    private reprovisionCertificateDomain;
+    /**
+     * After a force-renew, walk every route in the smartproxy that resolves to
+     * the same cert identity as `forcedDomain` and write the freshly-issued cert
+     * PEM into ProxyCertDoc for each. This guarantees that the next applyRoutes
+     * → provisionCertificatesViaCallback iteration will hot-swap every sibling's
+     * rust loaded_certs entry with the new (correct) PEM, rather than relying on
+     * the in-memory cert returned by smartacme's per-domain cache.
+     *
+     * Why this is necessary:
+     *   Rust's `loaded_certs` is a HashMap<domain, TlsCertConfig>. Each
+     *   bridge.loadCertificate(domain, ...) only swaps that one entry. The
+     *   fire-and-forget cert provisioning path triggered by updateRoutes does
+     *   eventually iterate every auto-cert route, but it returns the cached
+     *   (broken pre-fix) cert from smartacme's per-domain mutex. With this
+     *   helper, ProxyCertDoc is updated synchronously to the correct PEM before
+     *   applyRoutes runs, so even the transient window stays consistent.
+     */
+    private propagateCertToSiblings;
+    /**
+     * Delete certificate data for a domain from storage
+     */
+    private deleteCertificate;
+    /**
+     * Export certificate data for a domain as ICert-shaped JSON
+     */
+    private exportCertificate;
+    /**
+     * Import a certificate from ICert-shaped JSON
+     */
+    private importCertificate;
+}