尧图网页设计 
网络安全运维【免费下载链接】dehydratedACME client implemented as a simple shell-script – just add water项目地址https://gitcode.com/gh_mirrors/de/dehydrated点击查看免费下载本文是 dehydrated一个以纯 Bash 脚本实现的 ACME 客户端中http-01 挑战验证的实战配置指南核心围绕WELLKNOWN配置变量展开它决定了验证文件被写入哪个目录、如何被 Web 服务器对外提供。读完本文你将掌握 http-01 验证的底层工作原理、单 docroot 与多 docroot/反向代理两种场景下的WELLKNOWN配置方法以及 Nginx、Apache、Lighttpd、Hiawatha 四种主流 Web 服务器的完整配置范例并能独立完成验证连通性测试与常见排错。一、http-01 验证机制CA 如何确认你拥有域名http-01是 dehydrated 默认使用的域名所有权验证方式脚本也支持 DNS 方式验证。其核心流程为Lets Encrypt或任何遵循 ACME 协议的 CA会通过访问一个形如http://example.org/.well-known/acme-challenge/m4g1C-t0k3n的 URL 来确认你是否控制某个域名。这个验证 URL 由三部分组成/.well-known/acme-challenge/ACME 协议规定的固定路径前缀m4g1C-t0k3nCA 为本次验证随机生成的 token挑战令牌前缀部分你要申请证书的任意子域名。关键前提CA 会对domains.txt中列出的每一个子域名分别发起一次这种访问。因此所有要签入证书的域名都必须能通过 HTTP 在 80 端口访问到/.well-known/acme-challenge/下的验证文件。需要注意的传输细节起点永远是 HTTP80 端口。虽然配置了重定向到 HTTPS 也能工作但 CA 首次发起的连接一定是明文 HTTP因此 80 端口必须开放且可达若你的服务器同时监听 IPv4 和 IPv6请确保两个协议栈下的 HTTP 80 访问都正常详见下文排错章节。dehydrated 本身不内置挑战响应服务器这一点在 man 手册 中有明确说明它依赖你现有的 Web 服务器来对外提供挑战响应文件这正是WELLKNOWN变量存在的意义。二、WELLKNOWN 配置变量验证文件的落盘目录WELLKNOWN是 dehydrated 的一个配置变量它对应你的域名下/.well-known/acme-challenge应该被服务的那个目录。以上面的 token 为例验证文件会被保存为$WELLKNOWN/m4g1C-t0k3n也就是说只要你的 Web 服务器把$WELLKNOWN目录映射到 URL 路径/.well-known/acme-challengeCA 的验证请求就能命中 dehydrated 写下的 token 文件。默认值与配置位置默认值/var/www/dehydrated。这是脚本内置的默认 WELLKNOWN 位置见 dehydrated 中[[ -z ${WELLKNOWN} ]] WELLKNOWN/var/www/dehydrated也是 示例配置文件 中WELLKNOWN/var/www/dehydrated的注释默认值配置方式在 dehydrated 的配置文件中设置例如WELLKNOWN/var/www/.well-known/acme-challenge。dehydrated 会按以下顺序查找配置文件使用最先找到的一个参见 README.md 与 示例配置 中的说明/etc/dehydrated/config/usr/local/etc/dehydrated/config当前 shell 的工作目录运行 dehydrated 的脚本所在目录你可以复制 docs/examples/config 到/etc/dehydrated/config后按需编辑WELLKNOWN在其中对应如下注释块# Output directory for challenge-tokens to be served by webserver or deployed in HOOK (default: /var/www/dehydrated) #WELLKNOWN/var/www/dehydrated启动期强制校验dehydrated 在加载配置后会执行配置校验verify_config函数见 dehydrated。当使用 http-01 挑战执行签发/续期命令时若WELLKNOWN指向的目录不存在脚本会直接报错退出WELLKNOWN directory doesnt exist, please create ${WELLKNOWN} and set appropriate permissions.因此在首次运行前务必先手动创建WELLKNOWN目录例如mkdir -p /var/www/dehydrated按证书级覆盖进阶WELLKNOWN不仅能在主配置文件中全局设置还能按证书单独覆盖在证书输出目录如certs/example.org/config下创建config文件即可针对特定证书设置WELLKNOWN以及其他如CHALLENGETYPE、HOOK、RENEW_DAYS等选项。详见 docs/per-certificate-config.md。这意味着不同域名可以把验证文件放在各自不同的目录里再由各自的服务器/虚拟主机提供。三、单 docroot 场景最简单的配置如果服务器上只有一个 docroot网站根目录事情最简单直接把WELLKNOWN指向该 docroot 下的真实路径即可无需任何 Web 服务器额外配置WELLKNOWN/var/www/.well-known/acme-challenge前提是该目录能通过 URLhttp://你的域名/.well-known/acme-challenge/被直接访问——因为 docroot 天然就是 URL 根路径/的映射目录路径与 URL 路径一一对应。但如果你有多个 docroot或者服务器扮演反向代理 / 负载均衡角色不同域名、不同后端各自拥有独立的根目录上面的简单配置就不适用了——你不可能在每个 docroot 下都放一份验证文件。这时需要为 Web 服务器增加少量配置把固定的/.well-known/acme-challengeURL 前缀统一映射到一个共享目录。四、多 docroot / 反向代理场景四个主流 Web 服务器配置推荐的做法创建一个共享目录/var/www/dehydrated并在脚本配置中设置WELLKNOWN/var/www/dehydrated然后在 Web 服务器上为每个server/VHost 配置块添加别名alias。以下四种配置来自 docs/wellknown.md均可直接复制使用。4.1 Nginx 示例配置在任意serverVHost配置块中添加server { [...] location ^~ /.well-known/acme-challenge { alias /var/www/dehydrated; } [...] }要点说明location ^~表示该前缀匹配优先级高于正则 location避免与其他 location 规则冲突alias把 URL 前缀/.well-known/acme-challenge直接映射到本地目录/var/www/dehydrated每个需要签证书的server块都要加这一段。4.2 Apache 示例配置在 Apache 配置中添加以下内容对任意 VHost 生效Alias /.well-known/acme-challenge /var/www/dehydrated Directory /var/www/dehydrated Options None AllowOverride None # Apache 2.x IfModule !mod_authz_core.c Order allow,deny Allow from all /IfModule # Apache 2.4 IfModule mod_authz_core.c Require all granted /IfModule /Directory要点说明Alias指令完成 URL 到目录的映射Directory块通过IfModule条件同时兼容 Apache 2.2Order allow,deny/Allow from all与 Apache 2.4Require all granted两种授权语法目录权限收得较紧Options None、AllowOverride None仅需放开读取权限即可。4.3 Lighttpd 示例配置在 Lighttpd 配置中添加server.modules (alias) alias.url ( /.well-known/acme-challenge/ /var/www/dehydrated/, )要点说明需要启用alias模块server.modules (alias)alias.url以键值对形式把 URL 路径前缀映射到本地目录注意两侧的末尾斜杠。4.4 Hiawatha 示例配置Hiawatha 需要在每个 VirtualHost的配置中添加一个 AliasVirtualHost { Hostname example.tld subdomain.mywebsite.tld Alias /.well-known/acme-challenge:/var/www/dehydrated }要点说明语法为Alias URL路径:本地目录冒号分隔同一个 VirtualHost 内可列出多个域名所有列出的域名都能通过该映射访问验证文件。五、源码视角token 的写入、权限与清理全流程为了让读者理解上述 Web 配置为何能生效这里从 dehydrated 脚本源码剖析 http-01 挑战的完整生命周期对应挑战处理逻辑dehydrated生成 keyauth脚本从 CA 返回的 challenge 中取出token并拼接账户指纹构成keyauthtoken.thumbprint这是写入文件的实际内容dehydrated写入验证文件对于http-01脚本将keyauth写入${WELLKNOWN}/${challenge_tokens[${idx}]}并执行chmod ar确保文件全局可读这样 Web 服务器可能以不同用户身份运行才能读取它dehydrated部署与等待验证脚本在配置了HOOK时调用deploy_challenge钩子随后轮询 CA 的验证状态直到valid、invalid或超时dehydrated清理 token验证结束后脚本执行rm -f ${WELLKNOWN}/${challenge_tokens[${idx}]}删除验证文件并在失败路径中同样清理dehydrated、dehydrated。这一闭环说明了两点实战含义验证文件是临时性的每次验证后即被删除无需担心目录内文件堆积目录及其父级路径的写权限归 dehydrated 运行用户读权限归 Web 服务器进程用户——两者往往不同所以chmod ar是保证 Web 服务器可读的关键一步。六、验证连通性与常见排错配置完成后务必在申请证书前自测验证链路。参考 docs/troubleshooting.md 的官方建议在WELLKNOWN目录下创建一个测试文件例如test.txt用浏览器访问http://example.org/.well-known/acme-challenge/test.txt若无法访问说明 Web 服务器配置有问题需要修复。特别注意 IPv6如果你的域名解析出 IPv6 地址CA 的挑战连接会走 IPv6。浏览器访问常因自动回退到 IPv4 而掩盖问题因此必须分别测试 IPv4 与 IPv6 下的 HTTP 连通性例如curl -4 http://example.org/.well-known/acme-challenge/test.txt curl -6 http://example.org/.well-known/acme-challenge/test.txt若任何一条路径出错优先排查WELLKNOWN目录是否存在且权限正确、Web 服务器 alias 是否生效、80 端口防火墙是否放行。如果确认WELLKNOWN路径在你的域名下可读、但挑战仍然失败还可以通过--challenge (-t)参数切换验证方式http-01、dns-01、dns-persist-01、tls-alpn-01详见 README.md 的参数说明或参考 docs/staging.md 使用预演staging环境进行实验避免触及 CA 的签发速率限制。七、与其他挑战方式的取舍http-01是 dehydrated 的默认挑战类型源码默认值CHALLENGETYPEhttp-01见 dehydrated。当你面临多 docroot、纯内网主机、通配符证书等场景时可以对比以下替代方案dns-01 / dns-persist-01通过 DNS TXT 记录完成验证适合无法对外暴露 80 端口的主机无需 Web 服务器配置但需要 DNS 服务商支持的钩子脚本详见 docs/dns-verification.mdtls-alpn-01通过 TLS ALPN 协议完成验证需要额外输出 ALPN 验证证书目录--alpn参数相关说明见 docs/tls-alpn.md。选择http-01时本文的WELLKNOWN Web 服务器 alias 方案即是标准且官方推荐的部署形态选择其他方式时WELLKNOWN目录无需对外暴露但CHALLENGETYPE需相应调整可全局配置也可按证书覆盖见 docs/per-certificate-config.md。赞分享网络安全运维【免费下载链接】dehydratedACME client implemented as a simple shell-script – just add water项目地址https://gitcode.com/gh_mirrors/de/dehydrated点击查看免费下载相关推荐纯Shell实现ACME验证HTTP-01挑战全解析纯Shell实现ACME验证HTTP 01挑战全解析 你还在为配置HTTPS证书手动验证域名而烦恼吗本文将深入解析acme.sh如何仅用Shell脚本实现ACLI网络安全acme-companion DNS验证方案替代HTTP-01挑战的高级选项acme companion DNS验证方案替代HTTP 01挑战的高级选项 你是否遇到过HTTP 01验证失败的困扰在复杂网络环境下如多服务器负载均衡、云原生运维Certbot 域名验证挑战Challenge完全指南HTTP-01 与 DNS-01 原理、认证器插件选择与实战排障Certbot 域名验证挑战Challenge完全指南HTTP 01 与 DNS 01 原理、认证器插件选择与实战排障 Certbot 是 EFF 出品的网络安全CLI后端上一篇终极指南如何为openFPGALoader选择最适合你的FPGA开发板下一篇HMCL启动器GitHub星标破万的Minecraft神器是如何炼成的创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 dehydrated 的 HTTP-01 挑战与 WELLKNOWN 目录配置完全指南：让 ACME 验证文件在你的 Web 服务器上可达
网络安全运维【免费下载链接】dehydratedACME client implemented as a simple shell-script – just add water项目地址https://gitcode.com/gh_mirrors/de/dehydrated点击查看免费下载本文是 dehydrated一个以纯 Bash 脚本实现的 ACME 客户端中http-01 挑战验证的实战配置指南核心围绕WELLKNOWN配置变量展开它决定了验证文件被写入哪个目录、如何被 Web 服务器对外提供。读完本文你将掌握 http-01 验证的底层工作原理、单 docroot 与多 docroot/反向代理两种场景下的WELLKNOWN配置方法以及 Nginx、Apache、Lighttpd、Hiawatha 四种主流 Web 服务器的完整配置范例并能独立完成验证连通性测试与常见排错。一、http-01 验证机制CA 如何确认你拥有域名http-01是 dehydrated 默认使用的域名所有权验证方式脚本也支持 DNS 方式验证。其核心流程为Lets Encrypt或任何遵循 ACME 协议的 CA会通过访问一个形如http://example.org/.well-known/acme-challenge/m4g1C-t0k3n的 URL 来确认你是否控制某个域名。这个验证 URL 由三部分组成/.well-known/acme-challenge/ACME 协议规定的固定路径前缀m4g1C-t0k3nCA 为本次验证随机生成的 token挑战令牌前缀部分你要申请证书的任意子域名。关键前提CA 会对domains.txt中列出的每一个子域名分别发起一次这种访问。因此所有要签入证书的域名都必须能通过 HTTP 在 80 端口访问到/.well-known/acme-challenge/下的验证文件。需要注意的传输细节起点永远是 HTTP80 端口。虽然配置了重定向到 HTTPS 也能工作但 CA 首次发起的连接一定是明文 HTTP因此 80 端口必须开放且可达若你的服务器同时监听 IPv4 和 IPv6请确保两个协议栈下的 HTTP 80 访问都正常详见下文排错章节。dehydrated 本身不内置挑战响应服务器这一点在 man 手册 中有明确说明它依赖你现有的 Web 服务器来对外提供挑战响应文件这正是WELLKNOWN变量存在的意义。二、WELLKNOWN 配置变量验证文件的落盘目录WELLKNOWN是 dehydrated 的一个配置变量它对应你的域名下/.well-known/acme-challenge应该被服务的那个目录。以上面的 token 为例验证文件会被保存为$WELLKNOWN/m4g1C-t0k3n也就是说只要你的 Web 服务器把$WELLKNOWN目录映射到 URL 路径/.well-known/acme-challengeCA 的验证请求就能命中 dehydrated 写下的 token 文件。默认值与配置位置默认值/var/www/dehydrated。这是脚本内置的默认 WELLKNOWN 位置见 dehydrated 中[[ -z ${WELLKNOWN} ]] WELLKNOWN/var/www/dehydrated也是 示例配置文件 中WELLKNOWN/var/www/dehydrated的注释默认值配置方式在 dehydrated 的配置文件中设置例如WELLKNOWN/var/www/.well-known/acme-challenge。dehydrated 会按以下顺序查找配置文件使用最先找到的一个参见 README.md 与 示例配置 中的说明/etc/dehydrated/config/usr/local/etc/dehydrated/config当前 shell 的工作目录运行 dehydrated 的脚本所在目录你可以复制 docs/examples/config 到/etc/dehydrated/config后按需编辑WELLKNOWN在其中对应如下注释块# Output directory for challenge-tokens to be served by webserver or deployed in HOOK (default: /var/www/dehydrated) #WELLKNOWN/var/www/dehydrated启动期强制校验dehydrated 在加载配置后会执行配置校验verify_config函数见 dehydrated。当使用 http-01 挑战执行签发/续期命令时若WELLKNOWN指向的目录不存在脚本会直接报错退出WELLKNOWN directory doesnt exist, please create ${WELLKNOWN} and set appropriate permissions.因此在首次运行前务必先手动创建WELLKNOWN目录例如mkdir -p /var/www/dehydrated按证书级覆盖进阶WELLKNOWN不仅能在主配置文件中全局设置还能按证书单独覆盖在证书输出目录如certs/example.org/config下创建config文件即可针对特定证书设置WELLKNOWN以及其他如CHALLENGETYPE、HOOK、RENEW_DAYS等选项。详见 docs/per-certificate-config.md。这意味着不同域名可以把验证文件放在各自不同的目录里再由各自的服务器/虚拟主机提供。三、单 docroot 场景最简单的配置如果服务器上只有一个 docroot网站根目录事情最简单直接把WELLKNOWN指向该 docroot 下的真实路径即可无需任何 Web 服务器额外配置WELLKNOWN/var/www/.well-known/acme-challenge前提是该目录能通过 URLhttp://你的域名/.well-known/acme-challenge/被直接访问——因为 docroot 天然就是 URL 根路径/的映射目录路径与 URL 路径一一对应。但如果你有多个 docroot或者服务器扮演反向代理 / 负载均衡角色不同域名、不同后端各自拥有独立的根目录上面的简单配置就不适用了——你不可能在每个 docroot 下都放一份验证文件。这时需要为 Web 服务器增加少量配置把固定的/.well-known/acme-challengeURL 前缀统一映射到一个共享目录。四、多 docroot / 反向代理场景四个主流 Web 服务器配置推荐的做法创建一个共享目录/var/www/dehydrated并在脚本配置中设置WELLKNOWN/var/www/dehydrated然后在 Web 服务器上为每个server/VHost 配置块添加别名alias。以下四种配置来自 docs/wellknown.md均可直接复制使用。4.1 Nginx 示例配置在任意serverVHost配置块中添加server { [...] location ^~ /.well-known/acme-challenge { alias /var/www/dehydrated; } [...] }要点说明location ^~表示该前缀匹配优先级高于正则 location避免与其他 location 规则冲突alias把 URL 前缀/.well-known/acme-challenge直接映射到本地目录/var/www/dehydrated每个需要签证书的server块都要加这一段。4.2 Apache 示例配置在 Apache 配置中添加以下内容对任意 VHost 生效Alias /.well-known/acme-challenge /var/www/dehydrated Directory /var/www/dehydrated Options None AllowOverride None # Apache 2.x IfModule !mod_authz_core.c Order allow,deny Allow from all /IfModule # Apache 2.4 IfModule mod_authz_core.c Require all granted /IfModule /Directory要点说明Alias指令完成 URL 到目录的映射Directory块通过IfModule条件同时兼容 Apache 2.2Order allow,deny/Allow from all与 Apache 2.4Require all granted两种授权语法目录权限收得较紧Options None、AllowOverride None仅需放开读取权限即可。4.3 Lighttpd 示例配置在 Lighttpd 配置中添加server.modules (alias) alias.url ( /.well-known/acme-challenge/ /var/www/dehydrated/, )要点说明需要启用alias模块server.modules (alias)alias.url以键值对形式把 URL 路径前缀映射到本地目录注意两侧的末尾斜杠。4.4 Hiawatha 示例配置Hiawatha 需要在每个 VirtualHost的配置中添加一个 AliasVirtualHost { Hostname example.tld subdomain.mywebsite.tld Alias /.well-known/acme-challenge:/var/www/dehydrated }要点说明语法为Alias URL路径:本地目录冒号分隔同一个 VirtualHost 内可列出多个域名所有列出的域名都能通过该映射访问验证文件。五、源码视角token 的写入、权限与清理全流程为了让读者理解上述 Web 配置为何能生效这里从 dehydrated 脚本源码剖析 http-01 挑战的完整生命周期对应挑战处理逻辑dehydrated生成 keyauth脚本从 CA 返回的 challenge 中取出token并拼接账户指纹构成keyauthtoken.thumbprint这是写入文件的实际内容dehydrated写入验证文件对于http-01脚本将keyauth写入${WELLKNOWN}/${challenge_tokens[${idx}]}并执行chmod ar确保文件全局可读这样 Web 服务器可能以不同用户身份运行才能读取它dehydrated部署与等待验证脚本在配置了HOOK时调用deploy_challenge钩子随后轮询 CA 的验证状态直到valid、invalid或超时dehydrated清理 token验证结束后脚本执行rm -f ${WELLKNOWN}/${challenge_tokens[${idx}]}删除验证文件并在失败路径中同样清理dehydrated、dehydrated。这一闭环说明了两点实战含义验证文件是临时性的每次验证后即被删除无需担心目录内文件堆积目录及其父级路径的写权限归 dehydrated 运行用户读权限归 Web 服务器进程用户——两者往往不同所以chmod ar是保证 Web 服务器可读的关键一步。六、验证连通性与常见排错配置完成后务必在申请证书前自测验证链路。参考 docs/troubleshooting.md 的官方建议在WELLKNOWN目录下创建一个测试文件例如test.txt用浏览器访问http://example.org/.well-known/acme-challenge/test.txt若无法访问说明 Web 服务器配置有问题需要修复。特别注意 IPv6如果你的域名解析出 IPv6 地址CA 的挑战连接会走 IPv6。浏览器访问常因自动回退到 IPv4 而掩盖问题因此必须分别测试 IPv4 与 IPv6 下的 HTTP 连通性例如curl -4 http://example.org/.well-known/acme-challenge/test.txt curl -6 http://example.org/.well-known/acme-challenge/test.txt若任何一条路径出错优先排查WELLKNOWN目录是否存在且权限正确、Web 服务器 alias 是否生效、80 端口防火墙是否放行。如果确认WELLKNOWN路径在你的域名下可读、但挑战仍然失败还可以通过--challenge (-t)参数切换验证方式http-01、dns-01、dns-persist-01、tls-alpn-01详见 README.md 的参数说明或参考 docs/staging.md 使用预演staging环境进行实验避免触及 CA 的签发速率限制。七、与其他挑战方式的取舍http-01是 dehydrated 的默认挑战类型源码默认值CHALLENGETYPEhttp-01见 dehydrated。当你面临多 docroot、纯内网主机、通配符证书等场景时可以对比以下替代方案dns-01 / dns-persist-01通过 DNS TXT 记录完成验证适合无法对外暴露 80 端口的主机无需 Web 服务器配置但需要 DNS 服务商支持的钩子脚本详见 docs/dns-verification.mdtls-alpn-01通过 TLS ALPN 协议完成验证需要额外输出 ALPN 验证证书目录--alpn参数相关说明见 docs/tls-alpn.md。选择http-01时本文的WELLKNOWN Web 服务器 alias 方案即是标准且官方推荐的部署形态选择其他方式时WELLKNOWN目录无需对外暴露但CHALLENGETYPE需相应调整可全局配置也可按证书覆盖见 docs/per-certificate-config.md。赞分享网络安全运维【免费下载链接】dehydratedACME client implemented as a simple shell-script – just add water项目地址https://gitcode.com/gh_mirrors/de/dehydrated点击查看免费下载相关推荐纯Shell实现ACME验证HTTP-01挑战全解析纯Shell实现ACME验证HTTP 01挑战全解析 你还在为配置HTTPS证书手动验证域名而烦恼吗本文将深入解析acme.sh如何仅用Shell脚本实现ACLI网络安全acme-companion DNS验证方案替代HTTP-01挑战的高级选项acme companion DNS验证方案替代HTTP 01挑战的高级选项 你是否遇到过HTTP 01验证失败的困扰在复杂网络环境下如多服务器负载均衡、云原生运维Certbot 域名验证挑战Challenge完全指南HTTP-01 与 DNS-01 原理、认证器插件选择与实战排障Certbot 域名验证挑战Challenge完全指南HTTP 01 与 DNS 01 原理、认证器插件选择与实战排障 Certbot 是 EFF 出品的网络安全CLI后端上一篇终极指南如何为openFPGALoader选择最适合你的FPGA开发板下一篇HMCL启动器GitHub星标破万的Minecraft神器是如何炼成的创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考