Skip to content

ezSign - Key profiles

A key profile answers a different question from a group. A group says who may sign; a key profile says how the signature is made - which format, which eIDAS baseline level, which digest and algorithm, and which timestamp authority.

A profile also owns the signing keys. One profile may hold several keys over its lifetime - you generate a new one when a certificate is coming up for renewal - but only one of them signs at any moment.

Who does this

This is an administrator task. Operators never see this page. They notice it only in what they are offered when they come to sign, and in the kind of signature they get.

How profiles, groups and keys fit together

flowchart LR
    Group["Group<br/><i>who may sign</i>"] -->|assigned| Profile["Key profile<br/><i>how it is signed</i>"]
    Profile -->|owns| Keys["Signing keys<br/><i>one active at a time</i>"]
    Keys --> Cert["Certificate<br/><i>issued by your CA</i>"]

Figure: a group is granted key profiles, and each profile owns the keys that actually sign. One profile can be shared by several groups - which is why deleting a group never deletes its profiles.

Before you start

Nothing, in fact. A profile can be created on its own, before any group exists, and it will simply sit PENDING until it has a signing key. You can hand it to groups later, from Assign groups on this page or from the Groups page - the two edit the same thing from opposite ends.

Open the Key profiles page

In the administration area, open Manage → Key profiles in the left-hand menu.

The list shows one row per profile:

Column What it shows
PROFILE The name you gave the profile.
TYPE What the profile is for - Document today.
SIGNATURE The format, with the baseline level beneath it: PAdES over B-B.
GROUPS The groups that may sign with this profile, one chip each. Click the cell to change them.
KEYS How many signing keys the profile owns, or a dash if it has none yet. Click the number to see them.
STATE Whether the profile can sign - see What the states mean.
UPDATED The day the profile was last changed. The list is ordered by it, newest first, so anything you have just created or edited is at the top.
ACTIONS The key icon opens Manage keys, the pencil edits the profile, and the ⋮ menu holds view details, assign groups, disable and delete.

Click any row to open the read-only detail sheet. Looking is the default gesture; editing is the pencil, so nothing changes because you clicked to check something.

Search the list

The search box asks the server, not just the rows on your screen - so it also finds a profile a colleague created a minute ago, and it searches names and descriptions together.

What you type What you get
invoice Profiles matching that whole word.
"invoice pades" That exact phrase, in quotes.
invoice -archive Matches for invoice, minus anything mentioning archive.
inv* or *voice* A part-word match, for when you only remember a fragment.

A few letters on their own will find nothing

The plain search matches whole words, so inv does not find Invoice - it is not a word in its own right. Add a * and it will: inv*. This is what makes the search fast enough to run against every profile on every keystroke, and the wildcard is there for the rest.

Sorting a column, filtering, and paging through the list all work on whatever the search returned.

Create a profile

Click + New profile. The editor opens as its own page, with two cards.

Basics

Field What it is for
Name How the profile is identified everywhere else - in a group's checklist, in the audit trail, and to your colleagues. Something like Invoice PAdES-B reads better than Profile 1. Up to 255 characters, and no two profiles may share one.
Profile type What the profile is for. It does not change how the signature is produced. Document signing is the only type available today - code signing is planned, and needs a code-signing certificate this installation does not yet issue.
Description Free text, up to 255 characters. A good place for which CA issues its certificate, and any policy note.

eIDAS signature

Field What it is for
Format PAdES embeds the signature in a PDF. CAdES produces a CMS/PKCS#7 signature and XAdES an XML one.
Baseline level How much validation material travels with the signature - see below.
Packaging Only for CAdES and XAdES; PAdES has none, because a PDF signature is always embedded. The field appears only when the chosen format has a choice to make.
Digest The hash algorithm - SHA-256, SHA-384 or SHA-512.
Signature algorithm Determines the key type the profile's keys will be. Locked once the profile owns a key; see below.
TSA URL The timestamp authority. Required for B-T, B-LT and B-LTA, which each embed a trusted timestamp, and for a content timestamp at any level. Leave it empty for a plain B-B profile - a URL nothing can use is refused rather than stored. Use a plain http://host/path or https://host/path address: a URL carrying a user name and password is refused, because those are never sent.
Embed content timestamp Adds a timestamp over the document content itself, in addition to any signature timestamp. It needs a timestamp authority of its own right, so ticking it makes the TSA URL required even at B-B.

The baseline levels

Level What it adds Needs a TSA Needs revocation data
B-B The signature itself. Only for a content timestamp No
B-T A trusted timestamp, proving when it was signed. Yes No
B-LT Certificates and revocation data, so it can still be validated after the certificate expires. Yes Yes
B-LTA Archive timestamps, extending that for the long term. Yes Yes

