首页
/ 在Caddy Docker Proxy中实现通配符证书自动管理的最佳实践

在Caddy Docker Proxy中实现通配符证书自动管理的最佳实践

2025-06-23 21:58:29作者:卓艾滢Kingsley

背景介绍

随着Caddy 2.9.1版本的发布,新增了auto_https prefer_wildcard功能,这项功能允许优先使用已有的通配符证书而不是为每个子域名单独申请证书。本文将详细介绍如何在Caddy Docker Proxy(CDP)环境中实现这一功能。

核心概念解析

通配符证书的优势

通配符证书(如*.example.com)可以覆盖一个域名下的所有子域名,相比为每个子域名单独申请证书有以下优势:

  1. 减少证书申请次数
  2. 简化证书管理
  3. 降低Let's Encrypt等CA的请求限制风险

Caddy 2.9.1新特性

prefer_wildcard选项让Caddy优先检查是否存在匹配的通配符证书,如果存在则直接使用,否则才会为特定子域名申请独立证书。

实现步骤详解

1. 构建自定义CDP镜像

由于官方CDP尚未发布支持Caddy 2.9的版本,需要自定义构建:

ARG CADDY_VERSION=2.9.1
FROM caddy:${CADDY_VERSION}-builder AS builder
RUN xcaddy build ${CADDY_VERSION} \
  --with github.com/lucaslorentz/caddy-docker-proxy/v2

FROM caddy:${CADDY_VERSION}-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
CMD ["caddy", "docker-proxy"]

2. Docker Compose配置要点

services:
  reverse-proxy:
    image: localhost/caddy-docker-proxy:2.9.1
    labels:
      # 全局设置,优先使用通配符证书
      caddy.auto_https: prefer_wildcard
      # 通配符证书配置
      caddy_1: "*.example.internal"
      caddy_1.respond: "fallback"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp" # HTTP/3支持

3. 关键配置说明

  1. 通配符域名定义:必须使用引号包裹,如"*.example.com",否则Docker Compose会解析错误
  2. fallback响应:为未明确配置的子域名提供默认响应
  3. 网络配置:确保容器间网络互通,特别是DNS解析

测试验证方法

  1. 启动服务后,使用curl测试子域名访问:
curl --insecure https://whoami.example.internal
  1. 验证证书信息:
step certificate inspect --insecure https://whoami.example.internal | jq -c .extensions.subject_alt_name.dns_names
  1. 测试通配符匹配:
curl https://random-subdomain.example.internal

常见问题解决方案

  1. 配置语法错误:确保通配符域名使用双引号包裹
  2. 证书不更新:使用docker compose up --force-recreate强制重建容器
  3. DNS解析问题:检查容器网络配置和DNS设置

最佳实践建议

  1. 生产环境应考虑使用正式的CA而不是自签名证书
  2. 合理规划域名结构,确保通配符证书覆盖范围符合需求
  3. 定期监控证书到期时间,虽然Caddy会自动续期,但仍需确保服务正常运行
  4. 考虑证书缓存策略,提高服务可用性

通过以上配置,可以充分利用Caddy 2.9.1的通配符证书优先特性,简化证书管理流程,提高服务可靠性。这种方案特别适合需要管理大量子域名的场景,能显著降低运维复杂度。

登录后查看全文
热门项目推荐

项目优选

收起
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
144
1.93 K
kernelkernel
deepin linux kernel
C
22
6
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
192
274
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
145
189
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
930
553
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
8
0
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
423
392
金融AI编程实战金融AI编程实战
为非计算机科班出身 (例如财经类高校金融学院) 同学量身定制,新手友好,让学生以亲身实践开源开发的方式,学会使用计算机自动化自己的科研/创新工作。案例以量化投资为主线,涉及 Bash、Python、SQL、BI、AI 等全技术栈,培养面向未来的数智化人才 (如数据工程师、数据分析师、数据科学家、数据决策者、量化投资人)。
Jupyter Notebook
75
66
CangjieCommunityCangjieCommunity
为仓颉编程语言开发者打造活跃、开放、高质量的社区环境
Markdown
1.11 K
0
openHiTLS-examplesopenHiTLS-examples
本仓将为广大高校开发者提供开源实践和创新开发平台,收集和展示openHiTLS示例代码及创新应用,欢迎大家投稿,让全世界看到您的精巧密码实现设计,也让更多人通过您的优秀成果,理解、喜爱上密码技术。
C
64
511