@serve.zone/dcrouter 13.16.1 → 13.17.0

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

@@ -1,77 +0,0 @@
-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;
-}