release: public v0.1.9

- add staged OV/business flows and org-id pre-linking
- clarify provider-linked renewal lifetimes and validity output
- derive default output dirs from certificates-dir and common-name
- simplify docs and examples around Linux defaults

certbro-public-snapshot: true
certbro-private-commit: 3dd4983fceaf556415c96cb57ef1d4ccced59f0e
certbro-private-branch: main

Author: amallek

.gitignore

@@ -1,12 +1,8 @@
+*~
 .DS_Store
 .gocache/
 dist/
 certbro
-scripts/publish-public.sh
-scripts/release-current.sh
-scripts/release-devel.sh
-scripts/testdeploy.sh
-scripts/new-alias-deploy.sh
 *.log
 *.pem
 *.key

.tmp/certbro-renew.lock

@@ -2,14 +2,44 @@
 
 This file summarizes notable changes from the most recent committed updates.
 
+## 2026-03-23
+
+- `certbro issue`, `certbro import`, and `certbro issue-pair` now derive their output directories from `--certificates-dir` plus `common-name` when no explicit output path is passed.
+- Removed redundant `--output-dir` and `--output-dir-base` flags from the basic English and German examples, walkthroughs, and quick-start guides.
+- Simplified the README, getting-started guides, workflow overview, renewal/import/automation guides, and Ubuntu walkthroughs so the first example commands now rely on the Linux defaults instead of repeating default flags.
+- Removed default-valued parameters such as `/etc/certbro` state and certificates paths, the default DV product, and default key or timer settings from basic example commands. Non-default flags remain documented where they actually change behavior.
+- Restructured the larger Ubuntu walkthroughs so the initial `issue`, `renew`, `install`, and `list` examples stay flat and copy-pasteable, while non-default product and lifetime overrides are now described as explicit optional follow-up variants.
+
+---
+
+- Aligned the OV/business docs and example walkthroughs with the current TLS API semantics. The guides now describe `certbro issue` as blocking by default for DV products only.
+- Documented the `--org-id` path for OV/business orders, so existing usable organizations can be pre-linked before ordering.
+- Updated staged OV/business completion fixtures and tests to the current Console completion route under `/my/certs/{certificate_id}/complete`.
+
+---
+
+- Added staged OV/business order support for the TLS API completion flow.
+- `certbro issue` now treats `action_required=true` as a successful staged start, stores pending material locally, prints the Console `completion_url`, and exits without blocking for issuance.
+- `certbro renew` now resumes staged OV/business orders, keeps action-required orders pending without duplicating them, provisions DCV once validation records appear, and finalizes download and deployment after issuance.
+- Extended pending metadata, list output, and regression coverage for staged OV/business orders, including `action_required`, `pending_reason`, `pending_message`, `completion_url`, and `organization_id`.
+
+---
+
+- Aligned renewal handling with the updated TLS API semantics for provider-linked renewals.
+- `validity_days` is now treated consistently as the purchased base lifetime, while the effective issued lifetime is derived from `valid_from` and `valid_until`.
+- Added issued-lifetime helpers and surfaced `purchased_validity_days`, `effective_validity_days`, and `renewal_bonus_days` in CLI output and deployment metadata.
+- Updated docs and tests so `certbro` no longer implies guaranteed renewal credit before issuance.
+
+---
+
 ## 2026-03-22
 
 - Added English and German validity-management guides and updated the existing renewal, issuing, quick-start, and Ubuntu example docs to describe the new lifetime rules and short-lifetime examples correctly.
 - Expanded regression coverage for schedule transitions, renewal timing validation, legacy lead-time normalization, and recent-issuance cooldown behavior.
 - Added a 48-hour cooldown after fresh issuance. Non-forced renewal runs now skip certificates that were issued less than 48 hours ago.
 - Added self-healing for legacy managed certificates with overly large lead times. During renewals, stored lead times are reduced to `validity_days - 1` when needed.
 - Added renewal timing validation to prevent immediate renewal or reissue loops. New and updated configurations now require `validity_days` to be greater than both `renew_before_days` and `reissue_lead_days`.
