Certificate Secrets
Define project-scoped rules for issuing short-lived certificates without sending requester private keys to SikkerKey.
Certificate secrets issue short-lived credentials on demand instead of storing a reusable value. When an authorized machine requests one, it generates a key pair locally, sends only the public key to SikkerKey, and receives a newly signed certificate. The private key never leaves the machine.
A certificate secret is not a certificate authority. The certificate secret belongs to one project and controls who may request a certificate, what identity it carries, and how long it may last. The certificate authority belongs to the vault and supplies the signing key and trust anchor.
#How certificate secrets work
You define the identity and restrictions the certificate secret may issue.
You grant the certificate secret to the machines allowed to use that identity.
A granted machine authenticates to SikkerKey and generates a fresh key pair locally.
SikkerKey checks the machine’s project membership, explicit grant, project state, and any attached access policy.
SikkerKey signs the public key with the selected certificate authority and returns a short-lived certificate.
The machine presents its private key and certificate to a system that trusts the authority.
Every successful request produces a new certificate. A certificate secret does not hold the requesting machine’s private key, a reusable certificate, or a plaintext value.
Part | Purpose |
|---|---|
Secret ID | Stable project-scoped identifier used for grants, policies, audit events, and certificate identity |
Certificate type | Certificate format and configuration rules selected through the authority |
Certificate authority | Vault-scoped signer selected for this secret |
Type-specific settings | Identity, connection context, and restrictions interpreted by the selected certificate type |
Maximum validity | Longest lifetime SikkerKey will issue for a request |
Machine grants | Explicit list of machines allowed to request certificates |
Access policy | Optional conditions SikkerKey evaluates before issuing |
Certificate secrets have no stored value to replace, version history to restore, or scheduled value rotation. Their lifecycle is based on issuing a fresh, short-lived certificate for each authorized request.
#Supported certificate types
Certificate secrets are not tied to one certificate format. The selected certificate authority determines which certificate engine validates the settings and signs the request. SikkerKey currently supports OpenSSH user certificates; additional certificate types can use the same project-scoped secret, grant, policy, validity, and audit model as they become available.
OpenSSH user certificates
Setting | How SSH uses it |
|---|---|
Username | Stored as the certificate’s only principal. It must begin with a lowercase letter or underscore, may then contain lowercase letters, numbers, underscores, or hyphens, and can contain up to 32 characters. |
Host | Returned as connection context for the client. It does not bind the certificate to a hostname and the SSH server does not enforce it. |
Source addresses | Embedded as an OpenSSH source-address restriction. The SSH server accepts the certificate only when the connection comes from one of these literal IPv4 or IPv6 addresses or CIDR ranges. |
Maximum validity | Limits the requested lifetime to between 1 minute and 24 hours. |
A certificate source-address restriction and an access-policy IP allowlist protect different points. The SSH server checks the connection address against the certificate. SikkerKey checks the address used to request the certificate against the access policy. Use the addresses each system actually observes, especially when traffic passes through NAT, a proxy, or a gateway.
#Before you create a certificate secret
The vault must already contain a certificate authority of the required type, and the systems that should accept issued certificates must trust that authority. Authority creation and trust-anchor installation are managed separately from the certificate secret on the dashboard’s Certificates page.
If the creation form says the vault has no certificate authorities, ask a vault member with certificate-authority permissions to create one and prepare the target systems before continuing.
#Create a certificate secret
Select the project that should own the certificate secret, then open Secrets.
Select the plus button and choose Certificate secret.
Enter a name that identifies the workload and access purpose.
Choose the certificate authority that should sign certificates for this secret. The authority determines the certificate type.
Complete the settings shown for that certificate type. For the current OpenSSH type, enter the username and optionally add host context and source IP addresses or CIDR ranges.
Set the maximum validity from 1 minute to 24 hours.
Select Create secret.
The certificate secret is enabled immediately and appears in the project’s secrets table with a stable secret ID. Its certificate type and available settings follow the selected authority.
Create a separate certificate secret for each identity or access boundary. For example, use different secrets for deployment and operations access so each has its own machine grants, policy, type-specific restrictions, validity ceiling, and audit trail.
#Grant machines and apply access policies
A machine cannot request a certificate merely because it belongs to the project. It also needs an explicit grant for the certificate secret.
Open Machines beneath the project.
Add the approved machine to the project if it is not already a member.
Open the machine’s row menu and select Configure.
Select the certificate secret from the available secrets.
Save the grants.
To add conditions such as a time window, request-source IP allowlist, read-rate cap, or co-sign requirement, bind an access policy from the project’s Secrets page. Every enabled policy condition must pass before SikkerKey signs the public key.
See Standard Machines for project membership and grant management.
#Understand issuance and validity
The requesting machine chooses a requested lifetime. When no shorter lifetime is requested, SikkerKey uses the certificate secret’s configured maximum. A request for longer than the maximum is reduced to that maximum instead of being rejected.
SikkerKey backdates the certificate’s start time by 60 seconds to tolerate small clock differences between SikkerKey and the target server. The expiry still follows the effective requested lifetime.
Request | Result |
|---|---|
No lifetime requested | The certificate uses the configured maximum validity. |
Lifetime shorter than the maximum | The shorter requested lifetime is used. |
Lifetime longer than the maximum | The certificate is issued at the configured maximum. |
Certificate secret disabled | No new certificate is issued. |
Machine lacks project membership or a grant | The request is denied before signing. |
Access policy blocks the request | No certificate is issued, and the reason is recorded in the Audit Log. |
Project is frozen | The request is locked before signing. |
Certificates receive a serial number that increases for each certificate secret. OpenSSH also receives a key ID containing the certificate secret ID and requesting machine name, which helps correlate a server login with SikkerKey activity.
#Change or pause a certificate secret
Open the certificate secret’s row menu and select Configure. Use Status to disable or enable new issuance. Use Settings to change the authority, username, host, source addresses, or maximum validity.
Disable issuing to stop every new request without deleting the certificate secret.
Change the type-specific identity or restrictions to alter certificates issued after the save. For OpenSSH, these settings include the username and source addresses.
Shorten maximum validity to reduce the lifetime of future certificates.
Change the authority to sign future certificates from another compatible authority.
Configuration changes affect only certificates issued after the change. A certificate already handed out keeps its original identity, type-specific restrictions, signer, and expiry. If you change the authority, target systems must trust the new authority before they can accept newly issued certificates.
Renaming the secret or changing its note does not change the secret ID or certificate rules.
#Stop certificate access
Choose the control that matches the scope and urgency of the change.
Action | What it stops |
|---|---|
Remove one machine’s grant | Future issuance for that machine from this certificate secret |
Disable the certificate secret | All future issuance from this certificate secret |
Tighten or attach an access policy | Future requests that do not satisfy the policy |
Shorten maximum validity | The lifetime of certificates issued after the change |
Delete the certificate secret | All future issuance and the secret’s issuance configuration |
SikkerKey cannot recall an individual certificate after it has been signed. Removing a grant, disabling the secret, changing settings, or deleting the secret does not invalidate certificates already issued; they continue to work until they expire. Removing the authority’s trust anchor from target systems stops certificates from that authority immediately, but affects every certificate signed by it.
#Delete a certificate secret
Open the certificate secret’s row menu and select Delete.
Review the affected secret.
Confirm the deletion.
Deletion stops new issuance immediately and removes the certificate secret’s issuance configuration. Certificates already issued continue to work until their own expiry.
The deleted record may remain visible in Trash according to the vault’s retention rules, but its issuance configuration is removed and cannot be restored as a working certificate secret. Create a new certificate secret if access is needed again. Deleting the signing certificate authority also deletes every certificate secret that depends on it.
#Permissions
Permission | Access provided |
|---|---|
Project in scope | View certificate-secret metadata in the project’s secrets table |
Manage certificate secrets | Create, inspect, configure, enable, disable, rename, and delete certificate secrets in the scoped project |
View certificate authorities | See and select the vault’s certificate authorities when creating or editing a certificate secret |
Configure machine grants | Choose which project machines may request certificates |
View or manage policies | Review, attach, remove, and configure access policies according to the role’s policy capabilities |
View Audit Log | Review successful and failed certificate issuance and configuration activity |
Project permissions come from access roles. Certificate-authority and audit permissions come from vault roles.
#Troubleshoot certificate secrets
Symptom | What to check |
|---|---|
Certificate secret is unavailable in the create menu | Confirm the project is in your access-role scope and Manage certificate secrets is enabled. |
The form says there are no certificate authorities | Confirm the vault contains an authority for a supported certificate type and your vault role can view certificate authorities. |
Machine receives Access denied | Confirm it is approved, belongs to the project, and has an explicit grant for this certificate secret. |
Request is blocked or locked | Review the attached access policy, project freeze state, request source address, time window, rate limit, and co-sign requirement. |
Issuing is disabled | Open Configure, review Status, and enable issuing if the pause is no longer required. |
A settings change did not affect an existing certificate | Settings apply only to newly issued certificates. Existing certificates keep their original contents and expiry. |
OpenSSH troubleshooting
Symptom | What to check |
|---|---|
Username is rejected | Use 1–32 characters. Begin with a lowercase letter or underscore, then use only lowercase letters, numbers, underscores, or hyphens. |
Source address is rejected | Enter literal IPv4 or IPv6 addresses or valid CIDR ranges. Separate multiple entries with commas or new lines. |
Certificate is issued but SSH rejects it | Confirm the server trusts the selected authority, the username exists, the connection satisfies the certificate’s source-address restriction, and the server clock is correct. |