What B-LT and B-LTA ask of your certificate

These two levels embed the evidence a verifier would otherwise have to fetch years later, and ezSign can only embed evidence that exists. Two things have to be true of the signing key's certificate chain, and both are checked when the certificate is imported rather than when a document is signed:

  • The chain includes its root. Paste the whole bundle - end-entity certificate, any intermediates, and the root - not just the part your CA calls "the certificate". Without the root there is nothing to anchor the validation material on.
  • The certificates publish revocation data ezSign can fetch. Each one except the root has to name an OCSP responder or a CRL distribution point as an http:// or https:// address. Certificates from a commercial Document-Signing CA do. An address published only into a directory
  • an LDAP URL, or a distribution point written as a directory name, which is what Microsoft ADCS emits when configured that way - does not count: ezSign fetches revocation data over HTTP only, so there would be nothing it could retrieve.

If either is missing, ezSign refuses to put the key into service for a B-LT or B-LTA profile and says which one it was. Choose B-T, which needs neither, or obtain a certificate that carries them.

Your timestamp authority's certificate has to publish revocation data too

A B-LT or B-LTA signature covers every certificate it rests on, and that includes the ones the timestamp authority returns inside its own response. Those arrive over the network and are not known until a timestamp has been fetched, so they cannot be checked when you save the profile - if that authority's CA publishes no reachable OCSP or CRL, every document fails with Could not collect validation material even though the signing certificate is faultless. A public, eIDAS-qualified timestamp authority always publishes it; an internal one may not. Test one document after changing the TSA URL on a B-LT or B-LTA profile.

Where the timestamps and revocation data come from

Your installation fetches them, over the network, from the TSA URL on the profile and from the addresses printed inside your own certificates. If ezSign runs behind an outbound proxy, the one configured on the Proxy settings page is used - there is no second place to configure it.

Why a dropdown may hold fewer options than you expect

A dropdown offers only what this installation can actually produce, and the line above the fields says what that is - This installation signs PAdES, for example. A short list is not a fault.

An existing profile keeps the value it was saved with, even after the installation stops offering it: the dropdown still shows that value, still selected, so editing anything else on the profile leaves it alone. Change it and it is gone - it cannot be chosen again until the installation is configured to offer it once more.

The reason it works this way: a profile saved as B-LTA whose signature came out as B-B would be a quiet and serious surprise, so an option is withheld rather than silently downgraded.

All four baseline levels are offered by default. Formats other than PAdES are not, because ezSign signs PDFs. If you need a format or level that is not offered, raise it with whoever operates your installation - it is a deployment matter, not something to change on this page.

Click Create profile. The profile is created PENDING.

What the states mean

State What it means
PENDING No active signing key yet. The profile is configured but cannot sign. Every profile starts here.
ENABLED It has an active signing key, and can sign.
DISABLED An administrator has taken it out of service. Nothing can be signed with it until it is re-enabled.

PENDING and ENABLED are worked out from the profile's keys - you never set them by hand. DISABLED is the one you control, and it outranks the other two: a disabled profile stays disabled even if its keys change.

A profile with a key can still be PENDING

The KEYS column counts all of a profile's keys, including one that is still waiting for its certificate. Only an active key makes a profile ENABLED, so a key that has been generated but not yet activated leaves the profile PENDING.

The state does not track certificate expiry. A profile whose certificate has lapsed still reads ENABLED; the signature is what fails, at the moment of signing.

See everything about a profile

Click the row, or choose View details from the ⋮ menu.

The table shows eight of a profile's twenty-odd fields. The sheet shows the rest: packaging, digest, signature algorithm, TSA URL, the content-timestamp flag, the full description, the groups holding it, and both timestamps to the minute. It also carries the profile's ID - the value to quote in a support ticket.

Nothing on the sheet is editable. Edit profile in its footer takes you to the editor, and the signing-key count takes you to Manage keys.

Manage keys

Click the KEYS cell, or the key icon on the row.

The dialog lists every signing key the profile owns - its label, its status, and the serial number of its certificate, or No certificate yet where none has been issued.

It is a summary, not a workshop. Importing a certificate, activating, renewing, suspending and deleting all live on the Keys & certificates page, which shows the same keys across every profile at once.

Generate keypair is the exception, and it opens here - this dialog closes and the generate dialog takes its place, already set to this profile. When the key is made you get its CSR without leaving the page, and the profile's key count updates behind you.

Assign groups

