NeySlim/ultimate-ca-manager v2.223-rc3

on GitHub

[2.222] - 2026-09-06

Added

• PKCS#12 exports gained a compatibility mode. UCM's PKCS#12 archives use the OpenSSL 3 profile (PBES2 with AES-256-CBC, PBKDF2-SHA256 and an HMAC-SHA256 integrity check), which Android 15 and earlier, macOS 14 and earlier, Windows Server 2016 and earlier and Java before 8u301 / 11.0.1 cannot read and report as a wrong password. A Compatibility mode checkbox on the export dialogs (certificates, CAs, the user portal, mTLS downloads and key recovery) switches that archive to the 3DES/SHA-1 profile these importers accept, the same LegacyDES profile cert-manager and go-pkcs12 offer. The API takes it as legacy: true alongside password. AES-256 stays the default and the checkbox is a per-export choice, since the legacy profile protects the archive less well (#331, requested by @MakosHD)

Fixed

• The certificate template API no longer accepts ED25519 as a key type. It was allowed at save time but the issuance path cannot generate an Edwards key, so every certificate request from such a template failed with a 400. POST and PUT /api/v2/templates now reject it up front, and template import skips an ED25519 entry with a reason string instead of storing a template that can never issue. An existing ED25519 template must be switched to an RSA or EC key type before it can be edited again (#321 follow-up, contributed by @Hemsby)

[2.221] - 2026-09-05

Added

• ACME certificate profiles can bind a certificate template. An ACME order carries no template, so the built-in server could only ever issue the server certificate defaults; a profile (draft-ietf-acme-profiles) now has a Template field, and the bound template's key usage and extended key usage govern every certificate issued under that profile, on top of the key-algorithm rule. Validity and digest stay those of the profile. The issued certificate keeps the template link and records its divergences from the template defaults, as certificates from the issue form do. CA templates and templates carrying OCSP signing, timestamping, any-purpose or smartcard logon EKUs are refused at save time with a 400, and a template bound to a profile cannot be deleted until the profile is unbound, so a reused template id can never put a foreign template's key usage on ACME certificates; a template edited into an all-refused EKU set yields the server certificate default, never the CSR's own request. Backups carry a profile's template binding by template name and re-resolve it against the restored templates, since template ids are not portable between instances. PATCH /api/v2/acme/settings accepts template_id per profile and GET returns it (#327)

Fixed

• Dashboard: the SCEP service tile now reflects the SCEP configuration instead of always reporting the endpoint as available. It reads Disabled when SCEP is turned off, Enabled with no CA assigned or Enabled with CA not usable when neither the global CA nor an enabled SCEP profile can serve an enrollment (a CA the endpoint refuses, offline, without key or certificate, or HSM-backed, does not count), and Configured (with the usable profile count) otherwise (#328, reported by @JoseGoncalves)
• Dashboard: the SMTP service tile read configuration keys the Email settings page never writes, so a configured and working SMTP setup was reported as Not configured. It now reads the stored SMTP configuration with the sender's own readiness rule: Not configured without a host, Configured but disabled when the host is set but email is off, a warning when the port or From address is missing, and the host name when ready. The forgot-password endpoint used the same stale key and refused every reset request with "email not configured"; it now checks the same configuration (#329, reported by @JoseGoncalves)
• Certificate key usage now follows the key algorithm on every issuance path. An ECDSA leaf carried keyEncipherment, which is RSA key transport and cannot be performed with an EC key (RFC 5480 §3), unless it was issued from a template with the bit deselected; an ACME order has no template to select, so an ACME client got the bit regardless of key algorithm, and certificate linters flagged the result. A non-RSA key now never receives keyEncipherment or dataEncipherment, whether the built-in profile, the template or the CSR asked for them: a TLS server or client certificate on an EC key gets digitalSignature only, on the issue form, the approval workflow, Sign CSR, ACME, EST, SCEP and WSTEP alike, and an S/MIME certificate on an EC key keeps its encryption intent as keyAgreement, the bit ECDH-based S/MIME clients require on an EC recipient certificate. RSA certificates are unchanged (#327, reported by @JoseGoncalves)

Full history: CHANGELOG.md