---
title: "GeCert"
description: "GeCert: Lacuna Software's key and certificate manager that keeps keys in an HSM, Azure Key Vault, PKCS #11 device or the database, controls who uses each certificate and makes the certificates available on Windows through Gecert Connect."
canonical: "https://docs.lacunasoftware.com/en-us/articles/gecert"
locale: "en"
product: "GeCert"
last_updated: "2026-10-13"
---

# GeCert

GeCert is Lacuna Software's key and certificate manager for organizations. It keeps the private keys of the certificates in **key stores**
(a Kryptus HSM, Azure Key Vault, a PKCS #11 device or its own database), defines **which users may use each certificate** and makes those
certificates available on each user's Windows through the **Gecert Connect** application. Any Windows application can then sign, decrypt or
authenticate with the organization's certificate, and the private key never leaves the key store. Every use of a key is recorded.

You can use a GeCert instance hosted by Lacuna or host your own instance ([on-premises](https://docs.lacunasoftware.com/en-us/articles/gecert/on-premises)). The web application and
Gecert Connect are available in Portuguese, English and Spanish.

## Components

* **GeCert server**: the web application, with an area for each organization and the administration area (**Sys Admin**), and the
  [REST API](https://docs.lacunasoftware.com/en-us/articles/gecert/api) used by the web application and by Gecert Connect. Users sign in with a [GrantID](https://docs.lacunasoftware.com/en-us/articles/grant-id) account
  (OpenID Connect). 
* **[Gecert Connect](https://docs.lacunasoftware.com/en-us/articles/gecert/gecert-connect)**: the application that sits in the Windows tray of each user. It installs the certificates the
  user has access to in the Windows certificate store and serves the signing and decryption requests, forwarding them to the server.

* **Lacuna Key Storage Provider (KSP)**: a key storage provider for Windows CNG (Cryptography API: Next Generation), installed together
  with Gecert Connect. It is how Windows and the applications see the key of each certificate; it forwards every operation to Gecert
  Connect over a named pipe. 
* **Key stores**: where the keys actually live. See [the table below](https://docs.lacunasoftware.com/en-us/articles/gecert#key-stores).

## Concepts

* **Organization**: each organization has its own keys, certificates, users and applications. The instance administrator, in the
  **Sys Admin** area, creates the organizations and defines which key stores each one may use. A user can belong to several
  organizations. 
* **Key**: a reference to an RSA key pair kept in a key store. GeCert stores only the parameters that identify the key in the store (for
  example, the KMIP identifiers in a Kryptus HSM) and a CSR signed with it. A key comes into being in three ways: generated by GeCert in the
  store (**Generate New Key**), imported from a PKCS #12 file when a certificate is added, or registered when it already exists in the store
  (**Register existing key**). 
* **Certificate**: an X.509 certificate bound to a key. To add one, upload a PKCS #12 file (`.pfx`) with its password, and GeCert imports the
  key into the chosen key store (**Add certificate**); or upload only the certificate (`.cer`, no password) for a key that is already in GeCert,
  as long as the public key matches (**Register certificate**). The same certificate cannot be added twice to the same organization.

* **Certificate access**: the authorization for a user to use a certificate. Only users with access see the certificate in Gecert Connect
  and can sign with it. The user must belong to the organization, and cannot have access to the same certificate (same thumbprint) through
  two organizations. The accesses of one certificate can be copied to another, for example when the certificate is renewed.

* **Key store access**: the release of a key store to an organization, done by the Sys Admin. Only released key stores are offered when
  generating, registering or importing keys. The database key store, named `DatabaseDefault`, exists in every instance.

* **Partition**: in the key stores that support partitions, each organization gets a partition of its own, created by GeCert the first time
  the organization uses the store. In a Kryptus HSM, the partition is an HSM user with a PIN generated by GeCert and kept as secret data in
  the HSM itself; in the database, it is an encryption key of its own, protected by a PIN generated by GeCert. Azure Key Vault and PKCS #11
  devices have no partitions: the keys of every organization live in the root of the store.

* **Key usages**: the record of every operation Gecert Connect performs with a key: the date, the user, the operation (signature,
  decryption, encryption or signature verification), the algorithm, the hash and the value produced. 
* **Events and reports**: every creation, registration, update and deletion of keys and certificates, and every grant or removal of access,
  produces an event. An organization can generate a certificate expiration report and a report of the events of one certificate, as XLSX,
  CSV or PDF. 

## How a signature happens

![How a signature happens with GeCert: Windows application, Lacuna KSP, Gecert Connect, GeCert server and key store](https://docs.lacunasoftware.com/images/gecert/signature-flow.svg)

0. First of all, the user signs in to Gecert Connect with their GrantID account. Every 60 seconds, the application fetches the certificates
   the user has access to (`GET /api/certificates/my`) and installs each of them in the user's personal certificate store on Windows, bound
   to a Lacuna KSP key whose name is the key's ID in GeCert. Certificates whose access was removed are uninstalled.

1. A Windows application (Adobe Acrobat, Office, a browser, your own application) picks the certificate from the Windows store and asks
   CNG to sign a hash with its key.
1. The Lacuna KSP receives the request and sends it to Gecert Connect over the `gecert-connect-pipe` named pipe. 
1. Gecert Connect calls `POST /api/keys/{id}/signature` on the server, with the user's access token, giving the algorithm (`RS256` or
   `RS512`) and the hash in Base64. 
1. The server checks that the user has access to the certificate and belongs to the organization, connects to the partition (or the root)
   of the key store and signs the hash in there. 
1. The signature travels back the same way to the application, and the server records the usage in the organization's **Key usages**
   list. 

Decryption follows the same path (`POST /api/keys/{id}/decryption`, with `RSA1_5` padding). Encryption and signature verification also go
through the server, but use only the certificate's public key. See the [API](https://docs.lacunasoftware.com/en-us/articles/gecert/api#api-used-by-gecert-connect).

## Roles and permissions

The roles are those of Lacuna's application platform: two per organization and two in the Sys Admin area. 

| Role | Where | What it allows |
|---|---|---|
| **Admin** | Organization | View and manage keys, certificates and certificate accesses; manage the organization's users and applications |
| **Basic** | Organization | View keys, certificates and certificate accesses |
| **Owner** | Sys Admin | View the keys, certificates and accesses of every organization; manage certificate accesses; grant and remove the organizations' access to key stores; manage users |
| **Contributor** | Sys Admin | View the keys, certificates, certificate accesses and key store accesses of every organization |

Using a key (signing or decrypting through Gecert Connect) does not depend on the role: it requires a granted **certificate access** and
membership in the organization that owns the certificate. An Admin without access to a certificate cannot sign with it.

## Key stores

What each type of key store allows: 

| Key store | `Type` | Generate keys | Import PKCS #12 | Register existing key | Partition per organization | Hard delete |
|---|---|---|---|---|---|---|
| Database (`DatabaseDefault`) | `Database` | Yes | Yes | No | Yes | Always |
| Kryptus kNET HSM | `Kryptus` | Yes | Yes | Yes | Yes | No |
| Azure Key Vault | `AzureKeyVault` | Yes (2048 or 4096 bits) | Yes | Yes | No | If configured |
| PKCS #11 device (HSM or token) | `Pkcs11` | Yes | Yes | Yes | No | If configured |

By default, a key can have 1024, 2048 or 4096 bits. In Azure Key Vault, the key name may only contain letters, digits and hyphens. When hard
deletion (`HardDelete`) is not configured or not supported, deleting a key in GeCert only marks it as deleted: it stays in the key store.

The configuration of each key store is in [Configure key stores](https://docs.lacunasoftware.com/en-us/articles/gecert/on-premises/configure-key-stores).

## The web application

In the **Organization Area**, the menu has: 

* **Home**: a summary of the organization, with shortcuts to **Generate key** and **Add certificate**.
* **Keys**: the list of keys, **Generate New Key** and **Register existing key**. For each key: **Key Details** (type, size and whether it is
  still in the key store), **Edit Key** (the name), **Key CSR** (show the CSR or **Issue new CSR**, choosing the hash algorithm and the
  subject name), **Key Parameters** (the parameters in the key store, when the store allows key registration) and **Key Events**.
* **Certificates**: the list of certificates, **Add certificate** and **Register certificate**. For each certificate: the details, the
  authorized users (**Grant certificate access**, remove one access or all of them, **Copy authorizations to another certificate**), the
  **Certificate usages**, the **Certificate events** and the reports (**Generate certificates report**, with the expiration dates, and
  **Generate certificate report**, with the events of one certificate).
* **Key usages**: every operation performed with the organization's keys.
* **Users**, **Applications** and **Events**: the users and their roles, the applications with an API key and the organization's history.
  For each user, the **Authorized certificates**.

In the **Sys Admin** area, besides the organizations, users, applications and events of the whole instance, the menu has **Key Stores**:
the list of configured key stores (name, type, whether it is the default, whether it accepts key insertion and key registration and whether
it hard-deletes) and the details of each one. In the details of an organization, the Sys Admin grants and removes its access to the key
stores (**Grant key store access**). 

## See also

* [Gecert Connect](https://docs.lacunasoftware.com/en-us/articles/gecert/gecert-connect)
* [GeCert API](https://docs.lacunasoftware.com/en-us/articles/gecert/api)
* [GeCert on-premises](https://docs.lacunasoftware.com/en-us/articles/gecert/on-premises)
* [Changelog](https://docs.lacunasoftware.com/en-us/articles/gecert/changelog)
* [GrantID](https://docs.lacunasoftware.com/en-us/articles/grant-id)