-- Added automatic normalization of stored `validity_days` during renewals. If an older managed certificate still stores a now-too-large value, `certbro renew` uses the current schedule-aware default and persists the adjusted value after a successful run.
+- Added automatic normalization of stored `validity_days` during renewals. If an older managed certificate still stores a now-too-large value, `certbro renew` uses the current schedule-aware default and persists the adjusted value during renewal processing.
 - Moved the schedule-aware CA/B validity handling one day earlier than the official transition dates, so `certbro` starts using the upcoming lower defaults on `2026-03-14`, `2027-03-14`, and `2029-03-14`.
 
 ---

CHANGES.md

@@ -14,7 +14,7 @@ Das Tool bestellt Zertifikate, legt `dns-cname-token`-Validierungsrecords über
 - RSA- und ECDSA-Key-Rotation bei neuen Bestellungen, Renewal-Orders und Reissues
 - Stabile Dateien unter `live/` und versionierte Snapshots unter `archive/`
 - Eingebaute Validierung und Reload-Unterstützung für `nginx`, `apache` und `caddy`
-- Stündliche unbeaufsichtigte Renewals über `systemd`
+- Unbeaufsichtigte Renewals über `systemd`
 
 ## Voraussetzungen
 
@@ -41,47 +41,44 @@ curl -fsSL https://install.certbro.com/rf | CERTBRO_VERSION=v0.1.0 sh
 
 ## Schnellstart
 
-Standardmäßig nutzt `certbro` `/etc/certbro/state.json` als State-Datei und `/etc/certbro` als Root für verwaltete Zertifikate. Die folgenden Befehle nennen die Pfade der Klarheit halber trotzdem explizit:
+Standardmäßig nutzt `certbro` `/etc/certbro/state.json` als State-Datei und `/etc/certbro` als Root für verwaltete Zertifikate. `issue`, `import` und `issue-pair` leiten Zertifikatsverzeichnisse ebenfalls aus diesem Root und dem `common-name` ab. Die folgenden Befehle verwenden diese Defaults. `--state-file`, `--certificates-dir`, `--output-dir` und `--output-dir-base` sind nur nötig, wenn andere Pfade genutzt werden sollen.
 
 ```sh
 sudo mkdir -p /etc/certbro
 
-sudo certbro --state-file /etc/certbro/state.json configure \
-  --api-key YOUR_REGFISH_API_KEY
+sudo certbro configure --api-key YOUR_REGFISH_API_KEY
 ```
 
 Zertifikat bestellen und deployen:
 
 ```sh
-sudo certbro --state-file /etc/certbro/state.json issue \
+sudo certbro issue \
   --name example-com \
   --common-name example.com \
   --dns-name www.example.com \
-  --product RapidSSL \
-  --webserver nginx \
-  --key-type ecdsa \
-  --ecdsa-curve p256 \
-  --output-dir /etc/certbro/example.com
+  --webserver nginx
 ```
 
+Für DV-Produkte wartet `certbro issue` in der Regel auf die Ausstellung und deployt das Zertifikat direkt. Für OV- oder Business-Produkte kann die TLS API stattdessen `action_required=true` mit einer `completion_url` unter `/my/certs/...` zurückgeben. In diesem Fall speichert `certbro` das Pending-Material lokal, gibt die Console-URL aus und endet erfolgreich. Ein späterer Lauf von `certbro renew` setzt denselben offenen Vorgang fort, nachdem der Console-Schritt abgeschlossen wurde.
+
 Renewals manuell ausführen:
 
 ```sh
-sudo certbro --state-file /etc/certbro/state.json renew
+sudo certbro renew
 ```
 
 Stündlichen Renewal-Timer installieren:
 
 ```sh
-sudo certbro --state-file /etc/certbro/state.json install \
-  --certificates-dir /etc/certbro
+sudo certbro install
 ```
 
 ## Typische Workflows
 
 - Multi-Domain-Zertifikate: `--dns-name` für jede SAN wiederholen
 - Paralleler RSA- und ECDSA-Betrieb: `certbro issue-pair`
 - Bereits bestehende regfish-Bestellungen: Import per `certificate_id`
