最新ssl证书申请与安装配置2024版
目录
最新ssl证书申请与安装配置2024版
1、申请腾讯云ssl证书
2、ssl证书所属域名的验证
2.1、确保你的web服务正常访问“域名”及其子域“www.域名”
2.2、国内或国外均能访问
2.3、.txt文件访问验证
2.4、验证域名
3、下载签发的ssl证书
4、安装证书
4.1、解压下载的证书到web服务的执行文件所在路径的自定义路径下
4.2、若有需要代码配置证书或将配置了类似IIS的web服务DLL托管
4.3、在操作系统级别安装证书
5、配置证书
5.1、配置操作系统CSP控制安全提供者的SCHANNEL安全通道的ssl/tls协议版本
5.2、配置证书协议版本所对应的密码套件
5.2.1、配置密码套件及其顺序
5.2.2、响应“安全合规”的密码套件及其配置顺序
5.2.3、密码套件配置案例
5.3、最终的配置效果-兼顾完全安全合规、兼顾兼容性
一年一度的双11又要到了,每当此时,云服务器、证书等等,又要新购或到期续展了。这不,重新练练手,做下SSL证书的操作,以免遗忘。
1、申请腾讯云ssl证书
https://console.cloud.tencent.com/ssl
2、ssl证书所属域名的验证
备注:
RSA 加密算法与 ECC 加密算法的区别
证书,密钥,加密,rsa到底是啥
2.1、确保你的web服务正常访问“域名”及其子域“www.域名”
需要同时验证域名及其www.子域:比如你的域名是xxx.com
域名验证:
xxx.com
www.xxx.com
2.2、国内或国外均能访问
云服务器开通境外访问能力,或:
直接在你的web服务中配置跨域白名单且能生效:
现目前CA机构“亚信”域名验证时所使用的跨域服务器的IP为:
91.199.212.132,
91.199.212.133,
91.199.212.148,
91.199.212.151,
91.199.212.176,
54.189.196.217,
2.3、.txt文件访问验证
点“提交申请,进行域名验证”,将下图提示的文件下载:
将文件复制到你的web服务的“根”路径下对应上图所示的文件路径下:
cd wwwroot
mkdir .well-known
cd .well-known
mkdir pki-validation
cd pki-validation
即:
wwwroot/.well-known/pki-validation
2.4、验证域名
通过测试。点“点击此处验证‘域名’”、“点击此处验证‘子域名’”:
点“域名验证”,通过即可:
3、下载签发的ssl证书
所有类型的证书文件均下载,以备后续根据具体操作系统环境所使用,其中,根证书,必备。
4、安装证书
下面以MSWindows平台为例:
4.1、解压下载的证书到web服务的执行文件所在路径的自定义路径下
其中,“根证书”必备,如上图“域名_root.crt”;
其次,“CA证书链”必备,如上图“域名_root.pfx”;
最后,“你的证书”必备,如上图
“域名_bundle.crt”或“域名_bundle.pem”格式的证书文件;
“域名_bundle.key”; #你的证书的密钥文件。
4.2、若有需要代码配置证书或将配置了类似IIS的web服务DLL托管
确保你的web服务或websocket服务或tcp服务代码能够访问上述证书相关的文件;可能需要考虑UAC提权和ACL访问控制列表权限,视具体情况进行处理。
可选说明:确保你的IIS服务下模块你的DLL对上述证书相关的文件及其文件夹的ACL访问控制列表权限。
4.3、在操作系统级别安装证书
证书对应你的域名或IP(支持IP的证书,示具体证书类别),而最终的IP是依附于具体服务器设备的网卡上的,它们在操作系统放入支持下正常工作。所以证书一定要部署在“操作系统上”,这是正确理解和使用证书的前提。
当然,有些自研web服务,其中用代码对所申请的“CA机构签发证书”为客户端提供了访问的验证服务,也是可以的;但最终该web服务本身,也受制于其运行所依赖的操作系统;所以,最好在操作系统这个级别上,部署你的证书。
运行cmd: mmc
用“证书”节点来加载:
先删除过期的证书,其中,第3行,就是你自己的证书“cpuofbs.com”
其中,第1行证书(AAA机构的根证书)、最后1行证书(你的证书颁发机构,CA机构的证书)。
上述3类证书,构成了你申请证书的“证书链”,必须同时、正确的“部署”,用“4.1、”你下载并解压的证书文件来覆盖安装;或先删除、后重新安装。
5、配置证书
下面以MSWindows平台为例:
5.1、配置操作系统CSP控制安全提供者的SCHANNEL安全通道的ssl/tls协议版本
注册表项目:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
CSP——Control Security Providers控制安全提供者
SCHANNEL——Security CHANNEL安全通道,本质是对应了对操作系统文件schannel.dll的交互
在其下Protocols协议子项目下,创建或编辑后续你期望配置的证书密码套件的版本:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
其中,推荐配置,TLS 1.1、TLS 1.2,其余tls1.1以下的不推荐使用过时了、漏洞太多且无法弥补(比如,SSL 2.0等)。TLS v1.1 和 v1.2 都没有已知的安全问题,只有 v1.2 提供了现代的加密算法。TLS v1.2 应该是您的主要协议,因为它是唯一提供现代认证加密(也称为 AEAD)的版本。如果您今天不支持 TLS v1.2,则缺乏安全性。
若需查看访问者的日志记录:
在 Windows 和 Windows Server 中启用 Schannel 事件日志记录:
https://learn.microsoft.com/zh-CN/troubleshoot/developer/webapps/iis/health-diagnostic-performance/enable-schannel-event-logging
5.2、配置证书协议版本所对应的密码套件
这一步,是最关键的,配置错误的话,你就连最基本的RDP客户端(属于tcp服务),比如微软的“远程桌面连接”,都会在“连接”时、因加解密错误的而握手失败。
运行cmd: gpedit.msc
打开“本地计算机 策略-计算机配置-管理模板-网络-SSL 配置设置”,进行配置:
5.2.1、配置密码套件及其顺序
概念:
◆密码套件是一组加密算法,用于安全传输层协议(TLS)中的安全连接。TLS 密码套件由认证,加密和消息认证码(MAC)三个部分组成,它们提供安全性和可靠性,保护传输中的数据免受第三方窃取。在 TLS 握手过程中,客户端和服务器会协商一个可以使用的密码套件(客户端和服务器会根据它们支持的密码套件列表来确定使用哪个密码套件),以便客户端和服务器之间的通信可以使用该密码套件进行加密。
◆不同操作系统版本,对TLS的版本及其密码套件的支持:各异。
比如:windows server 2012 R2,配置如下:
windows server 2012 R2下,支持TLS 1.2、TLS 1.1的密码套件及其排列顺序:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256_P384,TLS_RSA_WITH_AES_128_GCM_SHA256
windows server 2012 R2本身就不支持TLS 1.3,即便是你在“5.1、配置操作系统CSP控制安全提供者的SCHANNEL安全通道的ssl/tls协议版本”中,配置了“TLS 1.3”的安全通道,即便是你的web服务支持TLS 1.3对传输进行加解密,也会“无效”,甚至因为你的配置,而导致用户访问“失败”,因为它们是有优先级顺序的。
概念:
◆优先级顺序
取决于你在“5.1、”配置的“安全通道”,按照先TLS后SSL、先高版本后低版本的顺序,浏览器客户端会用其支持的最高级别TLS 1.3去握手你的服务器;你的服务器的SCHANNEL“安全通道”中若配置并允许TLS 1.3协议,则服务器会进一步检查你配置的“密码套件及其顺序”,据此,回复客户端,我这里支持TLS 1.3协议,且采用你期望使用的“密码套件”,接下来我们双向就用它们来进行传输加密和解密;否则:
要么“SCHANNEL安全通道中有开通TLS 1.3协议、结果配置中找不到对应的密码套件”导致访问失败、要么“若有支持TLS 1.3的密码套件、但因配置错误”导致访问失败。
◆证书的算法选择
RSA或ECC——取决于你在申请证书时的“算法选择”,用于后期通讯时的加解密的算法。加解密算法不同,密码套件则会不同。不同算法选择的密码套件,其采用的加密算法不同的。你原本是RSA类型的证书,结果你配置的却是优先ECC的密码套件,那么将会导致访问失败。
5.2.2、响应“安全合规”的密码套件及其配置顺序
概念:
◆安全合规
◆Apple ATS合规:
注意
需要配置符合 PFS 规范的加密套餐,目前推荐配置:
ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4
需要在服务端 TLS 协议中启用 TLS1.2,目前推荐配置:
TLSv1 TLSv1.1 TLSv1.2
Apple ATS(Accessory Test System)是苹果公司推出的一种测试系统,用于测试MFi认证的配件和附件。该测试系统由苹果公司自主研发,用于测试各种与苹果设备兼容的配件和附件,如耳机、充电器、数据线等。ATS系统采用了一系列的测试程序和测试设备,以确保配件和附件的质量和兼容性符合苹果公司的标准和规范。通过ATS系统的测试,厂家可以确保其产品符合苹果公司的要求,并获得MFi/CarPlay认证。ATS系统可以进行多种测试,包括连接性测试、功耗测试、兼容性测试、安全性测试等。测试过程中,ATS系统会自动化地运行测试程序,进行各种测试,同时记录和分析测试数据,以便对测试结果进行评估和分析。ATS系统可以帮助厂家提高产品的质量和性能,并确保其与苹果设备之间的兼容性。同时,ATS系统也是苹果公司对比如MFi/CarPlay等第三方认证产品的一种保障,确保其符合苹果公司的标准和规范,为消费者提供高品质的周边配件和附件。
除了上述介绍的功能,ATS系统还具有以下特点:多样化的测试项:ATS系统可以进行多种测试,包括连接性测试、功耗测试、兼容性测试、安全性测试等,以确保配件和附件的质量和兼容性符合苹果公司的标准和规范。自动化测试:ATS系统可以自动化地运行测试程序,进行各种测试,同时记录和分析测试数据,以便对测试结果进行评估和分析。这种自动化测试方式可以提高测试的效率和精度。可扩展性:ATS系统支持多种不同的测试夹具和测试模块,可以满足不同类型的配件和附件测试需求。同时,ATS系统还支持自定义测试程序,以满足厂家特定的测试要求。易于使用:ATS系统具有友好的用户界面和操作流程,可以方便厂家进行测试操作和测试数据的分析和评估。
PFS规则是指"Path Finding System"的规则,即路径寻找系统的规则。在计算机科学领域中,PFS规则是一种用于解决路径搜索问题的算法规则。它被广泛应用于人工智能、网络路由、图形处理等领域。在密码学领域,前向保密FS(有时也称为"完全前向保密"PFS——perfect forward secrecy)是一种协议功能,可实现不依赖服务器私钥的安全对话,要求一个密钥只能访问由它所保护的数据,用来产生密钥的元素一次一换,不能再产生其他的密钥,一个密钥被破解,并不影响其他密钥的安全性。对于不前向保密的密码套件,可以恢复服务器的私钥的人就可以解密所有较早记录的加密对话(也就是可以先大量记录密文,再解密,比如您的证书到期后没有正确销毁,它的私钥就能用来解密非PFS的密文)。您需要支持ECDHE套件,以便通过现代网络浏览器实现前向保密。为了支持更广泛的客户,您还使用 DHE 套件作为 ECDHE 后备。避免 RSA 密钥交换,除非绝对必要,否则影响效率。
过时的加密原语必须避免:ADH(匿名 Diffie-Hellman套件,不提供身份验证);NULL (密码套件不提供加密);aNULL(导出密码套件在连接中协商时不安全,但也可以针对更喜欢更强大的套件(FREAK攻击)的服务器使用;RC4 (是不安全的);MD5(弱密码(通常为 40 和 56 位)的套件使用可以轻松破坏的加密));3DES (缓慢而虚弱)
◆PCI DSS合规:
全称Payment Card Industry Data Security Standard,支付卡行业数据安全标准,是由PCI安全标准委员会制定,力在使国际上采用一致的数据安全措施。
最晚2018年6月30号禁用早期SSL*/TLS1.0,并实施更安全的加密协议(TLS v1.1或更高版本,强烈建议使用TLS v1.2)以满足PCI数据安全标准的要求,从而保护支付数据。
◆配置方法参考(注意您的证书算法选择):
◆以RSA和ECDSA键为基础的标准TLS套件名称向前加密配置,作为起点:
(这是一个通用列表,并不是所有系统(特别是较旧的)支持所有套件,建议在分段环境中测试TLS配置。)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
◆openssl环境向前加密:上述示例配置使用标准 TLS 套件名称。一些平台使用非标准名称; 有关详细信息,请参阅您的操作系统平台文档。例如,以下套件名称将与OpenSSL 一起使用:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
5.2.3、密码套件配置案例
比如,在我的Windows Server 2012 R2服务器上,配置的密码套件:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256_P384,TLS_RSA_WITH_AES_128_GCM_SHA256