Click the GROUPS cell, or choose Assign groups from the ⋮ menu.

Tick the groups that may sign with this profile and untick those that may not. What is ticked when you press Save assignment is what the profile ends up with, so unticking everything removes it everywhere.

This is the same relationship the Groups page edits, read from the other end: there you ask what may this group sign with, here who may use this profile. Either is fine - use whichever matches the question you are answering.

Taking the last profile away from a group stops that group signing

A group's state is worked out from the profiles it holds: with one it is ACTIVE, with none it is PENDING, and a PENDING group cannot sign at all.

So if unticking a box would leave a group with no key profile whatsoever, ezSign marks that row, raises a warning, and will not save until you tick Unassign anyway. You are on a profile's page, not the group's, and a group's operators should not quietly lose the ability to sign with no row on screen to show it.

Edit a profile

Click the pencil on a profile's row. Everything in the editor can be changed, with one exception.

The algorithm locks once a key exists

Once a profile owns a signing key, its signature algorithm cannot move to a different key type. A profile that generated an EC key cannot become RSA, because the key it already holds could not sign under the new algorithm. The field is shown as read-only, with the reason beside it.

Moving between the two RSA paddings - PKCS#1 v1.5 and PSS - is allowed, because the same keypair signs under either.

To change key type, create a new profile.

Disable a profile

From the row's ⋮ menu, choose Disable profile. Groups holding it can no longer sign with it - operators stop being offered it immediately. Nothing is deleted, and its keys and certificates are untouched.

Re-enabling does not force it back into service: the profile returns to ENABLED only if it still has an active signing key, and to PENDING if it does not.

Delete a profile

From the row's ⋮ menu, choose Delete profile.

Certificates stay valid until you revoke them at your CA

Deleting a profile deletes its signing keys - from ezSign, from the signing service, and the HSM is asked to remove the key material too. The licensed quota those keys were holding comes back.

What deleting cannot touch is the certificates. Any certificate issued for those keys stays valid until your CA says otherwise, so revoke it with your CA provider first - ezSign cannot revoke on your behalf, and the serial numbers you would need to quote go with the profile.

HSM removal is attempted rather than guaranteed: if the partition cannot be reached the records still go, and the key material is left behind.

A profile with an active signing key cannot be deleted. The dialog names the key and asks you to suspend it, or activate another, first - deleting the key a profile is signing with should never be something that happens on the way to deleting something else.

A profile that is still assigned to a group cannot be deleted. The dialog names the groups holding it and asks you to unassign it first, which you can do from Assign groups on this page. There is no override, on purpose: a certificate is expensive, and a profile should never disappear as a side effect of something else.

A profile with documents still being signed cannot be deleted either - try again once the batch finishes. Documents that have already been signed do not block anything: they keep their signed bytes and their audit record, and simply lose their link to the profile.

Disable rather than delete

Unless the profile was created by mistake, disabling is almost always the right move. It stops signing immediately, is reversed with one click, and keeps the keys and certificates you paid for.

Troubleshooting

What you see What it means
The search box returns nothing for a few letters The plain search matches whole words. Add a * - inv* finds Invoice.
Another key profile already uses this name Names are unique. Pick a different one.
“…” is not available on this installation yet The value submitted is one the signing engine cannot produce, so it is not offered. See Why the lists are short above.
B-LTA embeds a trusted timestamp, so a TSA URL is required Add a TSA URL, or drop the level to B-B.
A content timestamp is obtained from a timestamp authority, so a TSA URL is required Add a TSA URL, or untick Embed content timestamp.
… embeds no timestamp and no content timestamp was requested, so this TSA URL would never be used Clear the TSA URL, or choose a level that uses one.
Remove the user name and password from the TSA URL Credentials in the address are never sent, so the request would go out unauthenticated. Use a plain URL; if your authority requires authentication, reach it another way.
The signing certificate chain stops before its root certificate… Re-import the certificate with the full chain, root included, or choose a level below B-LT.
No certificate in the signing chain publishes an OCSP responder or a CRL… The CA that issued this certificate publishes no revocation data ezSign can fetch, so B-LT and B-LTA are impossible with it. Note this also covers a CA that publishes only to a directory (an LDAP address, or a distribution point written as a directory name): the extension is there, but there is no HTTP address behind it. Use a certificate whose CA publishes over HTTP, or choose B-T.
A document fails with Timestamping failed The profile's timestamp authority could not be reached or refused the request. Check the TSA URL and try again; the details are in the server log.
A document fails with Could not collect validation material The revocation data a B-LT or B-LTA signature embeds could not be fetched. Check that the addresses inside your certificate are reachable from this installation - and those inside your timestamp authority's certificate, which are not checked when the profile is saved.
PAdES has no packaging Packaging applies to CAdES and XAdES only.
This profile already has N signing key(s), so the key type cannot change The algorithm lock. Create a new profile instead.
Key profile “…” is assigned to N group(s) Unassign it first, from Assign groups on this page, then delete.
Key profile “…” has N document(s) still being signed Wait for the batch to finish.
One group would be left with no key profile at all You unticked the only profile a group holds. Tick Unassign anyway to accept it, or leave the box ticked.
This key profile no longer exists A colleague deleted it while your list was open. Reload the page.
A profile stays PENDING after a key is generated The key is not the active one, or has no certificate yet.

