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). 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 used by the web application and by Gecert Connect. Users sign in with a GrantID account (OpenID Connect).
• 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.

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

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.
2. The Lacuna KSP receives the request and sends it to Gecert Connect over the gecert-connect-pipe named pipe.
3. 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.
4. 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.
5. 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.

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.

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
• GeCert API
• GeCert on-premises
• Changelog
• GrantID