> For the complete documentation index, see [llms.txt](https://t1t.gitbook.io/t1c-js-guide-v3/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://t1t.gitbook.io/t1c-js-guide-v3/release-notes/v3.8.10.md). # v3.8.10 ## Trust1Connector — Release Notes v3.8.10 **Release date:** June 2026\ **Packages:** Default Trust1Connector\ **Branches:** (API) · (Installers) *** ### Highlights | Area | What changed | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | **Localhost SSL** | Full self-signed CA + TLS leaf certificate lifecycle built into the API, trusted by all browsers without any user action | | **Shared cert store** | All four cert files live in `%LocalAppData%\T1CConnector\` — shared across all T1C packages on the same device | | **CertmgrService** | Certificate management extracted into a reusable library layer with zero actix-web dependencies | | **File Exchange** | Stability overhaul — guaranteed config, fixed type-deletion edge cases, improved sorting and listing | | **FileEx module** | Command-path quoting fixes for Windows UNC/network paths; raw-string parameter handling | | **macOS connectivity** | Automatic CCID driver fix (Sonoma 14+) and Rosetta 2 install on first startup | | **Windows connectivity** | Root CA seeded from the MSI install directory; trust-store written to `LocalMachine\Root` without elevation dialogs | | **Installers** | VC++ 2015–2022 runtime bundled; process-kill before uninstall; clean LocalAppData on uninstall; signtool auto-detection | | **Logging** | File logging enabled by default; log stored at `%LocalAppData%\\logs\t1c-api.log` | | **Startup stability** | DS sync and registry daemon crons are fully non-blocking; request timeouts prevent indefinite hangs | | **Build scripts** | `build-mac.sh` (ARM + Intel) and `build-windows.ps1` (x64 / x86 / ARM64) replace all previous build scripts | *** ### New Features #### Localhost SSL — automatic certificate lifecycle The API now generates, manages, and renews its own TLS infrastructure on every device without any pre-provisioned certificate: * **Per-device Root CA** generated on first startup with a 4096-bit RSA key pair.\ The CA includes correct `SubjectKeyIdentifier` and `AuthorityKeyIdentifier` extensions, making it accepted by all modern browsers and OpenSSL chains. * **Leaf certificate** (TLS server cert) generated from the Root CA with a random 128-bit serial number, eliminating the `SEC_ERROR_REUSED_ISSUER_AND_SERIAL` error in Firefox. * **Localhost and local IP SAN entries** (`127.0.0.1`, `::1`, `localhost`) are included automatically. * **Enabled by default.** No configuration flag or extra step is needed. * **Stale certificates are replaced** on each startup — the API deletes old leaf cert files before writing new ones to ensure no stale material is used. #### Shared cert store — `%LocalAppData%\T1CConnector\` All four certificate files are now stored in a single shared folder that every T1C package on the device reads and writes: ``` %LocalAppData%\T1CConnector\ t1c-ca.pem ← Root CA certificate (PEM) t1c-ca-key.pem ← Root CA private key t1c-tls.pem ← localhost TLS leaf certificate t1c-tls-key.pem ← localhost TLS private key ``` * If a valid Root CA already exists in this folder (generated by another T1C package), the API **reuses it** instead of generating a conflicting second CA. * The shared folder is **never deleted** by any single package uninstaller — it is preserved so other installed packages, continue to function. * CN-based stale CA deletion has been **removed** — the old behaviour of deleting any cert with CN `T1C Local Root CA` before install would wipe a valid CA owned by a co-installed package. Cleanup is now thumbprint-exact. #### CertmgrService — reusable library layer Certificate management has been extracted into a `CertmgrService` struct with **zero actix-web imports**: * All business logic (cert generation, store install/uninstall, hosts management, status queries) lives in `certmgr_service.rs` and can be called from desktop apps, CLI tools, or test harnesses without spinning up an HTTP server. * The actix-web handler file (`certmgr.rs`) is a thin shim: parse request → call service → wrap `HttpResponse`. * REST endpoints remain unchanged: `GET /v3/certmgr/status[/{domain}]`, `POST /v3/certmgr/install`, `POST /v3/certmgr/renew`, `POST /v3/certmgr/hosts`, `DELETE /v3/certmgr/uninstall`. #### macOS trust automation * Root CA installed into the **macOS System Keychain** via `security add-trusted-cert -d -r trustRoot`.\ A one-time marker file prevents re-prompting on every restart. * Elevation uses a native password dialog (`sudo -A` + `SUDO_ASKPASS`) — the same mechanism as `mkcert`. * **Firefox** is trusted via the enterprise policy (`policies.json` + `user.js`) — no NSS `certutil` or Homebrew needed. #### Windows trust automation * Root CA installed into **`LocalMachine\Root`** (machine-wide, no per-user dialog).\ When the MSI runs as SYSTEM, the CA is written before the user ever opens a browser. * The API seeds the CA from the MSI install directory (`C:\Program Files\\`) so the trust store entry is correct even if the `LocalAppData` folder doesn't exist yet. * **`ERR_CERT_AUTHORITY_INVALID`** in Chrome and Edge is resolved automatically on install. *** ### Stability Improvements #### Startup — non-blocking DS sync and registry daemon The Distribution Service (DS) sync and the `t1c-reg` registry daemon cron are now fully non-blocking at startup: * **DS client** (`mod_ds`): initial sync and the recurring cron are spawned in a Tokio background task. The HTTP server starts immediately — a slow or unreachable DS no longer delays the API from accepting requests. * **DS request timeouts:** 15 s overall request timeout + 10 s connect timeout added to the `reqwest` fallback client. A misconfigured or offline DS endpoint can no longer cause an indefinite hang. * **Registry daemon** (`t1c-reg`): the cron that polls `t1c-reg` is spawned via `tokio::spawn` (replacing `actix_rt::spawn`) and carries a 5 s connect + 10 s request timeout. The `HttpServer` no longer blocks waiting for the daemon to respond before it begins serving. #### File Exchange module (`mod_filex`) * **Configuration always present:** the file exchange config file is now guaranteed to exist on the user profile, preventing crashes on first-time use. * **Type deletion fixed:** deleting a type that no longer exists no longer causes a panic — the operation returns a clean error. * **Content sorting** is now applied consistently across all `list` and `type` responses; helper functions have been extracted for reuse. * **Origin and FileX config handling** refactored to eliminate duplication across endpoints. * All remaining `unwrap()` calls replaced with proper error handling — the module can no longer cause an API process crash through file operations. #### VDDS module (`mod_vdds`) * **Network-path quoting fix:** VDDS executable command arguments containing UNC paths (`\\server\share\...`) or paths with spaces are now passed as raw strings, preventing shell-parsing issues on Windows. * **Optional quote-stripping:** a flag controls whether surrounding quotes are removed from path parameters, resolving edge cases when callers pre-quote their arguments. * Commands that reference network locations now work reliably without manual workarounds. #### API core — panic elimination All remaining `panic!` / `unwrap()` / `.expect()` call sites replaced with graceful error handling: | Module | Location | Old behaviour | New behaviour | | ----------- | -------------------------- | -------------------------- | ---------------------------------- | | `mod_filex` | Multiple file operations | `unwrap()` → process crash | Returns `Err`, logged cleanly | | `sec.rs` | `rotate_device_cert` | `unwrap()` panics | Returns `Err` to caller | | `system.rs` | `start_sandbox_no_logging` | `.expect()` panic on spawn | Logs error, returns 0 | | `system.rs` | `start_registry` | `.expect()` panic on spawn | Logs error, returns 0 | | `api.rs` | certmgr SSL init | `panic!` | `error!` log + `process::exit(1)` | | API-wide | Option/Result chains | `unwrap()` | Explicit `match` / `?` propagation | *** ### Platform — macOS * **CCID driver fix** applied automatically on first startup (macOS **Sonoma 14.x and later** only; silently skipped on older releases). * **Rosetta 2** is installed if not already present, ensuring Intel card reader drivers run correctly on Apple Silicon Macs. * Both actions are idempotent — they run once and are skipped on subsequent starts. ### Platform — Windows * Root CA lookup now checks **both** `LocalMachine\Root` and `CurrentUser\Root` so the API correctly recognises a CA that was installed by an earlier version or by a user-level `certutil` call. * `AKID/SKID` certificate chain mismatch on Windows fixed by rebuilding the CA in memory from the DER-encoded bytes after disk load (avoids OpenSSL extension round-trip loss). * Firefox: `SEC_ERROR_REUSED_ISSUER_AND_SERIAL` eliminated by randomising the leaf certificate serial on every generation. * Windows Storage dependency updated (`windows` crate) for compatibility with latest SDK. *** ### Installer improvements #### VC++ 2015–2022 Runtime bundled The Microsoft Visual C++ Redistributable (`vc_redist.x64.exe`) is now embedded directly in every MSI. During installation: 1. The registry key `HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64\Installed` is checked. 2. If the runtime is already present, installation is **skipped** — no duplicate installs. 3. If absent, it is installed silently (`/quiet /norestart`) before any connector files are placed. This eliminates the `VCRUNTIME140.dll is missing` error on bare Windows machines. #### Process-kill before uninstall / upgrade Previous versions could leave locked file handles when upgrading or uninstalling while the API was running. The installer now: 1. Force-terminates the full process tree (`t1c-launch.exe`, `-api.exe`, `-sandbox.exe`, `t1c-reg.exe`) with `taskkill /F /T` before any file operations. 2. Waits 2 seconds for the OS to release all file handles. 3. Proceeds with file removal — no more "Access is denied" errors. #### Clean LocalAppData on full uninstall Runtime files (`LocalAppData\\`) — device keys, ds-txs.json, and logs — are removed on a **full uninstall** only. On an **upgrade**, the folder is intentionally preserved so device keys and sync state survive. The **shared** `LocalAppData\T1CConnector\` cert folder is **never** deleted by any single package uninstaller — it is preserved for reuse across all T1C packages on the same device. #### Root CA fallback script (`install-ca.bat`) A helper script is now included in `C:\Program Files\\install-ca.bat`. Administrators and Intune deployments can run this to (re-)install the Root CA without reinstalling the connector. The script: * Reads the CA file from the shared cert folder `%LocalAppData%\T1CConnector\t1c-ca.pem` (written by the API on first run). * Removes any stale `T1C Local Root CA` entry before adding the new one. * Returns an exit code that Intune Remediations can act on. #### Signtool auto-detection `package.bat` now locates `signtool.exe` automatically by walking all installed Windows SDK versions under `Program Files (x86)\Windows Kits\10\bin\`. No more build failure when the SDK is installed but not on PATH. #### File logging enabled by default All five MSI packages now start the API with the `-f` (`--enable-file-logger`) flag, both at install time and in the login startup registry key. The log file is written to: ``` %LocalAppData%\\logs\t1c-api.log ``` This path can be targeted by Intune's **Collect diagnostics** feature or a PowerShell Remediation script. *** ### Build & CI #### New release build scripts The previous collection of single-architecture shell scripts has been replaced with two comprehensive scripts: | Script | Platform | Targets | Notes | | ------------------- | -------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------- | | `build-mac.sh` | macOS (Apple Silicon host) | ARM64 native + Intel (x86\_64) cross | Uses `cross` for Intel; produces universal-compatible artefacts | | `build-windows.ps1` | Windows | x64, x86, ARM64 | ARM64 requires VS 2022 ARM64 CMake component + ClangCL; see `docs/src/build-environment.md` | Old scripts removed: `build-arm.sh`, `build-intel.sh`, `build-windows.bat`. A new `docs/src/build-environment.md` document covers the full build environment setup for both platforms, including the ClangCL VS component required for Windows ARM64. #### Other CI changes * `AWS_LC_SYS_CMAKE_BUILDER=1` added to `.cargo/config.toml` — removes the `libclang` build-time dependency and makes the build fully reproducible on machines without LLVM installed. * Test certificate files and old `t1c.zip` artifacts removed from the repository to reduce attack surface and repository size. * WiX extension NuGet packages pinned to exact version `[4.0.5]` across all five MSI projects — prevents a repeat of the `Binary:Wix4UtilCA_x64` linker error caused by a silent NuGet auto-update. *** ### Upgrade notes | Scenario | Behaviour | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------ | | Fresh install on a new machine | VC++ runtime installed automatically; Root CA generated and trusted; logging active | | Upgrade from 3.8.9 | `LocalAppData` folder preserved (CA keys survive); running processes killed cleanly before file replacement | | Multiple T1C packages on same device | Shared `%LocalAppData%\T1CConnector\` cert folder reused — only one Root CA generated; all packages trust it | | Full uninstall | `LocalAppData` removed; Root CA removed from trust store; shared cert folder preserved | | Intune / MDM silent deploy | No UAC dialogs; CA trusted under SYSTEM context; log available for Intune diagnostics | | macOS Apple Silicon | Rosetta 2 installed on first run; CCID fix applied on Sonoma 14+ | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://t1t.gitbook.io/t1c-js-guide-v3/release-notes/v3.8.10.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.