CI: restore Python 3.14 matrix leg once josepy/certbot stack is upgraded

[fabriziosalmi]

Context

CI previously ran the test matrix against both Python 3.12 (production via Dockerfile) and Python 3.14. The 3.14 leg was removed in commit c10f87f's follow-up because the pinned runtime stack is not 3.14-compatible:

• certbot==2.10.0 pulls acme==3.3.0 which requires josepy<2, so we are stuck on josepy==1.13.0.
• josepy==1.13.0 raises at class definition time under Python 3.14's PEP 649 deferred annotation evaluation:

  ValueError: Field `alg` in JSONObject `Header` has no type annotation.
  

• Dockerfile ships on Python 3.12 so production is unaffected.

Running a CI leg against a stack we don't support would either (a) silently skip the tests that actually hit the import, or (b) fail forever. Neither is useful.

Why this is not just a CI cleanup

The underlying stack upgrade is the same one gating Path A of the 'Zero-Domain Certificates' analysis (IP certificates / Let's Encrypt shortlived profile), which requires certbot>=5.3. That upgrade cascades into:

• certbot==2.10.0 → 5.x
• acme + josepy → matching 5.x-compatible versions
• ~23 certbot-dns-* plugins pinned to ==2.10.0 matching certbot — each one needs a version that works against certbot 5.x, or a replacement
• Full DNS provider matrix re-test

So this issue and Path A share the same upgrade surface.

Definition of done

• .github/workflows/ci.yml matrix includes a Python 3.14 leg again.
• The 3.14 leg is green end-to-end against the (upgraded) requirements pins.
• tests/test_edgedns_credentials_format.py::test_certbot_credentials_parser_reads_all_four_keys runs (not skipped) on both 3.12 and 3.14.
• Dockerfile may or may not switch to 3.14 at the same time — decision taken in this issue.

Link

• Removal commit / reasoning: see follow-up commit after c10f87f
• Path A spike analysis: private notes (summary: certbot 5.3+ required for IP certs, same upgrade blocker)

[fabriziosalmi]

Status check (v2.4.0): blocker still real, keeping this open.

`requirements.txt` is still pinned to `certbot==2.10.0` + `josepy==1.13.0`, and ~23 `certbot-dns-*` plugins are pinned to matching `==2.10.0`. The josepy 1.13 PEP 649 import-time crash on Python 3.14 hasn't gone away — the only path forward remains the certbot 2→5 stack upgrade plus full DNS provider matrix re-test.

Production is on Python 3.12 (Dockerfile), so this stays an enhancement / tracking issue rather than a production blocker. Re-evaluating once we tackle the stack upgrade for Path A (IP certificates / shortlived profile).

[ITJamie]

This may not be the right place to ask this question.
But was there a technical reason to use certbot v2 instead of v3 or newer during the project start? (Just looking for history/backstory)

[fabriziosalmi]

This may not be the right place to ask this question. But was there a technical reason to use certbot v2 instead of v3 or newer during the project start? (Just looking for history/backstory)

Good question, and this is actually the right place. Short answer: the third-party DNS plugin ecosystem, not certbot itself. The project started (June 2025) on 2.7.4 with Cloudflare only; as multi-provider support landed that same month we briefly ran 2.11.0, and by mid-July — with ~20 certbot-dns-* plugins wired in — we settled on 2.10.0 as the highest version where the whole plugin set (official lockstep-versioned plugins plus third-party ones like dns-azure, edgedns, duckdns, porkbun, godaddy, multi) coexisted. Certbot 3.x was out at the time, but third-party plugin compatibility lagged it significantly, and CertMate's value is the breadth of that provider matrix. The upgrade to the 5.x stack is exactly what this issue tracks — it cascades through acme/josepy and every plugin pin, needs a full provider matrix re-test, and also unlocks the LE shortlived/IP-cert path, so it's planned as a dedicated effort rather than a version bump.

[ITJamie]

Thanks for the history!

One thing to note is theres also a major new validation method coming soon. certbot/certbot#10549

The pr for this is now almost finalised and likely there will be requests coming for this soon after.

This would almost entirely kill off the uses for domain cname alias validation method since the new format txt record would be created once only.