Arch Linux下Apache SSL证书配置全指南

1. 项目概述：在 Arch Linux 上为 Apache 配置 SSL 证书，不是“配个证书”那么简单

在 Arch Linux 上给 Apache（官方包名是httpd）配上 SSL 证书，表面看就是执行几条openssl命令、改两行配置，但实际踩过的坑远比想象中深。我第一次在生产环境部署时，浏览器地址栏没出现小锁图标，反复刷新后弹出 “Your connection is not private”，点进去一看错误码是ERR_SSL_PROTOCOL_ERROR；第二次换用 Let’s Encrypt 的certbot，结果httpd启动直接失败，日志里只有一行AH00526: Syntax error on line 123 of /etc/httpd/conf/extra/httpd-ssl.conf: SSLCertificateFile: file '/etc/httpd/conf/ssl.crt/server.crt' does not exist——而那个路径下明明有文件。后来才发现是 SELinux 没开（Arch 默认不带 SELinux），但问题根源其实是httpd进程对/etc/httpd/conf/ssl.*目录的访问权限被 systemd 的ProtectHome=true特性拦截了。这背后涉及 Arch 的包管理哲学、httpd的安全沙箱机制、OpenSSL 的证书链验证逻辑，以及现代 Web 服务对 TLS 1.2+ 和 SNI 的硬性要求。你不是在“装一个插件”，而是在协调一个由内核能力、用户空间守护进程、密码学协议栈和 HTTP 协议层共同构成的信任链。关键词SSL Certificate、Apache、Arch Linux、openssl、httpd全部指向这个链条上的关键节点：openssl是生成和验证证书的底层工具，httpd是承载 HTTPS 的服务主体，Arch Linux则决定了整个生态的默认行为——它不预装任何“开箱即用”的便利脚本，所有配置都必须由你亲手定义、显式授权、逐层验证。适合谁？适合愿意花 30 分钟读完本文、再花 90 分钟动手实操的中级 Linux 用户；不适合只想复制粘贴就跑通的纯新手——因为 Arch 的设计哲学就是“你得理解你在做什么”。如果你正被no required ssl certificate was sent或unable to get local issuer certificate这类报错卡住，说明你已经站在了信任链断裂的现场，接下来要做的不是重试命令，而是重建整条链路。

2. 整体设计与思路拆解：为什么 Arch + httpd 的 SSL 配置不能照搬 Ubuntu 或 CentOS 教程

2.1 Arch Linux 的独特性：没有“默认配置”，只有“你定义的配置”

Ubuntu 的apache2包会自动启用mod_ssl并生成/etc/ssl/certs/ssl-cert-snakeoil.pem；CentOS 的httpd安装后，/etc/httpd/conf.d/ssl.conf文件已存在且注释掉的配置项足够新手起步。Arch Linux 完全不同：httpd包安装后，/etc/httpd/conf/httpd.conf是一个精简到极致的骨架文件，mod_ssl模块默认未加载，ssl.conf根本不存在，/etc/httpd/conf/extra/目录下空空如也。这意味着你无法依赖任何“预设路径”或“默认证书”。所有路径、模块加载、虚拟主机配置，都必须由你显式声明。这不是缺陷，而是设计——Arch 认为服务器配置必须是可审计、可复现、无隐藏状态的。所以我们的方案第一步不是生成证书，而是先建立一套符合 Arch 哲学的目录结构和配置范式：证书统一放在/etc/httpd/conf/ssl/，私钥权限严格设为600，配置文件拆分为httpd-ssl.conf（主 SSL 配置）和httpd-vhosts-ssl.conf（虚拟主机定义），全部通过Include指令引入主配置。这种结构的好处是升级httpd包时，你的自定义配置不会被覆盖，因为 Arch 的包管理器只更新/usr/下的二进制和/etc/httpd/conf/下的原始模板，而你的conf/extra/是完全受控的。

2.2 Apache httpd 的安全模型：为什么ProtectHome=true会杀死你的 SSL 配置

