NeySlim/ultimate-ca-manager v2.242

on GitHub

[2.241] - 2026-10-18

Added

• FIPS mode (preview): with UCM_FIPS=1, UCM refuses to start unless its crypto libraries run on an active OpenSSL FIPS provider and pass their self-tests and PostgreSQL is reached over TLS, generates keys through the provider, and refuses what it does not approve (Ed25519 and Ed448, MD5, 3DES, scrypt and Argon2id, legacy PKCS#12 and JKS exports, PKCS#12 import, SCEP key transport in PKCS#1 v1.5, NTLM to a Microsoft CA). UCM is not FIPS validated itself. This is a first release of FIPS mode: feedback is welcome on #399 (requested by @Stryker-88).
• Docker: building with UCM_FIPS_BUILD=1 adds the OpenSSL 3.1.2 FIPS provider (CMVP certificate #4985) and links cryptography, psycopg2 and xmlsec to the system OpenSSL; the image runs in standard mode without UCM_FIPS, and the Helm chart has fips.enabled (#399).
• Service status shows the OpenSSL library and FIPS provider in use, and /api/v2/health reports fips_active (#399).
• Backups: "kdf": "pbkdf2" at creation writes an archive that a FIPS-mode instance can restore (#399).
• DEB and RPM: with UCM_FIPS_BUILD=1 in /etc/ucm/ucm.env before the install, RHEL 9 and Ubuntu 24.04 hosts build cryptography, psycopg2, lxml and xmlsec against the system OpenSSL, and a host in FIPS mode gets UCM_FIPS=1 and the readiness report (#399). Upgrades rebuild a package only when its version changed (pip's wheel cache otherwise), and the updater refuses the update when a build tool is missing.
• RPM for RHEL, AlmaLinux and Rocky Linux 9 (ucm-el9-2.242-1.el9.noarch.rpm), running on python3.12; the Fedora RPM is unchanged and the updater picks the build matching the host.
• FIPS readiness check: python -m scripts.fips_preflight, GET /api/v2/system/fips-preflight and a button under Settings > About list, on a standard instance, what FIPS mode would refuse (scrypt passwords, Ed25519 authorities, hmac-md5 TSIG, Argon2id backups, PostgreSQL without TLS...) with a remedy for each; scheduled backups gain a KDF setting (#399).

Changed

• Upgrade note: SAML responses and assertions signed or digested with SHA-1 are refused; an identity provider still using SHA-1 (an older ADFS relying party trust, for instance) must switch to SHA-256 (#399).
• Upgrade note: WSTEP requests whose WS-Security signature does not use RSA or ECDSA with SHA-256, SHA-384 or SHA-512 are refused (#399).
• python-jose, which nothing used, is no longer installed (#399).

Fixed

• DEB and RPM: an /etc/ucm/ucm.env written before the install was kept as is, without secrets, and the service did not start. Missing secrets and defaults are now added, without changing any value already there.

[2.240] - 2026-10-17

Added

• Policies: allowed signature hashes join allowed key types, and both now bind every issuance (CSR signing, ACME, SCEP, EST, WSTEP, CA creation, renewals, mTLS, TSA and OCSP responder certificates). A hash nobody chose yields to the weakest allowed one, and the issue and CA forms only offer what the policies allow (#397, requested by @Stryker-88).

Changed

• Upgrade note: an active policy with allowed key types or hashes now also refuses ACME, SCEP, EST and WSTEP requests outside them, and CAs created under them; review active policies before upgrading (#397).
• Passwords, 2FA backup codes and the EST, WSTEP and XCEP secrets are hashed with PBKDF2-HMAC-SHA256 (600,000 iterations) instead of scrypt, which a FIPS-mode host refuses and which stopped UCM from starting there. Outside FIPS mode, existing scrypt hashes keep working and are replaced at the next login; on a FIPS host they must be reset (#399).
• Docker image on Debian 13 (trixie) instead of 12: system OpenSSL 3.5 and PostgreSQL client 17. Existing volumes upgrade in place. cryptography is pinned to 50.0.2.

Fixed

• TSA: generating a signing certificate with an EC key but no curve reported an invalid curve; it now says a curve is required.
• CAs: creating a CA with keyAlgo EC, a lowercase name or an unsupported algorithm silently produced an RSA-2048 key. Valid spellings are honoured, anything else is refused, and the CA detail view reports the real key algorithm and size.
• Renewal: a certificate whose key family cannot be regenerated (DSA) was renewed with an RSA-2048 key, and a Microsoft CA rekey of an EC certificate produced an RSA-2048 request. The first is now refused and the second keeps its curve.
• ACME client: new orders ignored the configured key type and always used RSA-2048. They now take it, an unknown type fails at finalize instead of falling back to RSA-2048, and Ed25519 or P-521 CSRs are signed with the right hash.
• Key labels: Ed25519 and Ed448 CAs showed "Unknown", and the compliance grade presented secp256k1 or brainpool keys as NIST P-256 or P-384.
• HSM: syncing a PKCS#11 or Google Cloud KMS provider deleted every key row and unbound the CAs using them, because the key listing could not read any key and came back empty. The listing reads keys and their real curve again, and a sync never removes a key a CA uses nor anything when the listing reports errors.
• Templates: a key type saved in a legacy spelling (ec:p384) was advertised to Windows clients as RSA 2048 over XCEP, and issuing from it failed with "Unsupported key type". Key types are now stored under their canonical label, existing templates at upgrade.
• Certificates: only imports and renewals recorded the key algorithm (imports as "EdDSA" for Ed25519), so sorting by key algorithm or compliance grade lumped most certificates together. Every certificate now records it, existing ones at upgrade.
• HSM: a CA on a PKCS#11 RSA key failed with "Could not deserialize key data", because its public key was stored in PKCS#1 form under a SubjectPublicKeyInfo label. Keys already stored are repaired at their next use.
• Policies: an Ed25519 or Ed448 request was signed whatever the allowed key types said, and the policy form ticked key types on its own, so a new or edited policy restricted them unasked (#397).
• ACME DNS-01: UCM submitted the challenge as soon as one authoritative nameserver served the TXT record, so Let's Encrypt often got NXDOMAIN from another one. Every authoritative nameserver must now serve it, CNAME delegations included, followed by a configurable settle delay (10 s by default) (#395, reported by @ziller-hqs).

Full history: CHANGELOG.md