FAQ

What is the difference between a group and a key profile?

A group says who may sign; a key profile says how the signature is made. The group maps the team values in someone's single sign-on token, while the profile holds the signature format, eIDAS baseline level, digest, algorithm and timestamp authority - and owns the signing keys. Groups are granted key profiles, and one profile can be shared by several groups.

Why is my new key profile PENDING?

Because it has no active signing key yet. Every profile is created PENDING. It becomes ENABLED once a signing key has been generated, its certificate imported and the key activated. A profile that already has a key can still be PENDING if that key is not the active one.

Why does the editor list only one signature format or baseline level?

Because a dropdown offers only what the signing engine on that installation can actually produce, and a line above the fields names it. Anything ezSign models but cannot yet deliver is left out, so a profile cannot be saved as, say, B-LTA while the signature it produces is actually B-B. Leaving the option out is only the convenience: the server refuses such a value too. The available options widen as engine support arrives; if you need a format or level that is not offered, raise it with whoever operates the installation.

Why can I not change a profile's signature algorithm?

Because the profile already owns a signing key, and key material generated for one algorithm family cannot sign under another - an EC key cannot produce an RSA signature. Moving between the two RSA paddings, PKCS#1 v1.5 and PSS, is still allowed because the same keypair signs under either. To change key type, create a new profile.

When does a key profile need a TSA URL?

For baseline levels B-T, B-LT and B-LTA, each of which embeds a trusted timestamp and therefore cannot be produced without a timestamp authority - and for Embed content timestamp, which needs one at any level, B-B included. A plain B-B profile needs none, and a TSA URL on one is refused rather than stored, because nothing would ever read it. ezSign marks the field required as soon as you pick a timestamped level or tick the box.

Why does B-LT fail when my signing certificate is fine?

Because a B-LT or B-LTA signature covers every certificate it rests on, and that includes the certificates your timestamp authority returns inside its own response. ezSign checks the signing key's chain when the certificate is imported, but the timestamp authority's chain arrives over the network and is not known until a timestamp has been fetched, so it cannot be checked when you save the profile. If that authority's CA publishes no reachable OCSP responder or CRL, every document fails with Could not collect validation material even though the signing certificate is faultless. Use a public, eIDAS-qualified timestamp authority, or one whose CA publishes revocation data, and sign one test document after changing the TSA URL on a B-LT or B-LTA profile.

Where do I choose which groups can use a profile?

Either end works. On this page, click the GROUPS cell on the profile's row, or choose Assign groups from its ⋮ menu. On the Groups page, the layers icon on a group's row does the same thing from the group's side. Use whichever matches the question you are answering - who may use this profile, or what may this group sign with.

Does deleting a key profile delete its signing keys?

It removes them from ezSign, but not from the HSM - the key material stays there, and any certificate issued for it stays valid until you revoke it. Revoke with your CA provider first: ezSign cannot revoke on your behalf, and the certificate serial numbers you would need to quote are deleted along with the profile. Disabling instead stops signing immediately while keeping everything intact.

Why can I not delete a key profile that is assigned to a group?

Because a profile should never disappear as a side effect of something else. Unassign it first - from Assign groups on this page, or from the group's own row on the Groups page - and then delete it. The confirmation names every group still holding it. There is no override.

Do documents already signed with a profile stop it from being deleted?

No. Only documents still being signed block a delete, and only until that batch finishes. Documents already signed keep their signed bytes, their embedded certificate and their audit record, and simply lose their link to the profile - so a superseded profile can be retired without touching your signing history.

Should I disable or delete a key profile?

Disable it unless it was created by mistake. Disabling stops every group signing with it immediately, is reversed with one click, and keeps the signing keys and paid-for certificates. Deleting is permanent. Re-enabling later returns the profile to ENABLED only if it still has an active signing key, and to PENDING if it does not.