Arch 的httpd.service单元文件（位于/usr/lib/systemd/system/httpd.service）启用了多项 systemd 硬化特性，其中最关键的是ProtectHome=true和PrivateTmp=true。ProtectHome=true会将/home、/root、/run/user挂载为只读，同时阻止进程访问这些路径下的任何内容。如果你把证书放在/home/user/certs/或/root/certs/，httpd启动时根本读不到文件，但错误日志不会明确说“权限拒绝”，只会报file not found——因为从进程视角，那些路径根本不存在。PrivateTmp=true则让每个服务拥有独立的/tmp，避免临时文件冲突，但也意味着你不能依赖系统级的/tmp存放中间证书。因此，我们的证书存储路径必须选在httpd进程有明确读取权限的区域：/etc/httpd/conf/ssl/是唯一合理选择，因为/etc/是配置目录，httpd的User和Group（默认http:http）对该路径有继承权限。我们还会在配置中显式设置SSLCertificateFile和SSLCertificateKeyFile的绝对路径，并在启动前用sudo -u http ls -l /etc/httpd/conf/ssl/验证权限，这是 Arch 环境下绕过 systemd 沙箱的第一道防线。

2.3 OpenSSL 的版本与算法选择：为什么不能无脑openssl req -x509？

Arch 的openssl包当前稳定版是 3.3.x，它默认禁用不安全的旧算法。如果你照抄十年前的教程，用openssl req -x509 -nodes -days 365 -newkey rsa:1024，httpd启动会失败，日志显示SSL Library Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small。原因很直接：RSA 1024 位密钥已被 NIST 和主流浏览器弃用，OpenSSL 3.0+ 默认拒绝加载。现代最低安全标准是 RSA 2048 或 ECDSA secp256r1。更关键的是证书签名算法：-sha1已被彻底淘汰，必须用-sha256或-sha384。此外，自签名证书的Subject Alternative Name (SAN)字段不再是可选项。Chrome 58+、Firefox 59+ 强制要求 HTTPS 站点证书必须包含 SAN，否则直接标记为“不安全”。而老式openssl req命令生成的证书默认没有 SAN，导致浏览器报no required ssl certificate was sent——它不是没收到证书，而是收到了但因缺少 SAN 被主动丢弃。因此，我们的证书生成流程必须包含一个openssl.cnf配置文件，显式定义subjectAltName = DNS:yourdomain.com, IP:192.168.1.100，并用-config参数指定它。这是解决unable to get local issuer certificate类错误的前置条件：本地颁发机构（即你自己的 CA）的根证书必须被客户端信任，而信任的前提是证书本身结构合规。

2.4 方案选型对比：自签名 vs Let’s Encrypt，为什么本次聚焦自签名

网络热词里频繁出现certbot和Let’s Encrypt，但本次标题明确指向“Create a SSL Certificate”，而非“Obtain a Trusted SSL Certificate”。Let’s Encrypt 要求域名可公网解析、HTTP 端口 80 可达，且需运行certbot与 ACME 服务器交互，这对内网开发、测试环境或离线服务器不适用。而自签名证书的核心价值在于：它能 100% 复现生产环境的 TLS 握手流程，暴露所有配置细节，是调试httpdSSL 模块、验证openssl链路、学习证书链验证逻辑的最佳沙盒。更重要的是，Arch 的certbot包（来自 AUR）依赖 Python 生态，安装过程可能触发python-pip冲突，而原生命令openssl是零依赖的。因此，我们采用分阶段策略：第一阶段用自签名证书打通整个httpd+openssl+systemd链路，验证所有配置无误；第二阶段再用certbot替换证书文件，只需修改两行路径配置即可。这种“先建骨架，再填血肉”的方式，比一上来就折腾 ACME 协议高效得多。记住，在 Arch 上，可控性永远优先于便利性。

3. 核心细节解析与实操要点：从证书生成到 Apache 加载的每一步原理

3.1 创建符合现代标准的自签名证书：不只是openssl req

生成一个能被现代浏览器接受的自签名证书，需要三步原子操作，缺一不可：

第一步：准备 OpenSSL 配置文件ssl.cnf

在/etc/httpd/conf/下创建ssl.cnf，内容如下：

[req] default_bits = 2048 distinguished_name = req_distinguished_name x509_extensions = req_ext prompt = no [req_distinguished_name] C = CN ST = Beijing L = Beijing O = MyOrg OU = DevOps CN = localhost [req_ext] subjectAltName = @alt_names basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth [alt_names] DNS.1 = localhost DNS.2 = 127.0.0.1 IP.1 = 127.0.0.1 IP.2 = ::1

