Skip to content

feat(pki): add default TTL setting to certificate profiles#5238

Merged
saifsmailbox98 merged 14 commits intomainfrom
saif/pki-98-add-default-certificate-ttl-values-to-profiles
Jan 28, 2026
Merged

feat(pki): add default TTL setting to certificate profiles#5238
saifsmailbox98 merged 14 commits intomainfrom
saif/pki-98-add-default-certificate-ttl-values-to-profiles

Conversation

@saifsmailbox98
Copy link
Contributor

@saifsmailbox98 saifsmailbox98 commented Jan 22, 2026

Context

Certificate profiles now support an optional default TTL setting that serves as a fallback validity period when a TTL is not explicitly specified in the certificate request.

ACME and certificate issuance services can now use the profile's default TTL when no explicit TTL is provided in the request

Screenshots

image image

Steps to verify the change

Create a policy with a max validity, create a profile with a default TTL (<= policy's max validity), use Certbot (ACME) to issue a certificate and it should use the default TTL provided.

Type

  • Fix
  • Feature
  • Improvement
  • Breaking
  • Docs
  • Chore

Checklist

  • Title follows the conventional commit format: type(scope): short description (scope is optional, e.g., fix: prevent crash on sync or fix(api): handle null response).
  • Tested locally
  • Updated docs (if needed)
  • Read the contributing guide

@saifsmailbox98 saifsmailbox98 marked this pull request as ready for review January 22, 2026 18:07
@maidul98
Copy link
Collaborator

maidul98 commented Jan 22, 2026

Snyk checks have passed. No issues have been found so far.

Status Scanner Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Jan 22, 2026

Greptile Overview

Greptile Summary

This PR adds optional default TTL support to certificate profiles, serving as a fallback when certificates are requested without an explicit TTL. The implementation follows a clear priority hierarchy: request TTL > profile default TTL > flow-specific default (47d for ACME, 90d for EST).

Key Changes:

  • Added nullable defaultTtlDays column to certificate profiles via idempotent migration
  • Created resolveEffectiveTtl function with validation to ensure profile defaults don't exceed policy max validity
  • Updated ACME, EST, and API certificate issuance flows to use the new TTL resolution logic
  • Made API TTL parameter optional (previously required) to support profile defaults
  • Added frontend UI with checkbox-enabled TTL input, unit conversion (days/months/years), and client-side validation
  • Documentation updated to explain the default TTL feature

Issues Found:

  • Empty string fallback in certificate-router.ts:222 could cause inconsistent behavior with the TTL resolution logic

Overall Assessment:
The implementation is well-structured with proper validation at both frontend and backend layers. The TTL resolution priority is clearly documented and consistently applied across enrollment flows. The one logic issue found should be addressed to ensure robustness.

Confidence Score: 4/5

  • This PR is mostly safe to merge with one logic issue that should be fixed
  • Score reflects solid implementation with clear validation and documentation, but the empty string fallback in the certificate router could cause unexpected behavior in edge cases where no TTL is provided
  • Pay close attention to backend/src/server/routes/v1/certificate-router.ts - the empty string fallback on line 222 needs correction

Important Files Changed

Filename Overview
backend/src/services/certificate-v3/certificate-v3-fns.ts New resolveEffectiveTtl function with clear priority order and validation
backend/src/services/certificate-v3/certificate-v3-service.ts Integrates TTL resolution logic across issuance flows, with potential empty string issue
backend/src/services/certificate-profile/certificate-profile-service.ts Validation ensures default TTL doesn't exceed policy max validity on create/update
backend/src/server/routes/v1/certificate-router.ts TTL made optional in API, but empty string fallback could cause issues
frontend/src/pages/cert-manager/PoliciesPage/components/CertificateProfilesTab/CreateProfileModal.tsx UI with checkbox-enabled TTL input, conversion helpers, and client-side validation

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

10 files reviewed, 5 comments

Edit Code Review Agent Settings | Greptile

…lt-certificate-ttl-values-to-profiles

# Conflicts:
#	backend/src/services/certificate-v3/certificate-v3-service.ts
@saifsmailbox98 saifsmailbox98 force-pushed the saif/pki-98-add-default-certificate-ttl-values-to-profiles branch from 33aa9b0 to 4d4b92a Compare January 23, 2026 20:18
@saifsmailbox98
Copy link
Contributor Author

@greptile review this

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 file reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Jan 26, 2026

Additional Comments (1)

backend/src/server/routes/v1/certificate-router.ts
Empty string fallback doesn't match resolveEffectiveTtl behavior. When attributes?.ttl is undefined, this passes an empty string ("") to the certificate order flow. However, resolveEffectiveTtl in certificate-v3-fns.ts:93 checks if (flowDefaultTtl) which treats empty string as truthy, bypassing the error throw and potentially causing unexpected behavior.

Either pass undefined instead of "", or ensure the downstream logic handles empty strings consistently.

          validity: { ttl: attributes?.ttl },

@saifsmailbox98
Copy link
Contributor Author

saifsmailbox98 commented Jan 26, 2026

Additional Comments (1)
backend/src/server/routes/v1/certificate-router.ts Empty string fallback doesn't match resolveEffectiveTtl behavior. When attributes?.ttl is undefined, this passes an empty string ("") to the certificate order flow. However, resolveEffectiveTtl in certificate-v3-fns.ts:93 checks if (flowDefaultTtl) which treats empty string as truthy, bypassing the error throw and potentially causing unexpected behavior.

Either pass undefined instead of "", or ensure the downstream logic handles empty strings consistently.

          validity: { ttl: attributes?.ttl },

Aren't both falsy?

…ltTtlDays is used when no explicit TTL is provided
@saifsmailbox98 saifsmailbox98 merged commit c43f7c7 into main Jan 28, 2026
14 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants