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证书?

百度、谷歌都支持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应用程序。

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

EV 代码签名证书

EV 代码签名证书

EV代码签名证书是不仅具有普通内核代码签名证书的所有功能,而且还采用更加严格的国际标准扩展验证(EV验证),并具有严格的证书私钥保护机制的新型安全证书。 EV代码签名证书采用 USB Key来保护签名证书的私钥,以防止证书被非法盗用,确保签名证书安全。

EV代码签名证书执行国际标准组织CA/浏览器论坛和微软规范的严格身份验证标准,验证申请人身份后签发,主要用于软件开发者对各种软件和代码进行数字签名。因为已经通过严格的微软认证,不仅使得签名证书大有好处,还增添了其实用性。

签发EV代码签名证书有以下好处

  • 证明代码开发者真实身份
  • 保护代码完整性及来源可信性,确保软件开发商开发的代码不被病毒、恶意代码和间谍软件所侵害
  • 为开发者建立一个良好的声誉,减少系统的用户信任警告信息
  • 使软件开发商安全快速地通过网络发布软件

签发EV代码签名证书有以下用途

  • 支持Windows 8和Windows8.1立刻获得信用
  • 支持IE9、10和11立刻获得信用
  • 支持Window 10 的内核驱动签名,以确保Win10操作系统的安全。并兼容Windows Mobile、标准的代码签名签名、内核签名、Office签名、VBA签名、Adobe签名。
  • 支持 Windows内核代码 .sys, .cat, .exe, .dll, .cab, .ocx( ActiveX )等文件数字签名
  • 支持 Windows 硬件认证,可以用它建立Windows开发人员中心硬件仪表板账号

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

phpStudy SSL证书部署指南

第1步 申请SSL证书

phpStudy是一个PHP调试环境的程序集成包。首先,确保你的apache编译了ssl模块,这是支持ssl证书必要的条件(如果没有,请编译,打开phpstudy——设置——PHP模块扩展——php-openssl前面勾选上)。如下图:

phpstudy SSL证书
准备好SSL证书,如果还没有购买,请联系易维信,CA(CA-证书颁发机构,比如Symantec(VeriSign)、GeoTrust、Thawte、GlobalSign等)以电子邮件的形式把证书发送给客户。复制嵌入邮件内容中的SSL证书信息,然后粘贴到Txt文本编辑器(比如:Notepad或vi) : 包含“—–BEGIN CERTIFICATE—–”“—–END CERTIFICATE—–”确保有5个破折号(—–)在BEGIN CERTIFICATE 和 END CERTIFICATE的两侧,确保没有空格,多余的换行符或其他无意中加入的字符。然后保存SSL证书文件(比如:ssl_certificate.crt文件(名称可以任意,后缀一般为*.crt或*.cer))。

第2步 :配置SSL证书

1、进入到apache目录下,httpd.conf找到#LoadModule ssl_module modules/mod_ssl.so,去掉前面的注释符,使得ssl模块生效(如果该模块已去掉注释,请不用操作)。

2、找到网站配置文件vhosts.conf,一般在如下路径:D:\phpStudy\Apache\conf,按照80的配置,另起一个VirtualHost443,如下所示:

第3步 检查测试

重启apache(有可能报错,看一下443端口是否被防火墙拦截或被占用),apache正常重启后,在浏览器里面输入https://yourdomain.com就能看到安全锁出来啦。小编提醒您:备份好您的证书!大家在部署的时候尽量找准自己的apache下的路径。

为什么要购买 EV SSL证书?

扩展验证和 SSL 安全

事实证明,拥有知名品牌的企业使用 Extended Validation (EV) SSL Certificates 可以有效防御网页仿冒骗局。对于任何在线企业,使用带有 EV 的 SSL 都会大幅提高经济效益。在线购物者更有可能将信用卡和/或其他机密财务信息输入具有 SSL EV 绿色地址栏的网站。

网页仿冒和在线欺诈摧毁了客户的信任

对身份信息窃取的担心以及浏览器警告消弱了个人用户的信心,即使在安全的网页上个人用户也感觉不安。

为了重塑信任,站点所有者需要轻松可靠的方式向客户证明与之进行交易是安全的,他们名副其实。证书颁发机构和互联网浏览器供应商共同确立了 SSL Certificates 的 EV 标准。

绿色地址栏通过扩展验证恢复信任

EV SSL Certificate 可以让客户更加确信:他们在与信任的网站进行交易,网站的信息都是安全的。EV SSL Certificate 可以触发高级别安全网络浏览器在绿色地址栏中显示贵公司的名称,以及颁发该证书的证书颁发机构的名称。证书颁发机构采用经过审核的严格身份验证方法,加上浏览器对显示的内容加以控制,因此使网页仿冒者和造假者难以劫持您的品牌和客户。

为何要采用赛门铁克EV SSL?

赛门铁克Symentec 引领了扩展验证的开发,截止 2012 年 1 月,颁发的 EV SSL Certificates 数量比其他任何证书机构所颁发的都要多。* 我们严格的身份验证实践树立了在线身份信息保证标准,并由 KPMG 审核。对搜索和基础架构的持续投资帮助赛门铁克在该行业中保持了高标准的实践,可以提前防御日益演变的安全风险。 购买网址:https://shop.evtrust.com