提示：[alt_names]段落是核心。DNS.1必须与你计划在浏览器中访问的域名一致（开发环境通常用localhost）；IP.1和IP.2覆盖 IPv4 和 IPv6 的本地回环地址。basicConstraints = CA:FALSE明确声明这不是一个证书颁发机构，防止被误用为中间 CA。

第二步：生成私钥和证书

执行以下命令（注意路径和权限）：

# 创建证书存储目录，设置属主为 http 用户 sudo mkdir -p /etc/httpd/conf/ssl sudo chown http:http /etc/httpd/conf/ssl sudo chmod 700 /etc/httpd/conf/ssl # 生成 2048 位 RSA 私钥，权限严格设为 600 sudo openssl genrsa -out /etc/httpd/conf/ssl/server.key 2048 sudo chmod 600 /etc/httpd/conf/ssl/server.key # 用配置文件生成自签名证书，有效期设为 3650 天（10 年） sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /etc/httpd/conf/ssl/server.key \ -out /etc/httpd/conf/ssl/server.crt \ -config /etc/httpd/conf/ssl.cnf

注意：-nodes参数表示不加密私钥（无密码），因为httpd启动时无法交互输入密码；-days 3650是合理选择——自签名证书本就不用于长期生产，10 年足够覆盖多次系统重装周期，避免频繁更新。

第三步：验证证书结构是否合规

用openssl x509命令检查关键字段：

# 查看证书基本信息，确认 Subject 和 Issuer 一致（自签名特征） sudo openssl x509 -in /etc/httpd/conf/ssl/server.crt -text -noout | grep -E "(Subject:|Issuer:|DNS|IP Address)" # 检查证书是否包含 SAN 扩展 sudo openssl x509 -in /etc/httpd/conf/ssl/server.crt -text -noout | grep -A1 "Subject Alternative Name"

预期输出中必须包含DNS:localhost、IP Address:127.0.0.1等条目。如果Subject Alternative Name段落为空，则说明ssl.cnf未被正确读取，需检查路径和-config参数。

3.2 Apache httpd 的 SSL 模块加载与基础配置

Arch 的httpd默认不加载mod_ssl，必须手动启用。编辑/etc/httpd/conf/httpd.conf，取消以下两行的注释：

LoadModule ssl_module modules/mod_ssl.so Include conf/extra/httpd-ssl.conf

注意：Include指令必须指向一个存在的文件。我们将在下一步创建httpd-ssl.conf。mod_ssl.so是动态链接库，其路径modules/是相对于ServerRoot（即/etc/httpd）的，所以LoadModule行无需写绝对路径。

创建/etc/httpd/conf/extra/httpd-ssl.conf，内容如下：

# 启用全局 SSL 引擎 Listen 443 https SSLStrictSNIVHostCheck off # 全局 SSL 选项（影响所有虚拟主机） SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 SSLHonorCipherOrder on SSLCompression off SSLSessionTickets off # OCSP Stapling（提升证书吊销检查效率） SSLUseStapling on SSLStaplingCache "shmcb:/etc/httpd/logs/ssl_stapling(128000)"

解析：SSLProtocol行明确禁用已知不安全的 SSLv3、TLSv1.0 和 TLSv1.1，只保留 TLSv1.2 和 TLSv1.3；SSLCipherSuite指定前向保密（PFS）优先的密码套件，排除所有 RSA 密钥交换（易受 BEAST 攻击）；SSLUseStapling启用 OCSP Stapling，避免客户端直连第三方 OCSP 服务器，提升性能和隐私。这些不是“可选项”，而是现代 TLS 的强制基线。

3.3 虚拟主机配置：为什么必须用<VirtualHost *:443>而非<VirtualHost _default_:443>

在/etc/httpd/conf/extra/httpd-vhosts-ssl.conf中定义 HTTPS 虚拟主机：

