Mark CNs with no issued cert file in the TUI and CLI lists

Renewing such a CN now works (it skips the revoke), but the list gave no
hint that it was a special case until the workflow printed its warning.
Flag it at selection time instead.

_load_current_certs() sets CertInfo.has_cert_file, so every view built on
it — the TUI list, --list and --list-all — gets the flag for free. The
stat happens after the per-CN dedup, so a CN with several V-lines in
index.txt is checked once.

TUI rows render "(no cert file)" between the CN and the email, placed
before the email so a long address truncating at the right edge cannot
push the marker off screen. --list/--list-all grow a trailing CERT
column holding MISSING; the column is omitted entirely when every CN has
its .crt, since it is pure noise on a healthy PKI.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Vlad Doloman
2026-08-15 04:11:37 +03:00
parent 9e5df8d9bb
commit 8adee23a69
5 changed files with 139 additions and 9 deletions

View File

@@ -31,6 +31,7 @@ Edit the `SETTINGS` block at the top of `openvpncertupdate.py` before first run.
| `--gen-crl` | Regenerate and copy CRL only |
| `--list` | List recently-expired/soon-to-expire CNs (per `DAYS_PAST`/`DAYS_AHEAD`) with email; read-only, no CA passphrase needed |
| `--list-all` | List all CNs with email; read-only, no CA passphrase needed |
| | Both grow a trailing `CERT` column marking `MISSING` CNs — see `CertInfo.has_cert_file`. The column is omitted entirely when every CN has its `.crt` |
| `--email EMAIL` | Recipient address |
| `--send-email` | Force email delivery |
| `--no-send-email` | Skip email; print URL to stdout |
@@ -66,7 +67,7 @@ python3 -m pytest tests/test_pki.py::test_sorted_ascending -v # single test
## Re-issue workflow
0. `has_issued_cert()` gates steps 12: if `<PKI_DIR>/issued/<CN>.crt` is absent, both are **skipped** with a warning and the workflow goes straight to step 3. EasyRSA reads the serial out of the `.crt` itself, so `revoke-issued` can only fail on such a CN — and there is nothing to add to the CRL either. This happens when an `index.txt` is carried over from an older EasyRSA install without the `issued/` files: the index still lists V-status certs whose `.crt` never came along. `--revoke` / the TUI `r` key deliberately do *not* skip — an explicit revoke request should fail loudly rather than silently no-op
0. `has_issued_cert()` gates steps 12: if `<PKI_DIR>/issued/<CN>.crt` is absent, both are **skipped** with a warning and the workflow goes straight to step 3. EasyRSA reads the serial out of the `.crt` itself, so `revoke-issued` can only fail on such a CN — and there is nothing to add to the CRL either. This happens when an `index.txt` is carried over from an older EasyRSA install without the `issued/` files: the index still lists V-status certs whose `.crt` never came along. `--revoke` / the TUI `r` key deliberately do *not* skip — an explicit revoke request should fail loudly rather than silently no-op. Such CNs are flagged before the user picks one: `_load_current_certs()` sets `CertInfo.has_cert_file` (one stat per CN, after the dedup), rendered as `(no cert)` before the email in the TUI list and as a `MISSING` cell in the `CERT` column of `--list`/`--list-all`
1. `revoke-issued <CN>` — archives old key + CSR to `pki/revoked/`
2. CRL regenerated and copied to `CRL_DEST_PATH` immediately after the revoke succeeds — the old cert is already revoked at this point, so the published CRL would otherwise be stale until a separate manual regen. Not fatal: a failure here is reported but the workflow continues to step 3 (a new cert is more urgent than a fresh CRL, and "Regenerate CRL" / `--gen-crl` remain available to retry)
3. `build-client-full <CN> --passout=pass:<pw>` — generates new key + cert