Compliance Profiles

Compliance Profiles

Policies in code, aligned with a versioned European reference text, attached to a certificate authority.

Version: 2.244 (dev)

---

Overview

A compliance profile is a built-in policy that binds everything a CA issues. It works like the policy FIPS mode applies to every CA, and like any policy it is checked on every issuance path: the issue form, signing a stored request, renewals, ACME, SCEP, EST, WSTEP, CA creation, the OCSP responder and the timestamping signer.

Profiles are aligned with a published reference text. They help a deployment follow that text; they do not make UCM, or a certificate authority run with it, certified, qualified or approved by any authority. See Limits.

Each rule is graded:

• Refusal: what the reference text imposes. The request fails with a message that names the rule.
• Advice: a recommendation or a legacy choice. The request succeeds and the response carries a notice (meta.notices).

A profile is stored per CA. A CA without a profile behaves as before. Attaching a profile only governs what the CA signs from then on; nothing already issued is re-checked or re-signed.

---

The three profiles

Name	Reference	Source
anssi	ANSSI-PG-083 3.00 (ANSSI guide on cryptographic mechanisms)	PDF
bsi	BSI-TR-02102-1 2026-01	PDF
eu-acm	ECCG-ACM 2.0 (Agreed Cryptographic Mechanisms of the European cybersecurity certification scheme, the reference behind eIDAS-related work)	ENISA guidelines

---

Rules as UCM applies them

Key types use UCM's labels (RSA-3072, EC-P256, ...). "NIST curves" means EC-P256, EC-P384 and EC-P521. All three profiles accept the digests SHA-256, SHA-384 and SHA-512 and refuse the others.

Rule	anssi	bsi	eu-acm
Key types accepted	RSA-2048, RSA-3072, RSA-4096, NIST curves, Brainpool curves, Ed25519, Ed448	RSA-3072, RSA-4096, Brainpool curves, NIST curves	RSA-2048, RSA-3072, RSA-4096, NIST curves, Brainpool curves
Key types refused	everything else	everything else, Ed25519 and Ed448 included	everything else, Ed25519 and Ed448 included
Key types advised against	RSA-2048, Brainpool curves, Ed25519, Ed448	NIST curves (notice only)	RSA-2048
RSA-2048 end date	refusal when the certificate is valid beyond 2030-12-31	refused	refusal when valid beyond 2028-12-31, and no new RSA-2048 certificate after 2026-12-31
Signature schemes accepted	RSA PKCS#1 v1.5, RSA-PSS, ECDSA, EdDSA	RSA-PSS, ECDSA	RSA PKCS#1 v1.5, RSA-PSS, ECDSA
Signature schemes advised against	RSA PKCS#1 v1.5, EdDSA	none	RSA PKCS#1 v1.5
Validity horizon advice	none	notice when a certificate is valid beyond 2035-12-31	none
CA key in a hardware module	not required	not required	required: a software, SoftHSM or OpenBao key is refused; an Azure or Google key only counts when it is HSM-protected
Declared HSM certification	not required	not required	required when the CA key is on an HSM: see the note below
TSA signer key	advice: EC key	refusal unless EC	advice: EC key
Post-quantum signature alone (ML-DSA)	refused without a classical certificate paired with it	same	same
PKCS#12 with 3DES/SHA-1	refused	refused	refused

Notes:

• The signature scheme rule applies to the key that signs: the CA key. An RSA CA created with PKCS#1 v1.5 can be switched to RSA-PSS in its settings (see CA Management).
• The horizon rules compare the end date of the issued certificate (or of the CA) with the date, so a short-lived RSA-2048 leaf is still accepted under anssi until the date arrives.
• A policy whose allowed key types are all unknown to UCM now refuses issuance, instead of silently allowing everything. The preflight reports it.
• For the HSM rule, a key in a PKCS#11 module or AWS CloudHSM counts as HSM-held. SoftHSM, recognised by its module path or its provider name, is refused. An OpenBao transit key is a software key and is refused. An Azure Key Vault key counts when its type is RSA-HSM or EC-HSM, a Google Cloud KMS key when its protection level is HSM; UCM records this when it creates or syncs the key, so sync the provider keys of an older key before attaching eu-acm. A key whose protection UCM has not recorded is refused.
• Under eu-acm, a CA key on an HSM also needs an accepted certification declared on its HSM provider (see HSM Support). Common Criteria EAL 4+ and EUCC (high assurance) are accepted without an end date; FIPS 140-3 level 3 is accepted until 2030-12-31 (Implementing Regulation (EU) 2025/1943); FIPS 140-2 level 3, Other and no declaration are refused. UCM does not verify the declaration.
• UCM does not issue ML-DSA certificates today. The rule is in place so a future release cannot issue one alone under a profile.
• Brainpool curves (EC-BP256, EC-BP384, EC-BP512) are accepted by every profile. Under bsi they are the preferred curves and the NIST curves get a notice. Under anssi they get a notice: the guide lists them among its curves but not among its signature mechanisms. Brainpool is refused in FIPS mode, and most browsers, Go, rustls and Java without Bouncy Castle do not accept it in TLS: see Brainpool curves before using it for TLS certificates.

---

Choosing a profile

• anssi: the French guide. Broadest set of accepted keys; RSA-2048 and Ed25519 are accepted but advised against.
• bsi: the German technical guideline. Strictest on keys and schemes: RSA-PSS or ECDSA only, no EdDSA, RSA at 3072 bits or more.
• eu-acm: the European agreed mechanisms. Requires the CA key to be in an HSM, and closes RSA-2048 issuance at the end of 2026.