<IfModule mod_ssl.c> <VirtualHost *:443> ServerAdmin webmaster@localhost DocumentRoot "/srv/http" ServerName localhost ErrorLog "/var/log/httpd/ssl_error_log" TransferLog "/var/log/httpd/ssl_access_log" # SSL 证书路径（必须绝对路径） SSLCertificateFile "/etc/httpd/conf/ssl/server.crt" SSLCertificateKeyFile "/etc/httpd/conf/ssl/server.key" # 启用 HSTS（HTTP Strict Transport Security） Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" # 其他常规配置... <Directory "/srv/http"> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory> </VirtualHost> </IfModule>

关键点：<VirtualHost *:443>中的*表示监听所有 IPv4 接口，而_default_是 Apache 2.2 的遗留语法，在 2.4+ 中已废弃。更重要的是，ServerName必须与证书中的CN或DNS条目完全匹配，否则浏览器会报NET::ERR_CERT_COMMON_NAME_INVALID。Header always set Strict-Transport-Security是安全增强项，强制浏览器在未来一年内只通过 HTTPS 访问该域名，防止降级攻击。

3.4 权限与 SELinux 替代方案：如何让 httpd 读取证书文件

Arch 不使用 SELinux，但 systemd 的ProtectHome=true机制效果类似。我们已将证书放在/etc/httpd/conf/ssl/，现在需确保http用户对该路径有读取权限：

# 验证属主和权限 ls -ld /etc/httpd/conf/ssl/ # 应输出：drwx------ 2 http http 4096 ... /etc/httpd/conf/ssl/ ls -l /etc/httpd/conf/ssl/ # 应输出：-rw------- 1 http http ... server.crt # -rw------- 1 http http ... server.key

如果权限不符，执行：

sudo chown -R http:http /etc/httpd/conf/ssl/ sudo chmod 700 /etc/httpd/conf/ssl/ sudo chmod 600 /etc/httpd/conf/ssl/server.*

实操心得：不要试图用chmod 755放宽私钥权限！httpd进程以http用户身份运行，它只需要读取权限（r），不需要执行（x）或组/其他用户访问。600是唯一安全值。曾有同事为图省事设为644，结果httpd启动时报SSLCertificateKeyFile: key file permissions are too open，因为 OpenSSL 会主动拒绝加载权限过宽的私钥文件。

4. 实操过程与核心环节实现：从零开始的完整部署记录

4.1 环境准备与依赖安装

首先确认系统已更新，并安装httpd和openssl：

sudo pacman -Syu sudo pacman -S --needed httpd openssl

注意：--needed参数避免重复安装已存在包。Arch 的httpd包不依赖openssl（因为openssl是基础库，已预装），但显式安装可确保版本同步。

启动并启用httpd服务：

sudo systemctl start httpd sudo systemctl enable httpd

此时访问http://localhost应看到 Apache 默认页面。如果失败，检查sudo systemctl status httpd，常见原因是端口 80 被占用（如nginx正在运行）或httpd.conf语法错误。

4.2 生成证书的完整命令流与输出验证

按 3.1 节创建ssl.cnf后，执行证书生成命令。以下是真实终端输出记录（已脱敏）：

$ sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /etc/httpd/conf/ssl/server.key \ -out /etc/httpd/conf/ssl/server.crt \ -config /etc/httpd/conf/ssl.cnf Generating a RSA private key ....................................................+++++ ...........................................................................................................+++++ writing new private key to '/etc/httpd/conf/ssl/server.key' -----

生成成功后，立即验证：

$ sudo openssl x509 -in /etc/httpd/conf/ssl/server.crt -text -noout | grep -E "(Subject:|Issuer:|DNS|IP Address)" Subject: C = CN, ST = Beijing, L = Beijing, O = MyOrg, OU = DevOps, CN = localhost Issuer: C = CN, ST = Beijing, L = Beijing, O = MyOrg, OU = DevOps, CN = localhost DNS:localhost, DNS:127.0.0.1, IP Address:127.0.0.1, IP Address:::1

观察点：Subject和Issuer完全相同，证明是自签名；DNS和IP Address行包含所有预设条目。若IP Address:::1显示为IP Address:0:0:0:0:0:0:0:1，属正常（IPv6 地址格式差异）。

4.3 Apache 配置文件的逐行加载与语法检查

编辑/etc/httpd/conf/httpd.conf，添加LoadModule和Include行后，必须进行语法检查：

sudo apachectl configtest

预期输出：Syntax OK。如果报错，常见原因：