+- OV- oder Business-Bestellungen: `certbro issue` kann eine Console-`completion_url` zurückgeben; wenn bereits eine nutzbare `--org-id` bekannt ist, direkt mitgeben, andernfalls die Bestellung dort abschließen und später mit `certbro renew` finalisieren
 - Sofortiger Ersatz: `certbro renew --name example-com --force`
 - Einmaliger Laufzeit-Override: `certbro renew --name example-com --force --validity-days 30`
 - Pending-Ausstellung nach Timeout: `certbro renew --name example-com` erneut ausführen, um denselben Request weiter zu beobachten

README.de.md

@@ -14,7 +14,7 @@ It orders certificates, provisions `dns-cname-token` validation records through
 - RSA and ECDSA key rotation on new issues, renewal orders, and reissues
 - Stable files under `live/` and versioned snapshots under `archive/`
 - Built-in validation and reload support for `nginx`, `apache`, and `caddy`
-- Hourly unattended renewals through `systemd`
+- Unattended renewals through `systemd`
 
 ## Requirements
 
@@ -41,47 +41,44 @@ curl -fsSL https://install.certbro.com/rf | CERTBRO_VERSION=v0.1.0 sh
 
 ## Quick Start
 
-By default, `certbro` uses `/etc/certbro/state.json` as the state file and `/etc/certbro` as the managed certificates root. The commands below keep the paths explicit for clarity:
+By default, `certbro` uses `/etc/certbro/state.json` as the state file and `/etc/certbro` as the managed certificates root. `issue`, `import`, and `issue-pair` also derive certificate directories from that root and the `common-name`. The commands below use those defaults. Add `--state-file`, `--certificates-dir`, `--output-dir`, or `--output-dir-base` only when you want different paths.
 
 ```sh
 sudo mkdir -p /etc/certbro
 
-sudo certbro --state-file /etc/certbro/state.json configure \
-  --api-key YOUR_REGFISH_API_KEY
+sudo certbro configure --api-key YOUR_REGFISH_API_KEY
 ```
 
 Issue and deploy a certificate:
 
 ```sh
-sudo certbro --state-file /etc/certbro/state.json issue \
+sudo certbro issue \
   --name example-com \
   --common-name example.com \
   --dns-name www.example.com \
-  --product RapidSSL \
-  --webserver nginx \
-  --key-type ecdsa \
-  --ecdsa-curve p256 \
-  --output-dir /etc/certbro/example.com
+  --webserver nginx
 ```
 
+For DV products, `certbro issue` usually waits for issuance and deploys the certificate directly. For OV or business products, the TLS API can instead return `action_required=true` with a `completion_url` under `/my/certs/...`. In that case, `certbro` stores the pending material locally, prints the Console URL, and exits successfully. A later `certbro renew` run resumes the same pending order after the Console step has been completed.
+
 Run renewals manually:
 
 ```sh
-sudo certbro --state-file /etc/certbro/state.json renew
+sudo certbro renew
 ```
 
 Install the hourly renewal timer:
 
 ```sh
-sudo certbro --state-file /etc/certbro/state.json install \
-  --certificates-dir /etc/certbro
+sudo certbro install
 ```
 
 ## Common Workflows
 
 - Multi-domain certificates: repeat `--dns-name` for each SAN
 - Dual RSA and ECDSA deployment: use `certbro issue-pair`
 - Existing regfish orders: import by `certificate_id`
+- OV or business orders: `certbro issue` can return a Console `completion_url`; if you already know a usable `--org-id`, pass it up front, otherwise complete the order there and let `certbro renew` finish it later
 - Immediate replacement: `certbro renew --name example-com --force`
 - One-off renewal lifetime override: `certbro renew --name example-com --force --validity-days 30`
 - Pending issuance after a timeout: rerun `certbro renew --name example-com` to resume monitoring the existing request

README.md

