从商业证书颁发机构安装SSL证书
简介
您可以通过生成CSR和私钥，将CSR提交给受信任的证书颁发机构（CA），验证域名控制权，然后在您的Web服务器上安装颁发的证书和中间链，来安装商业SSL/TLS证书。结果是获得浏览器信任的HTTPS，对于OV/EV选项，CA还会进行额外的组织验证（适用于内部政策、采购或合规需求）。
在2010年代中期之前，许多小型网站并不总是使用SSL或HTTPS。自那时起，安全期望不断提高，Let's Encrypt项目应运而生，以大规模提供免费、受信任的SSL证书，使几乎每个人都能根据需要使用HTTPS。
然而，Let's Encrypt的证书存在一些限制。它们每90天过期，通常需要有效的自动续订流程。在自动化受限或出站验证挑战（例如通配符证书的DNS更新）不可行的环境中，Let's Encrypt也可能更难使用。此外，商业CA可能提供证书管理功能、保修/保险条款或组织审查，这些是一些企业和合规计划所偏好的。
本教程将引导您完成选择CA、生成CSR和私钥、获取证书以及在Ubuntu上的Nginx或Apache上安装它的过程。您还将看到如何验证安装、修复常见的证书链问题以及处理续订。
关键要点
- 商业SSL适用于特定需求：无需频繁续订自动化的较长有效期、满足组织审查需求的OV/EV，或供应商功能（支持SLA、托管重新颁发、保修/合同条款）。
- CSR和私钥保留在您的服务器上：您只将CSR发送给CA；私钥永不离开机器。
- 证书链必须完整：提供您的站点证书加上CA的中间证书；缺少中间证书会导致浏览器信任错误。
- Nginx需要链式文件：将您的证书和中间证书连接成一个文件；Apache可以单独引用中间文件。
- 安装后始终验证：使用openssl s_client或浏览器确认链完整，以及HTTPS和HTTP到HTTPS重定向正常工作。
- 设置续订提醒：商业证书通常1-2年过期；错过续订会导致服务中断。
先决条件
尝试从商业CA获取SSL证书有几个先决条件：
- 一个注册的域名。本教程将全程使用example.com。您可以从Namecheap等注册商或您选择的提供商处购买域名。一些托管提供商根据可用性将域名与托管计划捆绑。
- 访问您域名WHOIS记录中的某个电子邮件地址或域名本身的“管理员类型”电子邮件地址。颁发SSL证书的证书颁发机构通常通过向域名WHOIS记录中的地址或域名本身的通用管理员电子邮件地址发送验证邮件来验证域名控制权。要获得扩展验证证书，您还需要向CA提供文件以建立网站所有者的法律身份等。
- 为您的服务器设置DNS记录。如果您使用DigitalOcean，请参阅我们的DNS文档了解如何添加它们的详细信息。
本教程使用通过Ubuntu初始服务器设置设置的Ubuntu服务器（兼容Ubuntu 22.04和24.04），包括具有sudo权限的非root用户和防火墙。您还应该按照如何在Ubuntu上安装Nginx或如何在Ubuntu上安装Apache Web服务器安装了Nginx或Apache。确保您为域名设置了服务器块（或Apache虚拟主机）。
步骤1 - 选择您的证书颁发机构
使用是主要根程序成员的CA（以便浏览器信任它），并提供您所需的证书类型。以下是需要检查的主要因素。
根证书程序成员资格
最关键的一点是，您选择的CA是最常用操作系统和Web浏览器的根证书程序的成员，即它是一个“受信任的”CA，其根证书受常见浏览器和其他软件信任。如果您的网站的SSL证书由受信任的CA签名，那么信任该CA的软件会认为其身份有效。
您遇到的大多数商业CA将是常见根CA程序的成员，但在购买证书前检查一下也无妨。例如，Apple发布了其受信任的SSL根证书列表。
证书类型
确保您选择提供所需证书类型的CA。许多CA以各种名称和定价结构提供这些证书类型的变体。以下是每种类型的简短描述：
- 单域名：用于单个域名，例如example.com。注意，额外的子域名（如www.example.com）不包括在内。
- 通配符：用于域名及其任何子域名。例如，*.example.com的通配符证书也可用于www.example.com和store.example.com。
- 多域名：称为SAN或UC证书，这些可用于添加到主题备用名字段的多个域名和子域名。例如，单个多域名证书可用于example.com、www.example.com和example.net。
除了上述证书类型外，CA还提供不同级别的验证：
- 域名验证（DV）：CA验证请求者拥有或控制相关域名后颁发DV证书。
- 组织验证（OV）：颁发CA验证请求者的法律身份后，才能颁发OV证书。
- 扩展验证（EV）：根据严格的指导方针，颁发CA验证请求者的法律身份等后，才能颁发EV证书。此类证书的目的是提供额外保证，即网站背后的组织已通过CA验证，这可能对内部政策、采购或合规要求有用。EV证书可以是单域名或多域名，但不能是通配符。
快速证书选择指南
使用下表根据常见的实际需求选择合适的证书类型：
- 具有基本HTTPS的公共网站：域名验证（DV）
- 用户可见的公司身份：组织验证（OV）或扩展验证（EV）
- 许多子域名（例如*.example.com）：通配符证书
- 多个不相关的域名：多域名（SAN）证书
- 不允许自动续订：商业DV/OV证书
- 监管或合规要求：OV或EV证书
如果您只需要加密和浏览器信任，DV证书就足够了。当需要法律身份验证或品牌信任指标时，选择OV或EV。
附加功能
许多CA提供大量“额外”功能，以区别于其他SSL证书颁发供应商。其中一些功能最终可以为您节省资金，因此在购买前权衡您的需求与提供的功能非常重要。需要注意的功能示例包括免费证书重新颁发或适用于www.和域名基本名称的单域名定价证书，例如www.example.com带有example.com的SAN。
步骤2 - 生成CSR和私钥
在您准备好先决条件并知道所需证书类型后，是时候生成证书签名请求（CSR）和私钥了。如果您计划使用Apache HTTP或Nginx作为Web服务器，可以在Web服务器上使用openssl命令生成私钥和CSR。
在本教程中，您可以将所有相关文件保存在主目录中，但也可以将它们存储在服务器上的任何安全位置：
要生成私钥和CSR（将example.com替换为您的域名），运行：- openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr
此时，您将被提示输入几行信息，这些信息将包含在您的证书请求中。最重要的部分是通用名字段，它应与您希望使用证书的名称匹配，例如example.com、www.example.com或（对于通配符证书请求）*.example.com。如果您计划获取OV或EV证书，请确保所有其他字段准确反映您的组织或业务详细信息。提供“挑战密码”不是必需的。
例如：输出
国家名称（2字母代码）[AU]:US
州或省名称（全名）[Some-State]:New York
地区名称（例如城市）[]:New York
组织名称（例如公司）[Internet Widgits Pty Ltd]:My Company
组织单位名称（例如部门）[]:
通用名称（例如服务器FQDN或您的姓名）[]:example.com
电子邮件地址[]:[email protected]
请输入以下要随证书请求发送的“额外”属性
挑战密码[]:
可选公司名称[]: 输出
example.com.csr example.com.key
步骤3 - 购买和获取证书
有许多商业CA提供商，您可以比较和对比最适合您设置的选项。例如，Namecheap作为SSL证书经销商，过去曾更换上游CA提供商以提供最佳价值。许多经销商（例如Namecheap）提供来自受信任CA（如Sectigo/Comodo）的证书。
以下是典型产品的示例：
做出选择后，您需要上传上一步生成的CSR。您的CA提供商可能还有一个“批准者”步骤，该步骤将向您域名的WHOIS记录中的地址或您获取证书的域名的管理员类型地址发送验证请求电子邮件。批准证书后，证书将通过电子邮件发送给指定的管理员。
将它们复制并保存到服务器上生成私钥和CSR的同一位置。将证书命名为域名加.crt扩展名，例如example.com.crt，并将中间证书命名为intermediate.crt。
证书现在已准备好安装在您的Web服务器上，但首先，您可能需要对防火墙进行一些更改。
步骤4 - 更新防火墙以允许HTTPS
如果您按照我们的Ubuntu设置指南启用了ufw防火墙，您需要调整设置以允许HTTPS流量。Nginx和Apache在安装时都会向ufw注册一些配置文件。您可以通过键入以下命令查看当前设置：如果您收到的输出仅包含Nginx HTTP或Apache，则只允许HTTP流量到Web服务器：输出
状态：活动
到 动作 从
-- ------ ----
OpenSSH 允许 任何地方
Nginx HTTP 允许 任何地方
OpenSSH (v6) 允许 任何地方 (v6)
Nginx HTTP (v6) 允许 任何地方 (v6) - sudo ufw allow 'Nginx Full'
- sudo ufw delete allow 'Nginx HTTP'
- sudo ufw allow 'Apache Full'
- sudo ufw delete allow 'Apache'
输出
状态：活动
到 动作 从
-- ------ ----
OpenSSH 允许 任何地方
Nginx Full 允许 任何地方
OpenSSH (v6) 允许 任何地方 (v6)
Nginx Full (v6) 允许 任何地方 (v6)
步骤5 - 在服务器上安装证书
从您选择的CA获取证书后，您需要将其安装在Web服务器上。这涉及向Web服务器软件配置添加一些与SSL相关的行。本教程涵盖Ubuntu上的Nginx和Apache（兼容Ubuntu 22.04及更高版本）；大多数现代Linux发行版的工作方式类似。
本教程还做出以下假设：
- 私钥称为example.com.key
- SSL证书称为example.com.crt
- 您的提供商返回的CA中间证书在名为intermediate.crt的文件中
注意：在生产环境中，这些文件应存储在只有Web服务器进程（通常是root）可以访问的位置，并且私钥应保持安全。例如，Let's Encrypt将其生成的证书存储在/etc/letsencrypt。由于多服务器配置的复杂性，生产示例会有所不同。
Nginx
这些是在Nginx上手动部署SSL证书的步骤。浏览器需要完整的链（您的证书加上CA的中间证书）来信任您的站点。如果您的CA只返回一个中间证书（或多个中间证书），您必须创建一个包含您的证书后跟中间证书的单个链式文件。Nginx期望ssl_certificate有一个文件；Apache可以使用单独的中间文件（见下面的Apache部分）。
在生产环境中，将证书存储在系统位置而不是主目录中。常见路径包括/etc/ssl/certs用于证书文件和/etc/ssl/private用于私钥。将私钥权限限制为仅root：- sudo chmod 600 /etc/ssl/private/example.com.key
- sudo chown root:root /etc/ssl/private/example.com.key
- cat example.com.crt intermediate.crt > example.com.chained.crt
使用nano或您喜欢的文本编辑器，打开默认的Nginx服务器块文件进行编辑：- sudo nano /etc/nginx/sites-enabled/default
/etc/nginx/sites-enabled/default
…
server {
listen 443 ssl;
… /etc/nginx/sites-enabled/default
…
server_name example.com;
ssl_certificate /home/sammy/example.com.chained.crt;
ssl_certificate_key /home/sammy/example.com.key;
…
为了只允许最安全的SSL协议和密码套件，向文件添加以下行：/etc/nginx/sites-enabled/default
…
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
… /etc/nginx/sites-enabled/default
server {
listen 80;
server_name example.com;
return 301 https://$server_name$request_uri;
}
…
在重新启动Nginx之前，您可以使用nginx -t验证配置：如果没有问题，重新加载Nginx以应用SSL配置（或者如果您的设置不支持重新加载，使用sudo systemctl restart nginx）：- sudo systemctl reload nginx
Apache
这些是在Apache上手动部署SSL证书的步骤。
使用nano或您喜欢的文本编辑器，打开默认的Apache虚拟主机文件进行编辑：
注意：在Ubuntu上，推荐的方法是使用预配置的default-ssl.conf文件，而不是直接修改000-default.conf。更新证书路径后，您可以使用sudo a2ensite default-ssl启用它。下面显示的方法有效，但使用default-ssl.conf更符合标准Apache SSL布局。- sudo nano /etc/apache2/sites-available/000-default.conf
/etc/apache2/sites-available/000-default.conf
…
<VirtualHost *:443>
… /etc/apache2/sites-available/000-default.conf
…
ServerName example.com
… /etc/apache2/sites-available/000-default.conf
…
SSLEngine on
SSLCertificateFile /home/sammy/example.com.crt
SSLCertificateKeyFile /home/sammy/example.com.key
SSLCACertificateFile /home/sammy/intermediate.crt
…
此时，您的服务器配置为仅监听HTTPS（端口443），因此对HTTP（端口80）的请求将不会被服务。要将HTTP请求重定向到HTTPS，将以下内容添加到文件顶部（在两个地方替换名称）：/etc/apache2/sites-available/000-default.conf
<VirtualHost *:80>
ServerName example.com
Redirect permanent / https://example.com/
</VirtualHost>
…
通过运行此命令启用Apache SSL模块：现在，重新启动Apache以加载新配置并启用HTTPS上的TLS/SSL。- sudo systemctl restart apache2
验证您的SSL安装
安装证书后，验证链是否完整以及服务器是否呈现受信任的证书。从命令行，使用OpenSSL连接并检查链（将example.com替换为您的域名）：- echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer
要查看完整链和任何验证错误：- openssl s_client -connect example.com:443 -servername example.com
在浏览器中，打开https://example.com，点击挂锁，并查看证书。链应显示：您的站点证书，然后是中间证书，然后是根证书。如果链断裂，挂锁可能显示警告或“证书不受信任”。
常见SSL安装错误故障排除
浏览器显示“您的连接不是私密的”或“证书不受信任”
原因：浏览器无法构建到受信任根的完整链。通常缺少中间证书或顺序错误。
Nginx修复：确保使用链式文件（您的证书+中间证书），而不仅仅是example.com.crt。顺序必须是：站点证书在前，然后是中间证书。如果需要，重新创建链式文件：- cat example.com.crt intermediate.crt > example.com.chained.crt
Apache修复：将SSLCertificateFile设置为您的站点证书，将SSLCACertificateFile设置为中间文件。一些设置使用SSLCertificateChainFile（在较新的Apache中已弃用）或将中间证书包含在单个文件中；遵循您的CA的说明。
“SSL: wrong version number”或“rx record too long”
原因：客户端连接到错误的端口（例如443上的HTTP）或服务器在443上未说TLS。
修复：确认Web服务器正在监听443，并且listen 443 ssl（Nginx）或<VirtualHost *:443> with SSLEngine on（Apache）在正确的虚拟主机中。有关协议命名的上下文，请参阅TLS vs SSL。
私钥和证书不匹配
原因：证书是为与ssl_certificate_key或SSLCertificateKeyFile中的密钥不同的密钥颁发的。服务器将无法启动或TLS握手将失败。
修复：验证密钥和证书的模数是否匹配：- openssl x509 -noout -modulus -in example.com.crt | openssl sha256
- openssl rsa -noout -modulus -in example.com.key | openssl sha256
Nginx或Apache在配置更改后无法启动
原因：语法错误、证书/密钥路径错误或缺少中间文件。
修复：运行sudo nginx -t（Nginx）或sudo apachectl configtest（Apache）并修复任何报告的错误。确保文件路径正确，Web服务器用户可以读取证书和密钥文件（并且密钥不是全局可读的）。
续订和管理商业证书
商业证书通常有1年或2年的有效期。计划在到期前续订以避免停机。
- 设置提醒（例如到期前30-60天）。许多CA发送电子邮件提醒；不要仅依赖它们。
- 使用与初始颁发相同的步骤生成新的CSR（理想情况下是新的私钥）。一些CA允许您重用现有密钥，但续订时的密钥轮换是常见的最佳实践，并且如果密钥曾经暴露，它可以降低风险。
- 将CSR提交给您的CA，完成验证，并获取新证书和中间证书。
- 在服务器上安装新证书（和链），然后重新加载Nginx或Apache。在确认新证书工作之前，保留旧证书可用。
- 如上所述使用openssl s_client或浏览器验证。
将私钥和证书存储在安全、受限的位置（例如/etc/ssl/private，仅root可读）。对于负载均衡或多服务器设置，将相同的证书和密钥部署到每个节点或使用中央密钥存储。
常见问题解答
什么是商业SSL证书？
商业SSL/TLS证书是您从受信任的证书颁发机构（CA）或经销商处购买的证书。它由CA的根或中间证书签名，因此信任该CA的浏览器和操作系统将信任您的站点。商业证书通常提供更长的有效期（1-2年），并可能包括供应商功能，如支持SLA、托管重新颁发、保修/合同条款或组织审查。
何时应该使用付费SSL证书而不是Let's Encrypt？
当您需要更长的有效期而无需频繁的续订自动化、需要组织审查以满足内部政策/合规原因，或需要CA/供应商功能（如托管重新颁发、支持SLA或特定的保修/合同条款）时，使用商业证书。Let's Encrypt支持多域名和通配符证书（通常通过DNS验证），因此决定通常基于续订/自动化限制、合规要求或供应商功能，而不是技术能力。
生成CSR需要哪些信息？
您需要：通用名称（CN），确切的域名（例如example.com、www.example.com或通配符的*.example.com）。对于OV/EV，CA还将使用CSR中的组织、地区、州、国家来验证您的组织。可选：电子邮件、组织单位。挑战密码不是必需的。
私钥和证书有什么区别？
私钥是您在服务器上生成并保密的密钥；它用于解密流量并证明证书的所有权。证书是由CA签名的公共文档，将您的域名（以及可选的组织）绑定到该公钥。您向CA发送CSR（其中包含公钥但不包含私钥）；他们返回证书。切勿共享或上传私钥。
什么是中间证书，为什么需要它们？
中间证书是CA颁发的证书，将您的站点证书链接到浏览器信任的根CA。浏览器只存储根证书；它们需要中间证书来构建从您的证书到受信任根的链。如果您不提供中间证书，链就不完整，浏览器可能显示“证书不受信任”。
如何在Nginx上安装SSL证书？
生成链式文件：cat example.com.crt intermediate.crt > example.com.chained.crt。在您的443端口的Nginx服务器块中，将ssl_certificate设置为链式文件，将ssl_certificate_key设置为您的私钥。使用ssl_protocols TLSv1.2 TLSv1.3;和强密码套件，然后重新加载Nginx。有关完整详细信息，请参见上面的步骤5。
如何在Apache上安装SSL证书？
启用SSL模块（sudo a2enmod ssl），然后在<VirtualHost *:443>块中设置SSLEngine on，将SSLCertificateFile设置为您的站点证书，将SSLCertificateKeyFile设置为您的密钥，将SSLCACertificateFile设置为中间证书。重新启动Apache。有关完整详细信息，请参见上面的步骤5。
如何验证我的SSL证书是否正确安装？
使用openssl s_client -connect example.com:443 -servername example.com并检查Verify return code: 0 (ok)。在浏览器中，打开https://example.com，点击挂锁，并确认证书链完整且有效期正确。
什么导致浏览器中的SSL证书信任错误？
常见原因：缺少或顺序错误的中间证书；证书已过期或尚未生效；主机名不匹配（例如证书用于www.example.com但您打开了example.com）；或证书是为与配置的密钥不同的密钥颁发的。通过提供完整链、更正密钥/证书对以及确保证书的通用名或SAN与您访问的主机匹配来修复。
结论
您现在知道如何选择商业CA、生成CSR和私钥、在Nginx或Apache上获取和安装SSL/TLS证书、验证安装以及故障排除常见的链和密钥问题。保持证书链完整和私钥安全对于浏览器信任和生产可靠性至关重要。
有关后续步骤，请参阅TLS vs SSL、OpenSSL证书和CSR要点，以及如果您后来切换到免费证书，如何用Let's Encrypt保护Nginx。有关负载均衡器和其他用例的SSL，请参阅SSL证书词汇表和网络负载均衡。
原文链接：Install an SSL Certificate from a Commercial Certificate Authority |
发表于：