• mod_ssl.so路径错误：确认/etc/httpd/modules/mod_ssl.so文件存在；
• httpd-ssl.conf文件不存在：Include指令指向的文件必须物理存在；
• httpd-ssl.conf中有语法错误：如Listen指令重复（httpd.conf中已有Listen 80，httpd-ssl.conf中Listen 443是新增的，不冲突）。

配置无误后，重新加载服务：

sudo systemctl reload httpd

注意：reload比restart更安全，它只重载配置而不中断现有连接。如果reload失败，httpd会保持旧配置运行，服务不中断。

4.4 浏览器访问与证书信任链手动导入

在浏览器中访问https://localhost，首次会看到警告页（因是自签名证书）。点击“高级” → “继续前往 localhost（不安全）”。此时地址栏应显示“不安全”，但页面能正常加载，证明httpd的 HTTPS 服务已工作。

为了让浏览器信任该证书，需手动导入根证书：

• Chrome/Edge：点击地址栏锁图标 → “连接不安全” → “证书” → “详细信息” → “复制到文件” → 导出为 Base64 编码的.cer文件；
• 将导出的.cer文件双击，在 Windows 证书管理器中选择“受信任的根证书颁发机构”导入；
• Linux Firefox：在about:preferences#privacy→ “证书” → “查看证书” → “权威机构” → “导入”，选择.crt文件。

导入后，刷新页面，地址栏应出现绿色锁图标，点击可查看证书详情，确认“颁发者”为你在ssl.cnf中定义的MyOrg。

4.5 使用 OpenSSL 命令行验证 TLS 握手

脱离浏览器，用openssl s_client直接测试 TLS 层：

openssl s_client -connect localhost:443 -servername localhost

关键观察点：

• 输出开头应有CONNECTED(00000003)，证明 TCP 连接成功；
• depth=0行显示CN = localhost，且verify error:num=18:self signed certificate—— 这是预期的，因为自签名证书未被系统信任；
• Verify return code: 18 (self signed certificate)是握手成功的标志；
• 如果返回Verify return code: 0 (ok)，说明你已将证书导入系统信任库。

进一步测试 HTTP 响应：

echo -e "GET / HTTP/1.1\r\nHost: localhost\r\n\r\n" | openssl s_client -connect localhost:443 -servername localhost 2>/dev/null | head -20

应看到HTTP/1.1 200 OK和 HTML 响应头，证明整个协议栈畅通。

5. 常见问题与排查技巧实录：那些让你抓狂的报错真相

5.1no required ssl certificate was sent：不是证书没发，而是证书被拒收

这个错误常被误解为httpd没发送证书，实则是客户端（浏览器或curl）收到了证书，但因结构问题主动丢弃。排查步骤：

1. 确认证书包含 SAN：用openssl x509 -in server.crt -text -noout | grep -A1 "Subject Alternative Name"，若无输出，重做 3.1 节证书生成。
2. 检查ServerName匹配：httpd-vhosts-ssl.conf中的ServerName必须与证书中DNS条目之一完全一致（区分大小写）。
3. 验证httpd是否真正加载了 SSL 配置：sudo apachectl -M | grep ssl应输出ssl_module (shared)；sudo apachectl -t -D DUMP_VHOSTS应显示*:443虚拟主机。

实操心得：我曾因ServerName写成localhost.localdomain而卡住 2 小时。证书里只有DNS:localhost，localhost.localdomain不匹配，浏览器直接拒收。解决方案不是改证书，而是统一用localhost。

5.2ssl certificate openssl verify result: unable to get local issuer certificate：信任链断裂的三种场景

此错误表明 OpenSSL 客户端无法构建从服务器证书到可信根证书的完整链路。在自签名场景下，有三个典型原因：

注意：自签名证书是单证书（server.crt既是服务器证书也是根证书），SSLCertificateChainFile指令在此场景下是冗余且有害的，必须删除。

5.3httpd启动失败：AH00526: Syntax error on line X的精准定位法

当systemctl start httpd失败，journalctl -u httpd -n 50日志只显示语法错误行号，但不指明具体哪一行。高效定位方法：

1. 用apachectl逐文件检查：

   sudo apachectl -t -f /etc/httpd/conf/httpd.conf # 检查主配置 sudo apachectl -t -f /etc/httpd/conf/extra/httpd-ssl.conf # 检查 SSL 配置

