Certificates in Secryn are immutable cryptographic artifacts used to secure services, infrastructure, and communication channels. They can be generated directly within Secryn or uploaded as existing certificate bundles. Once created, certificates cannot be edited, ensuring integrity, traceability, and audit consistency.

Every certificate belongs to a vault. People using the web interface are checked against project membership, vault permissions, and user roles. Certificate private keys are stored in a SECRYN-PRIVATE-V1 envelope encrypted with APP_KEY. Existing installs encrypt older plaintext files with php artisan vault:encrypt-private-material. See the security model.

What Certificates Are Used For

Certificates are commonly used for:

• TLS and internal service encryption
• infrastructure security and identity verification
• application and environment authentication
• managing certificate lifecycles centrally

Secryn stores, distributes, and tracks certificates—it does not mutate them after creation.

Creating Certificates

• Generate a new certificate directly in Secryn (self-signed using the supplied metadata).
• Upload an existing certificate bundle (PEM, CRT, or PFX). Secryn extracts and stores the relevant details automatically.

Certificate Immutability

Certificates cannot be edited. To renew or replace a certificate, create a new one. Existing certificates can be disabled or allowed to expire, but the original data remains unchanged for audit purposes. This enforces explicit rotation workflows.

Certificate Metadata

Each certificate includes metadata such as:

• certificate name
• common name (CN)
• optional subject fields (organization, OU, country, state, locality)
• optional contact email

When uploading a certificate, Secryn populates these fields based on the certificate contents.

Validity and Lifecycle

Certificates support lifecycle controls:

• activation time
• expiration time (derived automatically for uploads)
• enabled/disabled toggle

Times are stored in UTC and displayed relative to the viewer’s timezone.

Visibility and Public Access

Certificates can be marked public. Public access uses a resource-specific bearer token on GET /api/v1/certificates/{certificate_id}. It does not use the vault access key, and it returns the certificate only, never the certificate private key. The endpoint is not an open link. This setting controls access, not trust or certificate authority. Treat the token as a secret. If that public link was enabled before this release, rotate the certificate private key. Older public links could return private key material.

Tags and Organization

Tag certificates to help with service identification, environment grouping, or compliance tracking. Tags improve searchability but do not affect access control.

Permissions and Access Control

Access depends on project membership, vault permissions (including restricted vaults), and user roles. Depending on role, users may:

• create or upload certificates
• download certificate material
• disable certificates
• view metadata only

Upload Behavior Summary

When uploading a certificate:

• expiration is set from the certificate itself
• subject fields are parsed automatically
• manual lifecycle inputs are overridden
• the certificate is stored as-is

Best Practices

• treat certificates as immutable records
• rotate by creating new certificates
• always set expiration dates
• disable certificates instead of deleting access abruptly
• use restricted vaults for sensitive certificates
• avoid public visibility unless required

This lifecycle-driven approach keeps certificate management predictable, auditable, and secure.