HTTPS -ECC证书

HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能,可以有效防止数据被监听或篡改,还能抵御 MITM(中间人)攻击,点击了解更多Https 加密原理。TLS 在实施加密过程中,需要用到非对称密钥交换和对称内容加密两大算法。

对称内容加密强度非常高,加解密速度也很快,只是无法安全地生成和保管密钥。在 TLS 协议中,应用数据都是经过对称加密后传输的,传输中所使用的对称密钥,则是在握手阶段通过非对称密钥交换而来。常见的 AES-GCM、ChaCha20-Poly1305,都是对称加密算法。

非对称密钥交换能在不安全的数据通道中,产生只有通信双方才知道的对称加密密钥。目前最常用的密钥交换算法有 RSA 和 ECDHE:RSA 历史悠久,支持度好,但不支持 PFS(Perfect Forward Secrecy);而 ECDHE 是使用了 ECC(椭圆曲线)的 DH(Diffie-Hellman)算法,计算速度快,支持 PFS。

存在问题

并不是所有浏览器都支持 ECDHE 密钥交换,也就是说 ECC 证书的兼容性要差一些。例如在 Windows XP 中,使用 ECC 证书的网站只有 Firefox 能访问(Firefox 的 TLS 自己实现,不依赖操作系统);Android 平台中,也需要 Android 4+ 才支持 ECC 证书。

好消息是,Nginx 1.11.0 开始提供了对 RSA/ECC 双证书的支持。它的实现原理是:分析在 TLS 握手中双方协商得到的 Cipher Suite,如果支持 ECDSA 就返回 ECC 证书,否则返回 RSA 证书。

也就是说,配合最新的 Nginx,我们可以使用 ECC 证书为现代浏览器提供更好的体验,同时老旧浏览器依然会得到 RSA 证书,从而保证了兼容性。

如何申请ECC 证书

如果你的 CA 支持签发 ECC 证书,使用以下命令生成 CSR(Certificate Signing Request,证书签名请求)文件并提交给提供商,就可以获得 ECC 证书:

openssl ecparam -genkey -name secp256r1 | openssl ec -out ecc.key

openssl req -new -key ecc.key -out ecc.csr

以上命令中可供选择的算法有 secp256r1 和 secp384r1,secp521r1 已被 Chrome 和 Firefox 废弃。

我目前在用的 Let’s Encrypt,也支持签发 ECC 证书。我使用了 acme.sh 这个小巧的工具来签发证书,指定 -k ec-256 就可以将证书类型改为 ECC:

“/root/.acme.sh”/acme.sh –issue –dns dns_cx -d imququ.com -d www.imququ.com -k ec-256

目前 Let’s Encrypt 只提供 RSA 中间证书,官方预计会在 2017 年 3 月底提供 ECC 中间证书(via)。

如何使用

有了 RSA/ECC 双证书之后,还需要安装 Nginx 1.11.x。

一切准备妥当后,将证书配置改为双份即可:

ssl_certificate     example.com.rsa.crt;

ssl_certificate_key example.com.rsa.key;

ssl_certificate     example.com.ecdsa.crt;

ssl_certificate_key example.com.ecdsa.key;

测试环境使用 Cloudflare 提供的 Cipher Suites 配置,在 Nginx 中配置了双证书并重启,用 Chrome 测试发现仍然没有采用 ECC 证书。这是为什么呢?

# https://www.evtrust.com/cloudflare/sslconfig/blob/master/conf

ssl_ciphers                 EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;

ssl_prefer_server_ciphers   on;

研究发现,Chrome 与服务端协商到的 Cipher Suites 是 ECDHE-RSA-AES128-GCM-SHA256,来自于 ssl_ciphers 配置中的 EECDH+AES128 这部分。我们通过 openssl 工具看一下 EECDH+AES128 具体包含哪些 Cipher Suites:

openssl ciphers -V ‘EECDH+AES128’ | column -t

0xC0,0x2F  –  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)  Mac=AEAD

0xC0,0x2B  –  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)  Mac=AEAD

0xC0,0x27  –  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA256

0xC0,0x23  –  ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA256

0xC0,0x13  –  ECDHE-RSA-AES128-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA1

0xC0,0x09  –  ECDHE-ECDSA-AES128-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA1

可以看到,使用 RSA 做为签名认证算法(Au=RSA)的加密套件排到了前面,导致 Nginx 作出了错误判断。

知道原因就好办了,将这段配置改为 EECDH+ECDSA+AES128:EECDH+aRSA+AES128,再看一下:

openssl ciphers -V ‘EECDH+ECDSA+AES128:EECDH+aRSA+AES128’ | column -t

 

0xC0,0x2B  –  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)  Mac=AEAD

0xC0,0x23  –  ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA256

0xC0,0x09  –  ECDHE-ECDSA-AES128-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA1

0xC0,0x2F  –  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)  Mac=AEAD

0xC0,0x27  –  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA256

0xC0,0x13  –  ECDHE-RSA-AES128-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA1

这下就没问题了。

并不是所有加密套件都需要把 ECDSA 和 aRSA 分开写,例如 EECDH+CHACHA20 就不需要,ECDSA 默认就在前面:

openssl ciphers -V ‘EECDH+CHACHA20’ | column -t

0xCC,0xA9  –  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=ChaCha20-Poly1305  Mac=AEAD

0xCC,0xA8  –  ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2  Kx=ECDH  Au=RSA    Enc=ChaCha20-Poly1305  Mac=AEAD

最终,我的 Cipher Suites 配置如下,供参考:

ssl_ciphers                EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5;

Symantec EV 代码签名证书

Symantec(VeriSign) Extended Validation(EV) Code Signing Certificates
Symantec EV 代码签名证书具有标准代码签名证书的所有功能,能签名内核代码,不同的是采用更加严格国际标准扩展验证(Extended Validation:EV验证),并且有严格的证书私钥保护机制–必须采用 USB Key来保护签名证书的私钥,以防止证书被非法盗用,确保代码签名证书安全。

代码签名证书能验证软件的来源和代码的完整性,使用者也会知道该代码程序自发布后未遭到非法窜改,从而对软件开发商产生高度信赖感,保护了软件开发商的利益,使得软件开发商能安全地快速地通过互联网发布软件。

在Windows 10中标准代码签名证书无法用于内核模式驱动签名,必须用EV 代码签名证书签名。Symantec EV代码签名证书在标准代码签名证书已有的优点和基础上,增加了更加严格的开发商的身份审核,并将证书存储在USB key中,杜绝了证书被盗用的风险;能帮助已经签名的代码在Windows SmartScreen®中快速建立自己的声誉,并减少系统的用户信任警告信息。

Symantec(VeriSign) EV代码签名证书特点
● 最严格的企业身份信息扩展验证(EV),材料齐全,3~5个工作日审核验证颁发证书;

● 支持 Windows 32位和64位用户模式下 .exe, .dll, .cab, .ocx( ActiveX )等应用程序文件数字签名 ;

● 支持 Windows (包括Windows 10)32位和64位内核模式下 .sys, .cat,等驱动程序文件数字签名 ;

● 提供最为严格的证书私钥保护机制,比如通过USB Key保护证书私钥;

● 支持 Windows 硬件认证,可以用它建立Windows开发人员中心硬件仪表板账号;

● 可消除 Internet Explorer 以及 Windows 操作系统中弹出的「不明发行商」;支持Silverlight 4应用程序;

● 保护您的代码的完整性 (未被篡改或破坏 );

● 免费提供时间戳服务,确保已经签名的代码长期有效 ;

● 代码签名证书在有效期内可以不限次数对软件进行签名;

● 支持SHA)1 和 SHA 2 签名算法;

● 相对其他代码签名供应商,支持更多的平台,比如:基于云和移动应用平台;

● 严格地实行每年一次的KPMG(毕马威)审计;

Symantec(VeriSign) EV 代码签名证书和标准代码签名证书对比如下:

Symantec(VeriSign) 代码签名证书 5大理由