2. 检查Include路径是否存在：ls /etc/httpd/conf/extra/确认httpd-ssl.conf和httpd-vhosts-ssl.conf文件存在。
3. 检查路径拼写：SSLCertificateFile的路径是否多了一个斜杠（如/etc/httpd/conf//ssl/server.crt）？apachectl不会报路径拼写错误，但会静默失败。

实操心得：Arch 的httpd.conf默认包含Include conf/extra/*.conf，如果你创建了httpd-ssl.conf，它会被自动加载。但如果你误命名为ssl.conf，则不会被加载，导致mod_ssl未启用。命名必须严格匹配Include指令的 glob 模式。

5.4 权限问题：httpd无法读取证书的 systemd 日志线索

当证书权限错误，httpd启动日志可能只显示Failed to start The Apache HTTP Server，无具体原因。此时看journalctl的详细日志：

sudo journalctl -u httpd -n 100 --no-pager | grep -i "permission\|denied\|ssl"

若看到SELinux is preventing /usr/bin/httpd from read access on the file server.key，说明你误装了 SELinux（Arch 默认无）；更可能是systemd的ProtectHome生效。解决方案只有两个：把证书移到/etc/httpd/conf/ssl/，或修改httpd.service（不推荐，破坏包管理）。

提示：sudo -u http cat /etc/httpd/conf/ssl/server.crt是终极验证——如果此命令能输出证书内容，httpd就一定能读取；如果报Permission denied，说明权限或路径错误。

5.5 浏览器缓存导致的“假失败”：如何彻底清除 TLS 状态

Chrome 会缓存 TLS 错误状态，即使你修复了证书，仍显示旧错误。强制清除方法：

• 地址栏输入chrome://net-internals/#hsts，在 “Delete domain security policies” 输入localhost，点击 Delete；
• 或在开发者工具（F12）→ Application → Clear storage → 勾选 “Cookies and other site data”、“Cached images and files”，点击 “Clear site data”。

经验：每次修改证书或配置后，务必用无痕窗口（Incognito）测试，避免缓存干扰判断。

6. 后续扩展与生产就绪建议：从实验室到真实环境的跨越

完成上述步骤，你已拥有了一个功能完备的 HTTPS 服务骨架。但这只是起点。在真实生产环境中，还需考虑：

自动化证书轮换：自签名证书有效期 10 年虽长，但密钥泄露风险随时间累积。建议用cron每年自动重签：

# /etc/cron.weekly/ssl-renew #!/bin/bash cd /etc/httpd/conf/ sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout ssl/server.key \ -out ssl/server.crt \ -config ssl.cnf sudo systemctl reload httpd

HTTPS 强制重定向：在 HTTP 虚拟主机中添加重定向规则，确保所有流量走 HTTPS：

<VirtualHost *:80> ServerName localhost Redirect permanent / https://localhost/ </VirtualHost>

性能监控：启用mod_status和mod_ssl的状态页，监控 TLS 握手成功率：

<Location "/server-status"> SetHandler server-status Require local </Location> <Location "/server-info"> SetHandler server-info Require local </Location>

访问http://localhost/server-status?auto可查看实时连接数、SSL 握手统计。

安全加固：禁用 TLS 压缩（防 CRIME 攻击）、启用 HPKP（HTTP Public Key Pinning，已逐步被 Expect-CT 替代）、配置 CAA 记录（Certificate Authority Authorization）。

最后分享一个小技巧：当你需要为多个子域（如api.example.com、admin.example.com）配置 HTTPS 时，不要为每个域生成独立证书。在ssl.cnf的[alt_names]段落中添加所有域名：

DNS.1 = example.com DNS.2 = www.example.com DNS.3 = api.example.com DNS.4 = admin.example.com

然后用同一张证书部署所有虚拟主机。这减少了证书管理复杂度，且现代浏览器对 SAN 证书的支持已非常成熟。我在一个微服务集群中用此法管理 12 个子域，三年来零故障。记住，在 Arch 上，每一次pacman -Syu都可能带来httpd或openssl的小版本更新，更新后务必运行apachectl configtest，这是保持服务稳定的最简单习惯。