@@ -11,6 +11,7 @@ Dieses Verzeichnis enthält die deutschsprachigen Betriebs- und Nutzungshinweise
 
 ## Zertifikats-Workflows
 
+- [Workflow-Überblick](workflow-overview.md): DV-, gestufte OV-/Business- und vorverknüpfte Organisations-Flows im direkten Vergleich
 - [Zertifikate bestellen](issuing-certificates.md): Single-Domain, SANs, Produktauswahl, Key-Algorithmen, Laufzeitplan und leise Ausgabe
 - [Laufzeitverwaltung](validity-management.md): gespeicherte Laufzeiten manuell ändern und automatisch an künftige Limits anpassen
 - [Parallele RSA- und ECDSA-Zertifikate](dual-certificates.md): gleichzeitiger Betrieb für moderne und ältere TLS-Clients

docs/de/README.md

@@ -21,15 +21,15 @@ Auch die Verzeichnisse werden daraus konsistent abgeleitet:
 - `<output-dir-base>-rsa`
 - `<output-dir-base>-ecdsa`
 
+Wenn `--output-dir-base` fehlt, nutzt `certbro issue-pair` zunächst `<certificates-dir>/<common-name>` und hängt danach diese Suffixe an.
+
 Beispiel:
 
 ```sh
-sudo certbro --state-file /etc/certbro/state.json issue-pair \
+sudo certbro issue-pair \
   --name-base example-com \
   --common-name example.com \
   --dns-name www.example.com \
-  --product RapidSSL \
-  --output-dir-base /etc/certbro/example.com \
   --webserver nginx \
   --webserver-config /etc/nginx/nginx.conf
 ```
@@ -60,16 +60,17 @@ Mit dieser Konfiguration handeln TLS-Clients automatisch das jeweils passende Ze
 Beide Zertifikate bleiben eigenständige Renewal-Einheiten. Sie können:
 
 - gemeinsam über `certbro renew`
-- gemeinsam über `certbro --certificates-dir /etc/certbro renew`
 - einzeln über `certbro renew --name example-com-rsa` und `certbro renew --name example-com-ecdsa`
 
 erneuert werden.
 
+Wenn das Paar unter einem nicht-defaultigen Root liegt, einfach zusätzlich `--certificates-dir /pfad/zu/certbro` setzen.
+
 Beispiel:
 
 ```sh
-sudo certbro --state-file /etc/certbro/state.json renew --name example-com-rsa
-sudo certbro --state-file /etc/certbro/state.json renew --name example-com-ecdsa
+sudo certbro renew --name example-com-rsa
+sudo certbro renew --name example-com-ecdsa
 ```
 
 Wenn beide Zertifikate mit `--webserver nginx` konfiguriert sind, validiert und reloadet jeder erfolgreiche Renewal-Lauf `nginx` nach dem Deployment.

docs/de/dual-certificates.md

@@ -33,13 +33,8 @@ Diese Kommandos zuerst ausführen und die Werte anpassen:
 export REGFISH_API_KEY='YOUR_REGFISH_API_KEY'
 export HOST_FQDN='example.certbro.com'
 export CERTBRO_NAME='example-certbro-com'
-export CERTBRO_PRODUCT='RapidSSL'
-export CERTBRO_VALIDITY_DAYS='3'
-export CERTBRO_RENEW_BEFORE_DAYS='2'
-export CERTBRO_REISSUE_LEAD_DAYS='2'
 export WEBROOT="/var/www/${HOST_FQDN}/html"
 export CERTBRO_DIR="/etc/certbro/${HOST_FQDN}"
-export CERTBRO_STATE_FILE='/etc/certbro/state.json'
 ```
 
 ## 2. Ubuntu aktualisieren, Apache installieren und Firewall aktivieren
@@ -210,32 +205,28 @@ Dadurch wird der verifizierte API-Key im lokalen certbro-State gespeichert:
 ```sh
 sudo mkdir -p /etc/certbro
 
