Assistance Disclosure

I authored the code and performed the tests. I consulted Gemini (Google's AI) for implementation strategy guidance, architectural mapping within Caddy, and initial draft snippets. All code was manually reviewed, integrated, and validated locally.

Dependencies

⚠️ This PR depends on caddyserver/certmagic#371 and should not be merged before that PR is accepted.

Description

This PR adds support for the key_file directive in the TLS app and Caddyfile.

It allows users to provide a pre-existing private key for automated certificate management (ACME or Internal), enabling key continuity across deployments, infrastructure migrations, and environments where keys are pre-provisioned.

The default behavior remains unchanged. If key_file is not specified, Caddy continues generating keys automatically via CertMagic.

Relates to

Fixes #2854

Changes

• Caddyfile:

  • Added key_file subdirective to tls
  • Added key_file as a global option

• Automation:

  • Extended AutomationPolicy with a KeyFile field

• Provisioning:

  • Added logic in automation.go to instantiate certmagic.FileKeyGenerator when a custom key file is configured

• Policy Consolidation:

  • Updated consolidation logic in tlsapp.go to prevent merging policies that reference different custom keys

• Parsing:

  • Updated builtins.go and options.go to parse and validate the key_file token

Testing

Tested locally by:

1. Generating an EC P-384 private key:

   openssl ecparam -genkey -name secp384r1 -noout -out my_key.pem

2. Configuring a site block with:

   tls {
       key_file my_key.pem
       issuer internal
   }

3. Verifying via curl -v that the server presented a certificate using the specified P-384 key (confirmed public key type and size during the TLS handshake).

4. Verifying that global options correctly propagate the key_file setting across automation policies.