1、可支持更多平台,让您最大限度地提高软件分发量,从而提供您的收入
2、依靠全球最权威、最受信任的证书颁发机构(CA)减少安全警告
3、保护您的代码完整性和您的信誉
4、通过简化安全保障,加快产品上市速度
5、确保让客户获得安全可靠的体验

友情提醒
Symantec EV 代码签名证书仅限于单位用户申请,个人不能申请EV 代码签名证书 ,Symantec EV 代码签名证书需要邮寄,申请周期比较长。任何用户都不得使用Symantec EV 代码签名证书为间谍软件(Spyware)、流氓软件和黑客软件等进行数字签名,否则,一经举报和查实,我们有权立刻吊销此证书,不退款,而且还会配合公安部门和其他机构追究可能由此带来的一切法律责任。

文章来源易维信官网: http://www.evtrust.com/symantec/ev-code-signing.html

微软WHQL提交需要使用EV代码签名证书

微软曾经宣布每个WHQL提交的测试包都必须使用EV代码签名证书进行签名,没有EV代码签名的提交包将会被微软拒绝。微软最初提出这样的要求主要是出于账户安全的考虑,防止账号被滥用发布恶意驱动。

但是,目前微软收到许多WHQL合作伙伴反馈,这一要求带来了非常多的不方便。每个提交都使用EV代码签名证书使得很多大公司无法适应。一般来说,CA只会给一个公司颁发一个EV代码签名证书Ukey, 而在大的PC 硬件公司每个部分可能都需要提交WHQL。 在一些超大型公司里往往无法确认这个UKey到底在哪个部门;大公司各部门的资源调动需要走一定的流程。也建议这些公司联系易维信(http://www.evtrust.com)同时申请不同CA的EV代码签名证书,例如DigiCert EV 代码签名证书,GlobalSign EV 代码签名证书或者 Symantec 赛门铁克 EV 代码签名证书。

为了解决合作伙伴的这些烦恼,微软不再要求每个提交都使用EV代码签名证书。但在每个sysdev账户还是必须要有至少有一个EV代码签名证书,主要是做建账户的身份验证。当然,出于安全考虑微软还是鼓励伙伴们使用EV代码签名证书来做WHQL提交。

ssl证书安装-苹果ATS

自2017年1月1日起,根据苹果要求,所有 iOS 应用必须使用 ATS(App Transport Security),即 iOS 应用内的连接必须使用安全的 HTTPS 连接。同时,苹果要求使用的不仅是一个简单的 HTTPS 协议连接,而且必须要满足 iOS9 中的新增特性。

ssl证书安装,苹果ATS

本文介绍苹果ATS环境ssl证书安装苹果 ATS 针对 HTTPS 协议包含以下四个方面的要求:

证书颁发机构的要求

  • 建议您使用 DigiCert、Symantec、GeoTrust 品牌的 OV 型及以上数字证书,易维信出售的所有ssl都符合要求。
  • 对于个人用户,建议使用 DV 型数字证书,不推荐使用免费证书。
  • CFCA 品牌的数字证书只在最新的苹果设备上才支持,因此不推荐选择 CFCA 品牌。

证书的哈希算法和密钥长度的要求

哈希算法

上述推荐的证书品牌中是使用的哈希算法都是 SHA256 或者更高强度的算法,符合 ATS 的要求。

密钥长度

  • 如果您选择使用系统创建 CSR 的方式,系统生成的密钥采用的是 2048 位的 RSA 加密算法,完全符合 ATS 的要求。
  • 如果您选择自己创建CSR文件,请确保使用 2048 位或以上的 RSA 加密算法。

传输协议的要求

传输协议必须满足 TLS1.2。需要在 Web 服务器上开启 TLSv1.2,通常要求:

  • 基于 OpenSSL 环境的 Web 服务器,需要使用 OpenSSL 1.0 及以上版本,推荐使用 OpenSSL 1.0.1 及以上版本。
  • 基于 Java 环境的 Web 服务器,需要使用 JDK 1.7 及以上版本。
  • 其他 Web 服务器,除 IIS7.5 以及 Weblogic 10.3.6 比较特殊外,只要 Web 服务版本满足,默认均开启 TLSv1.2。

详细 Web 服务器配置要求说明如下:

  • Apache 、 Nginx Web 服务器需要使用 OpenSSL 1.0 及以上版本来支持 TLSv1.2。
  • Tomcat 7 及以上版本 Web 服务器需要使用 JDK 7.0 及以上版本来支持 TLSv1.2。
  • IIS 7.5 Web 服务器默认不开启 TLSv1.2,需要修改注册表以开启 TLSv1.2。
    下载并导入 ats.reg 注册表脚本后,重启(或注销)服务器,即可使 TLSv1.2 生效。
  • IBM Domino Server 9.0.1 FP3 Web 服务器支持 TLSv1.2。根据 ATS 要求,建议使用IBM Domino Server 9.0.1 FP5 版本。更多信息请参考:
  • IBM HTTP Server 8.0 及以上版本支持 TLSv1.2。根据 ATS 要求,建议使用 IBM HTTP Server 8.5 及以上版本。
  • Weblogic 10.3.6 及以上版本 Web 服务器需要使用 Java7 及以上版本来支持TLSv1.2。
    注意:Weblogic 10.3.6 中存在多个 SHA256 兼容问题,建议最低使用 Weblogic 12 版本,或为 Weblogic 10.3.6 配置前端 Apache 或 Nginx 的 HTTPS 代理或 SSL 前端负载。
  • Webspere V7.0.0.23及以上版本、Webspere V8.0.0.3及以上版本、Webspere V8.5.0.0 及以上版本支持 TLSv1.2。关于如何配置 Webspere 服务器支持TLSv1.2,请参考 Configure websphere application server SSL protocol to TLSv1.2

签字算法的要求

签字算法必须满足如下算法要求:

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

配置示例

以下通过举例方式说明不同 Web 服务器的 ATS 协议及加密套件应该如何配置:注意: 示例中只列举了与 ATS 协议有关的属性,请不要完全复制以下配置用于您的实际环境。

Nginx 配置文件片段

Nginx 配置文件中 ssl_ciphers 及 ssl_protocols 属性与 ATS 协议有关。

  1. server {
  2. ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
  3. ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  4. }

Tomcat 配置文件片段

Tomcat 配置文件中的 SSLProtocol 及 SSLCipherSuite 属性与 ATS 协议有关。

  1. <Connector port="443" protocol="HTTP/1.1" SSLEnabled="true"
  2. scheme="https" secure="true"
  3. ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  4. SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"
  5. SSLCipherSuite="ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4" />

IIS 系列 Web 服务器的配置方法请参考 Enabling TLS 1.2 on IIS 7.5 for 256-bit cipher strength。您也可以使用 IIS Crypto 可视化配置插件进行配置。

ATS 检测工具

您可在苹果电脑中使用系统自带的工具进行ATS检测,执行以下命令即可:

nscurl --ats-diagnostics --verbose 网址

什么是驱动数字签名

什么是驱动数字签名—驱动没有数字签名的解决方案

如我们日常签名一样,数字签名是一种签章,有如我们的文件加盖公章一样。随着科技的发展我们有越来越多的电子档文件需要身份界定,所有权确定。由此,就有了只有文件的签发者可以产生而其他人无法仿制由一个数字串组成的电子签章。

驱动数字签名是指运用在驱动上的数字签名。有数字签名的驱动操作系统会认为它是安全,稳定,有版权的驱动。安装的时候会明显更顺畅。不建议大家安装没有数字签名的驱动程序。

驱动没有数字签名的情况如图所示:notsign1

notsign2

如果您是驱动最终用户,遇到驱动未数名的情况。您可以联系这款驱动的供应商(一般也是设备的生产者)。如果您是驱动发行机构或者是硬件产品生产商,那您可以选择如下几种方式获得数字签名:

第一种,申请Windows发行的驱动数字签名。

这种驱动数字签名是在windows操作系统下使用最多,最有效,最稳定的驱动数字签名。在安装过程中非常的流畅,没有任何敬告提示。是微软windows操作系统最欢迎的驱动数字签名。

要获得Windows发行的驱动数字签名需要将硬件和驱动通过微软的WHQL认证,认证完成后微软会下发签有” Microsoft Windows Hardware Compatibility Publisher”驱动catalog文件,将此文件附在驱动的同一目录下驱动就有了数字签名。

Windows数字签名是驱动开发商和硬件生产商首选的驱动数字签名。

Microsoftsign驱动数字签名
驱动数字签名

第二种, 用代码签名证书签发驱动数字签名。

uassoft-sign驱动数字签名
驱动数字签名

这种驱动数字签名主要是利用CA机构如symantec颁发的代码签名证书来对驱动进行签名。推荐购买EV 代码签名证书EV 代码签名证书具有标准代码签名证书的所有功能,能签名内核代码,不同的是采用更加严格国际标准扩展验证(Extended Validation:EV验证),并且有严格的证书私钥保护机制–必须采用 USB Key来保护签名证书的私钥,以防止证书被非法盗用,确保代码签名证书安全。这种签名运用范围十分广泛,EV 代码签名证书除了对驱动进行签名以外还可以对其他类型文件如exe, MSI, dll, cab等文件进行签名。这种驱动数字签名相比windows发行的数字签名级别要低,安装时会出现对话框确认,但可以在windows 64位系统上成功安装。由于这种数字签名成本较低,而且不限制签名次数,也被广泛采用。

易维信(https://www.evtrust.com)了解到EV代码签名证书的重要性后,开始了EV代码签名证书业务。易维信致力于提供高效专业标准的为代码开发者提供签发EV代码签名证书服务,并且承诺我们的报价远低于同行,点击官网产品介绍,联系易维信销售

 

SSL证书的区别

各种类型SSL数字证书的区别

用于网站或应用程序的 SSL/TLS 证书,当前主要分为DV SSL、OV SSL、EV SSL三种类型的证书。下面文详细介绍SSL证书的区别

  • DV SSL数字证书部署在服务器上后,用户浏览器访问网站时,展示如下:DV SSL
  • OV SSL数字证书部署在服务器上后,用户浏览器访问网站时,展示如下:OV SSL
  • EV SSL数字证书部署在服务器上后,用户浏览器访问网站时,展示如下:EV SSL

SSL证书的区别简述如下,

数字证书 DV SSL OV SSL EV SSL
用户建议 个人 组织、企业 大型企业、金融机构
公信等级 一般
认证强度 网站真实性 组织及企业真实性 严格认证
安全性 一般
可信度 常规 高(地址栏绿色)

PS.易维信出售的Symantec证书,在原有OV、EV基础上,推出了增强型OV、增强型EV证书。增强型与专业版OV及高级版EV的区别主要在于,增强型OV、增强EV支持ECC椭圆加密算法。有研究表示160位的椭圆密钥与1024位的RSA密钥安全性相同。更多的选购指南请参考:如何选购SSL证书?

如何选购SSL证书?

百度、谷歌都支持https加密搜索,尤其是最近一段时间,百度对https网站的照顾更是超乎常人,比如百度将优先收录https站点。那么我们该如何选购SSL证书呢?易维信从3个方面为大家分享如何选购SSL证书

SSL证书类型的选择

  • 如果您的网站主体是个人(即没有企业营业执照),只能申请免费型或 DV 型数字证书。
  • 对于一般企业,建议购买 OV 及以上类型的数字证书。对于金融、支付类企业,建议购买 EV 型证书。为什么要购买 EV SSL证书?
  • 移动端网站或接口调用,建议您使用 OV 及以上类型的证书。

注意: DigiCert 、Symantec 品牌的 EV 型证书有服务器 IP 限制。如果您的一个域名有多个主机 IP,建议您购买多张数字证书。

SSL证书品牌选择

  • 各数字证书品牌兼容性从强到弱的顺序: DigiCert > Symantec > GlobalSign > GeoTrust > Comodo。
  • 移动端网站或接口调用相关的应用,建议您选择 DiGiCert 、Symantec 品牌

    SSL证书保护域名数量

    • 一个域名: 该数字证书只能配置一个具体的域名。
    • 多个域名: 该数字证书可配置多个具体的域名。这些域名可以是一个顶级域也可以是非顶级域名,例如 www.evtrust.comhttp://www.evtrust.net等。
    • 通配符域名: 该数字证书可配置一个通配符域名。通配符域名一般格式为 *.evtrust.com。通配符域名仅支持同级匹配,例如绑定 *.evtrust.com 通配符域名的数字证书,支持 p1.evtrust.com,但不支持 p2.1.evtrust.com。如果你需要支持 p2.p1.evtrust.com的通配符域名数字证书,则还需要购买一张 *.p1.evtrust.com的通配符域名证书。

    注意

    • 通配符域名的数字证书中,仅根域名包含域名主体本身。例如:
      • *.evtrust.com的通配符域名数字证书包含了 evtrust.com。
      • *.p1.evtrust.com的通配符域名数字证书不包含 p1.evtrust.com。
    • 具体的域名中如果填写的是 www 域名,则包含了主域名本身。例如:
      • www.evtrust.com域名绑定的数字证书包含了 evtrust.com。
      • www.p1.evtrust.com域名绑定的数字证书不包含 p1.aliyun.com。
    • 您的数字证书一旦颁发后,将无法修改域名信息等。

设置DNS CAA记录,HTTPS更安全!

2017年3月CAB论坛(一个全球证书颁发机构和浏览器的技术论坛)发起了一项关于对域名强制检查CAA的一项提案的投票,获得187票支持,投票有效,提议通过。

提议通过后,将于2017年9月8日根据Mozilla的Gervase Markham提出的检查CAA记录作为基准要求来实施。

什么是DNS CAA?

证书颁发机构授权(全称Certificate Authority Authorization,简称CAA)为改善PKI(Public Key Infrastructure:公钥基础设施)生态系统强度,减少证书意外错误发布的风险,通过DNS机制创建CAA资源记录,从而限定了特定域名颁发的证书和CA(证书颁发机构)之间的联系。

CAA是保护域名免受钓鱼的安全措施,网站运营商可以通过该措施来保护域名免于被错误的签发SSL证书。在2013年由RFC 6844进行了标准化,允许CA“降低意外证书错误的风险”。默认情况下,每个公共CA都可以为公共DNS中的任何域名颁发证书,只要它们验证对该证书的域名控制权。这意味着,如果在许多公共CA的验证过程中有任何一个错误,每个域名都可能受到影响。CAA为域名持有者提供了降低风险的途径。

而DNS Certification Authority Authorization(DNS证书颁发机构授权)是一项借助互联网的域名系统(DNS),使域持有人可以指定允许为其域签发证书的数字证书认证机构(CA)的技术。它会在 DNS 下发 IP 的同时,同时下发一条资源记录,标记该域名下使用的证书必须由某证书颁发机构颁发。

CAA记录格式

根据规范(RFC 6844),CAA记录格式由以下元素组成:

CAA <flags> <tag> <value>

名词解释:

CAA:DNS资源记录类型

<flags>:认证机构限制标志

<tag>:证书属性标签

<value>:证书颁发机构、策略违规报告邮件地址等

<flags>定义为0~255无符号整型,取值:

Issuer Critical Flag:0

1~7为保留标记

<tag>定义为US-ASCII和0~9,取值:

CA授权任何类型的域名证书(Authorization Entry by Domain) : issue

CA授权通配符域名证书(Authorization Entry by Wildcard Domain) : issuewild

指定CA可报告策略违规(Report incident by IODEF report) : iodef

auth、path和policy为保留标签

<value>定义为八位字节序列的二进制编码字符串,一般填写格式为:

[domain] [“;” * 参数]

设置CAA资源记录

需要当限制域名evtrust.com及其子域名可由机构GlobalSign颁发不限类型的证书,同时也可由DigiCert(digicert.com)颁发证书通配符,其他一律禁止,并且当违反配置规则时,发送通知邮件到example@example.com。

配置如下(为便于理解,二进制值值已经过转码,下同):

evtrust.com. CAA 0 issue “globalsign.com”

evtrust.com. CAA 0 issuewild “digicert.com”

evtrust.com. CAA 0 iodef “mailto:example@example.com”

子域名:如果子域名有单独列出证书颁发要求,例如:

evtrust.com. CAA 0 issue “globalsign.com”

shop.evtrust.com. CAA 0 issue “digicert.com”

那么,因子域策略优先,所以只有DigiCert为可以域名shop.evtrust.com颁发证书。

通配符:此外,CAA记录也可用于将通配符证书的颁发权限指定仅限一家CA。

domain.com. CAA 0 issuewild ” http://globalsign.com”

如果不想手动设置CAA记录,也可以通过自动生成工具生成一段CAA记录,发布到DNS系统中。

CAA记录查询

CAA记录是一个相对较新的资源记录,目前很多工具并不支持。以dig为例,不能适用其标准语法。若需要查询CAA记录,dig时需要直接指定RR类型(type257)。

例如:

$ dig google.com type257

; <<>> DiG 9.8.3-P1 <<>> google.com type257

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64266

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;google.com. IN TYPE257

;; ANSWER SECTION:

google.com. 86399 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D

;; Query time: 51 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Thu Dec 29 21:07:18 2016

;; MSG SIZE rcvd: 59

该查询的输出是二进制编码记录,需要转码才能知道具体CAA策略。

最后

目前,国内大多数的DNS解析商均不支持CAA记录解析。但随着HTTPS逐步取代HTTP的趋势,使用SSL证书升级HTTPS的解决方案将被大量采纳。为了避免HTTPS证书的错误签发,相信不久的将来,CAA记录解析将被兼容。

SSL证书吊销检查

虽然证书吊销状态在不断变化,并且用户代理对证书吊销的行为差异很大,但作为服务器,要做的就是尽可能快地传递吊销信息。实际操作中转化为以下这些规则。

  • 使用带OCSP信息的证书
    OCSP被设计用于提供实时查询,允许用户代理只请求访问网站的吊销信息。因此查询简短而快速(一个HTTP请求)。相比之下CRL是一个包含大量被吊销证书的列表。一些用户代理只有当OCSP信息不可用的时候才下载CRL,这种情况下浏览器与你的网站的通讯将被暂停,直到CRL下载完成。几十秒的延迟都不少见,尤其是通过慢速的网络连接时(想想移动设备)。
  • 使用具有快速且可靠的OCSP响应程序的CA
    不同CA之间的OCSP响应程序性能也有所不同。缓慢和错误的OCSP响应程序会潜在地导致性能下降,这个现实被隐藏了很长一段时间。在你向CA提交之前先检查他们的历史OCSP响应程序。
    另一个选择CA的标准是它更新OCSP响应程序的速度。为了避免网站错误,你希望自己的证书一被颁发就加入到OCSP响应程序中。令人费解的是,有些CA对于新证书的OCSP更新拖延很久,这个期间OCSP响应程序都会返回错误。
  • 部署OSCP stapling
    OCSP stapling是一种允许在TLS握手中包含吊销信息(整个OCSP响应)的协议功能。启用OCSP stapling之后,通过给予用户代理进行吊销检查的全部信息以带来更好的性能。OCSP stapling增加握手大约450字节,会让握手略微变慢,但可以省去用户代理通过独立的连接获取CA的OCSP响应程序来查询吊销信息。
    OCSP响应大小因签发CA的实际部署不同而不同。与最终实体证书(正在检查吊销的)具有相同CA签名的OCSP响应会比较简短。因为用户代理已经有签发CA的证书,OCSP响应可以只包含吊销状态和签名。
    一些CA喜欢使用不同的证书对OCSP响应进行签名。因为用户代理事先并不知道其他证书,CA必须将它们包含在每个OCSP响应里面。这会给OCSP响应略微增加超过1 KB的大小。

注意:当浏览器跳过吊销状态检查时,虽然会获得更好的性能,但也面临安全风险。EV证书始终检查吊销状态以提供更好的安全性。DV证书不总是检查吊销状态,可能有轻微的性能优势。这个问题可以通过OCSP stapling让两种类型的证书都有相同的性能来解决。

为什么经常遇到无效证书?

我们经常遇到无效证书,而且无效证书非常流行,很难找到没有遇到过这些证书的人。以下是几个根本原因。

  • 配置错误的虚拟主机
    今天,多数网站只在端口80上运行且不使用加密。一个常见的配置错误是让这些明文网站和在443端口上使用加密的其他网站使用同一个IP地址。这样一来,如果用户尝试使用https访问明文网站的话,就会导致错误的发生:证书和域名不匹配。
    这个问题的部分原因是,在技术层面,我们没有一种机制可以使得网站来声明是否支持加密。从这个角度来看,托管明文网站的正确做法是让他们使用关闭了端口443的IP地址。
    在2010年,有数据统计,扫描了19亿个域名,寻找加密网站。扫描的列表包括所有的.com、.net和.org域名。我发现2265万(19%)的安全网站托管在大概200万个IP地址上。在这些安全网站中,只有72万个(3.2%)网站的证书和域名匹配。
    有一个名称正确的证书是一个好的开始,但是这还不够。大概30%的这类证书在2010年的调查中由于其他原因而实际是无效的(不受信)。
  • 域名覆盖范围不足
    在少数场合下,网站管理员购买并部署了证书,但是证书中没有包含全部的网站域名。例如,你在example.com上运行了一个网站,证书可能包括这个域名以及example.com。如果网站还有其他的域名,证书中也需要包含那些域名。
  • 自签名证书和私有CA
    自签名的证书以及私有CA签发的证书不适合在公开场合使用。这类证书无法简单并可靠地与中间人攻击的证书区分开。在我的调查中,大约48%的无效证书是因为这个原因。
    那么为什么人们要使用这类证书?原因有很多:(1)购买、配置和续签证书带来了额外的工作,而且需要持续投入;(2)直到几年前,证书的价格仍比较昂贵;(3)一些人认为公共受信的证书应该是免费的,因而拒绝进行付费购买。然而,最简单的事实是公共受信证书对于公开网站是适合的。
  • 设备使用的证书
    当今,很多设备都有基于Web的管理界面,这些界面要求使用安全通信。当这些设备被制造出来的时候,域名和IP还无法确定,这意味着生产厂商无法安装有效的证书。理论上来讲,最终用户可以自己在设备上安装证书,但是很多这种设备都不常用,因此也就不值得去购买并安装证书。此外,很多设备的管理界面也不允许用户自己配置证书。
  • 过期的证书
    另外一个无效证书产生的重要原因是过期。在我的调查中,57%的无效证书是由于过期导致的。在很多情况下,网站的管理员忘记去续签证书,或者,他们放弃了取得有效证书的想法,但是并没有将老的证书下线。
  • 错误的配置
    另外一个常见的问题是错误的配置。为了让一张证书被信任,每个浏览器都需要建立起一条信任链,从服务器证书到一个可信任的根证书。服务器被要求提供除了根证书之外的整个信任链,但是根据SSL Pulse的数据,大约6%的服务器的证书链不完整。在某些情况下,浏览器可以对此作出变通,但是通常他们并不会这样做。

当谈到用户体验的时候,一个2013年的研究结果显示在39亿个公开的TLS连接中,有1.54%的连接存在证书警告。但是这只是在公开的互联网上的情况,在这里网站一般都会尽量避免警告。在某些特定的场景下(例如内联网或者内部应用),你可以需要每天都需要点击通过证书警告,以便可以访问和工作相关的Web应用程序。

如果您遇到这些无效证书,请联系易维信技术支持