When you create a CA you can name a profile: the Compliance profile selector of the Create CA form, or complianceProfile in the API. For an intermediate CA the form proposes the parent's profile, otherwise the instance default, and it only offers the keys, digests and RSA signature schemes the profile allows (RSA-PSS only under bsi, HSM storage only under eu-acm). The CA you create must itself meet the profile: its key type, its signature scheme and, for eu-acm, an HSM-held key. For an intermediate CA the parent signs its certificate, so the parent's key must meet the new CA's profile too: a bsi sub-CA needs a parent that signs RSA-PSS or ECDSA, an eu-acm sub-CA a parent whose key is HSM-held. The server inherits nothing silently: a sub-CA gets the profile you name, or the instance default.

If the request names no profile, the instance default applies. Set it in Settings > About > Compliance profiles (permission admin:settings), or with PATCH /api/v2/settings/general and {"compliance_profile_default": "bsi"} (empty means none). The change is recorded in the audit log.

---

Attaching a profile to an existing CA

In the CA details, Attach a profile (or Change profile) runs the preflight for the chosen profile on that CA, shows its findings, and asks for confirmation; Remove profile takes it off. In the interface, attaching or changing needs write:cas and admin:system (the preflight requires it); removing needs write:cas. The API takes the change with write:cas alone and runs no preflight: run it first.

1. Run the preflight for the profile and that CA.
2. Read what it reports: blockers are what the profile would refuse from now on, warnings are what it would advise against.
3. Confirm. In the API, PATCH /api/v2/cas/{id} with {"complianceProfile": "bsi"}; the change is recorded in the audit log (compliance_profile none -> bsi).

Nothing is re-signed and no existing certificate is revoked. An existing CA that the profile refuses (for example an RSA-2048 CA under bsi) simply cannot issue any more; move issuance to a new CA. Send null or an empty string to remove the profile.

---

Preflight

The preflight lists what a profile would refuse or advise against on this instance, without changing anything.

Interface. Settings > About > Compliance profiles: pick a profile and run the check, next to the FIPS preflight.

API. GET /api/v2/system/compliance-preflight?profile=bsi[&ca=ID] (permission admin:system). It answers 400 for an unknown profile or a malformed ca, and 404 for a CA that does not exist. See the API reference.

Command line. From the backend directory of an installation:

python -m scripts.compliance_preflight --profile bsi [--ca ID] [--json]

The database is opened read-only. Exit codes:

Code	Meaning
0	nothing blocks
1	at least one blocker
2	a check could not run, or the profile or the CA is unknown

Checks. Blockers: CA key type, Ed25519/Ed448 CA keys, CA signature scheme, CA validity beyond the key horizon, CA key not in an HSM when required, CA key on an HSM without an accepted declared certification (ca.hsm_certification, which lists the CAs concerned), certificates valid beyond a horizon, templates, policies and ACME profiles that allow what the profile refuses, policies whose key types are all unknown, delegated OCSP responder keys, and the timestamping signer key. Each, except ca.hsm_certification, has an advisory twin at warning (or information) level for what the profile only advises against.

---

Interaction with FIPS mode

A profile and FIPS mode are cumulative: both policies apply and the result is their intersection. For example, FIPS plus bsi leaves NIST curves, RSA at 3072 bits or more, RSA-PSS and ECDSA. GET /api/v2/policies/effective returns the combined result for a CA.

---

Timestamping

Timestamp tokens are always signed with RSA PKCS#1 v1.5 (or ECDSA for an EC signer). Under bsi, a TSA signer with an RSA key is refused and the message asks for an EC signer; under anssi and eu-acm an EC signer is advised. See TSA.

---

Algorithms UCM does not support

UCM does not issue certificates, CRLs or signatures with the algorithms below, and no compliance profile accepts them.

Algorithm	Why it is not supported
FRP256v1 (French ANSSI curve)	Not provided by OpenSSL 3.5, by the Python cryptography library or by asn1crypto, so there is no signing or key generation path to build on. Reference texts such as the ECCG agreed mechanisms list it, but no mainstream client or library implements it.
SM2, SM3, SM4 (Chinese national suite)	SM2 signatures are not available in the Python cryptography library, and some distribution builds of OpenSSL are compiled without SM2 and SM4. Mainstream browsers and operating system stacks (for example Windows CNG) do not validate SM2 certificates.
GOST R 34.10-2012, GOST R 34.11-2012, GOST R 34.12-2015 (Russian national suite)	Not part of OpenSSL 3.5 or of the Python cryptography library; the external GOST engine is not packaged with UCM. Only specialised clients implement it.

What UCM does with them:

• No issuance. They cannot be chosen for a CA key, a certificate key or a signature, in the interface, the API, templates or any enrollment protocol.
• Tolerant import. A certificate imported into the trust store that uses one of these algorithms is stored and displayed by its OID, without an error.
• Chains marked unverifiable. UCM cannot check signatures made with these algorithms, so a chain that depends on one is marked as not verifiable instead of valid or invalid.

---

Limits

• Not a certification or a qualification. A profile helps align UCM's behavior with a reference text. It does not make UCM, or a CA run with it, certified, qualified or approved, and it covers algorithms and key handling, not the organizational, audit or process requirements of a scheme such as eIDAS.
• Reference versions are fixed in code and named above; a new edition of a text arrives with a new UCM release.
• FRP256v1, SM2/SM3/SM4 and GOST suites are not supported: see Algorithms UCM does not support.
• Ed25519 and Ed448 keys are refused under bsi and eu-acm and advised against under anssi.

---

Related Documentation

• FIPS Mode: validated cryptographic module, combined with a profile by intersection
• Approval Workflows: policies and their rules
• CA Management: creating a CA, RSA-PSS
• HSM Support: HSM-held CA keys, required by eu-acm
• TSA: timestamp signer
• API Reference