Skip to content

v1.5.4

Choose a tag to compare

View all tags
@Romain-Grosos Romain-Grosos released this 29 Apr 20:06
v1.5.4
37c07a0
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

v1.5.4 - cert SAN cross-check in the route editor

A small UX-only patch release. One feature, no Rust code change, no schema migration, no config change. Upgrade is drop-in.

Added

  • Issue #11 (route editor / TLS cert SAN cross-check) : the Routing tab in the route drawer now flags a non-blocking warning when the selected certificate's SAN list does not cover the route's hostname or any of its hostname_aliases. Pre-fix the mismatch was only visible at runtime as a TLS handshake failure (SSL_ERROR_BAD_CERT_DOMAIN browser-side, unknown certificate worker-side) ; an operator who picked the wrong cert would not learn about it until a real client tried to reach the route. The check runs RFC 6125 strict matching - the same rules Chrome / Firefox / Safari enforce on the live handshake - so a "covered" verdict in the editor predicts a successful handshake, and an "uncovered" verdict predicts a real failure rather than a guess that can diverge from the browser. Specifically : exact match (case-insensitive, trailing-dot tolerant), wildcard match where *.example.com covers exactly one subdomain label (so pki.example.com is in, a.b.example.com and the bare apex example.com are out), partial-label wildcards like pki*.example.com rejected as ambiguous (Chrome / Firefox both reject these). The warning is rendered in the existing warn-banner style under the cert select with the offending hostname(s) named and the cert's SAN list echoed for context. Save remains allowed - a wildcard or multi-SAN cert that the operator knows covers the host can still be saved without friction. New lib/cert-san-match.ts (3 exports : hostnameMatchesSan, hostnameCoveredByAny, findUncoveredHostnames) + 23 vitest cases pinning the contract (exact, wildcard single-label, apex rejection, multi-label rejection, partial-label rejection, case-insensitive, trailing-dot, label-boundary straddle, empty inputs, deduplication). No backend change : the CertificateResponse.san_domains field already carried the SAN list since v1.5.3 SAN extraction. 343 frontend tests green (was 320).

Upgrade notes

  • No schema migration, no config change.
  • No new dependency.
  • Rust binaries are unchanged in behaviour ; the bump is metadata-only on the Rust side.
  • A v1.5.3 -> v1.5.4 upgrade is a hot drop-in : stop the service, replace the binary / .deb / .rpm, restart. The SQLite store, certificates, configs, sessions all carry forward unchanged.

Artifacts

  • .deb (Ubuntu / Debian, amd64) : built via dist/build-deb.sh
  • .rpm (RHEL / Rocky / Alma, x86_64) : built via dist/rpm/lorica.spec
  • Source tarball : auto-generated by GitHub from the tag

Verification (operator-side after deploy)

  1. Open the dashboard, edit any route that has a TLS certificate selected.
  2. Switch to a certificate whose SAN list does NOT cover the route hostname (or temporarily change the hostname).
  3. Confirm the orange warn banner appears under the TLS Certificate select with the offending hostname named.
  4. Confirm the Save button remains enabled (the warning is informational, not blocking).
  5. Switch back to a covering cert ; the banner clears in real time.

Full changelog

Compare v1.5.3...v1.5.4

Assets 9
Loading