Managing Certificates

Certificates in Secryn represent cryptographic certificates used for TLS, internal services, and infrastructure authentication. Certificates belong to a vault and are governed by project-level access and optional restricted vault rules.

Certificates are immutable and non-versioned. Once created or uploaded, they cannot be edited.

Creating a Certificate

To create a certificate:

• Navigate to a Project
• Open a Vault
• Click New Certificate
• Choose one of the following:
  • Generate a new certificate
  • Upload an existing certificate
• Provide:
  • Name
  • Common Name (CN)
  • Optional subject details (Organization, OU, Country, State, Locality, Email)
  • Activation date
  • Expiration date
  • Optional tags
  • Visibility (Public or Private)
• Save to complete creation.

An audit log entry is recorded.

Generating a Certificate

When generating a certificate:

• Secryn creates a self-signed certificate.
• Subject fields are optional except where required.
• Expiration date is defined at creation.
• The certificate becomes active based on the activation time.
• Generated certificates cannot be modified after creation.

If changes are required, create a new certificate.

Uploading a Certificate

When uploading a certificate:

• The expiration date is automatically extracted from the certificate.
• Subject fields are automatically populated.
• Uploaded metadata overrides any manually entered values.
• The certificate is stored as-is.

This ensures Secryn remains a source of truth and does not alter uploaded material.

Certificate Immutability

Certificates in Secryn:

• Cannot be edited
• Do not support version history
• Cannot be mutated in place

If renewal or replacement is required:

• Create or upload a new certificate
• Update dependent systems
• Disable the old certificate if necessary

This design prevents silent modification of cryptographic material.

Public Visibility

Certificates may be marked as public.

When public visibility is enabled:

• A public download URL is generated
• Vault authentication is not required
• Anyone with the URL can retrieve the certificate

Important:

• Public refers only to access behavior
• Public does not imply trust level or certificate authority status
• Public URLs bypass vault-level access control

Use public visibility only when required.

Activation and Expiration

Certificates support:

• Activation time
• Expiration time

Expiration:

• Does not delete the certificate
• May trigger notifications (if configured)
• Is recorded in logs

Expired certificates remain visible but inactive.

Enabling and Disabling Certificates

Certificates can be enabled or disabled.

• Enabled -> retrievable via API or public URL (if public)
• Disabled -> not accessible

Disabling does not remove the certificate record.

Tags

Certificates can be tagged for organization and filtering.

Tags:

• Do not affect access control
• Help group certificates by environment or service

Access Control

Access to certificates is determined by:

• Project membership
• User role
• Vault rules (including Restricted Vaults)
• Public visibility setting

Admins and Project Managers typically manage certificates. Contributors may create certificates if permitted by vault rules.

Accessing Certificates via API

Certificates can be accessed using:

• Vault access keys
• Authenticated API requests
• MCP clients
• Public URL (if visibility is enabled)

All access is logged.

Security Model

Certificates in Secryn follow these principles:

• Immutable records
• No versioning
• Explicit replacement for renewal
• Full audit logging
• Controlled public exposure

Secryn prioritizes cryptographic integrity and lifecycle clarity.

Best Practices

• Use restricted vaults for production certificates
• Monitor expiration dates
• Rotate certificates by creating new records
• Disable unused or deprecated certificates
• Avoid enabling public visibility unless required