-sudo certbro --state-file "${CERTBRO_STATE_FILE}" configure \
-  --api-key "${REGFISH_API_KEY}"
+sudo certbro configure --api-key "${REGFISH_API_KEY}"
 ```
 
 ## 7. Zertifikat bestellen
 
-Zertifikatsverzeichnis anlegen und Zertifikat bestellen:
+Zertifikat bestellen. Mit den Linux-Defaults schreibt `certbro` nach `${CERTBRO_DIR}`:
 
 ```sh
-sudo certbro --state-file "${CERTBRO_STATE_FILE}" issue \
+sudo certbro issue \
   --name "${CERTBRO_NAME}" \
   --common-name "${HOST_FQDN}" \
-  --product "${CERTBRO_PRODUCT}" \
-  --validity-days "${CERTBRO_VALIDITY_DAYS}" \
-  --renew-before-days "${CERTBRO_RENEW_BEFORE_DAYS}" \
-  --reissue-lead-days "${CERTBRO_REISSUE_LEAD_DAYS}" \
-  --webserver apache \
-  --output-dir "${CERTBRO_DIR}"
+  --webserver apache
 ```
 
+Der Befehl oben nutzt das Default-DV-Produkt und die schedule-aware Default-Laufzeit. Wenn ein anderes Produkt oder eine kürzere Testlaufzeit gewünscht ist, einfach gezielt nicht-defaultige Flags wie `--product SecureSite` oder `--validity-days 30` ergänzen.
+
 Was während `certbro issue` passiert:
 
 - `certbro` erzeugt lokal einen frischen Private Key und CSR
 - es legt die TLS-Bestellung über die regfish TLS API an
 - es provisioniert automatisch die benötigten `dns-cname-token`-DCV-Records über die regfish DNS API
-- es wartet auf die Ausstellung
+- in diesem DV-Beispiel wartet es auf die Ausstellung
 - es lädt das Zertifikat herunter und deployt es auf stabile Pfade unter `${CERTBRO_DIR}/live/`
 - weil `--webserver apache` gesetzt ist, validiert es die Apache-Konfiguration und reloadet Apache nach dem Deployment
 
@@ -292,7 +283,7 @@ curl -I "https://${HOST_FQDN}"
 `systemd`-Service und Timer installieren:
 
 ```sh
-sudo certbro --state-file "${CERTBRO_STATE_FILE}" install --certificates-dir /etc/certbro
+sudo certbro install
 ```
 
 Timer prüfen:
@@ -307,25 +298,25 @@ sudo systemctl list-timers certbro.timer --all
 Verwalteten Zertifikatszustand anzeigen:
 
 ```sh
-sudo certbro --state-file "${CERTBRO_STATE_FILE}" list
+sudo certbro list
 ```
 
 Regulären Renewal-Lauf starten:
 
 ```sh
-sudo certbro --state-file "${CERTBRO_STATE_FILE}" renew --name "${CERTBRO_NAME}"
+sudo certbro renew --name "${CERTBRO_NAME}"
 ```
 
 Wenn der komplette Renewal-Pfad sofort getestet werden soll, kann er erzwungen werden:
 
 ```sh
-sudo certbro --state-file "${CERTBRO_STATE_FILE}" renew \
+sudo certbro renew \
   --name "${CERTBRO_NAME}" \
   --force \
-  --validity-days "${CERTBRO_VALIDITY_DAYS}"
+  --validity-days 30
 ```
 
-Das `3`-Tage-Beispiel funktioniert nur, weil die gespeicherten Lead-Tage auf `2` gesetzt wurden. `certbro` lehnt Laufzeiten ab, die nicht größer sind als die Renewal-Lead-Tage.
+Wenn sehr kurze Laufzeiten getestet werden sollen, müssen `--renew-before-days` und `--reissue-lead-days` unter der gekauften Basislaufzeit bleiben. Werte, die sofort wieder in das Renewal- oder Reissue-Fenster führen würden, lehnt `certbro` ab.
 
 `--force` nur verwenden, wenn bewusst ein echter Renewal- oder Reissue-Flow für Tests ausgelöst werden soll.