数字签名证书是完全识别发布商的数字证书。它们由符合最低RSA关键长度要求的证书机构颁发。如果对代码有任何更改，则需要发布新的签名。
当应用数字签名时，浏览器和用户知道他们处于安全的应用环境中。数字签名不仅可识别应用程序的来源，还能证明软件的安全性和有效性。如果没有证书，或者数字签名似乎被篡改，用户将收到安全警告，让他们知道软件可能不可信。
这就是为什么有效的数字签名证书对开发人员至关重要。客户不太可能信任没有适当证书的发布商，他们不应该信任。如果没有数字签名证书，代码更改可以毫无警告地进行，用户可以在不知不觉中下载网络罪犯注入的恶意代码，试图窃取其数据。
这意味着，除网站上的SSL/TLS证书外，任何与最广泛接受的根程序一起使用的任何软件应用程序都必须通过数字签名证书进行验证。正如SSL/TLS证书为网站提供信任一样，数字签名通过保护软件、应用程序和驱动程序来提供信任。
SSL2.0和3.0分别在2011年和2015年被Internet Engineering Task Force（也称为IETF）弃用。多年来，在废弃的SSL协议（例如POODLE，DROWN）中一直并将继续发现漏洞。大多数现代浏览器在遇到使用旧协议的Web服务器时，都会显示退化的用户体验（例如，通过URL栏中的挂锁或https或其他安全警告的行）。出于这些原因，您应该禁用服务器配置中的SSL2.0和3.0，而您在它-继续前进，并弃用TLS1.0和TLS1.1。
根据最近的WatchGuard调查，在Alexa前100，000名中，近7%的人仍然支持SSL2.0和/或SSL3.0。因此，这些网站仍然在那里丰富。
CAA是一种安全措施，允许域名所有者在其域名服务器（DNS）中指定哪些CA有权为该域名颁发证书。如果CA收到具有CAA记录的域名证书订单，并且CA未被列为授权发行人，则禁止他们向该域或任何子域颁发证书。
CAA的好处
CAA的好处之一是补充证书透明度（CT）。CT提供机制，帮助域名所有者识别发行后错误签发或经常颁发的域名证书，而CAA可以帮助防止在事实发生之前未经授权的签发。他们一起建立一套比任何一个更好的安全。
CAA还可以帮助已标准化或想要标准化或限制其使用的CA的组织。在CAA之前，组织执行此类策略的方法并不简单，但现在所有CA必须检查CAA记录，这些策略实际上可以由CAS执行。
实施CAA
虽然检查CAA记录是CAs的必修课，但使用CAA对域名所有者来说是可选的。您可以自行决定是否要实施，如果您决定实施，您可以在需要时指定多个CA（请参阅此博客稍后的警告说明）。
以下是CA的处理规则：
无CAA记录：CA可以发布。
CAA记录包括CA：CA可以发布。
CAA记录，但不包括CA：CA不能发布。
CAA支持以下属性：
发行：允许Cas签发证书（包括通配符证书，除非受到发行野生的限制）
发行野生：允许CA签发通配符证书，但不允许签发非通配符证书。
下面是CAA代码的示例，如果您想要授权ert7为example.com签发证书，您将在DNS区域文件中添加：
CAA0发行”ert7.com”
请记住，CAA检查从完整的FQDN开始，并处理到基本域，因此在验证www.a.domain.com的FQDN时，CA将检查：
www.a.domain.com，然后
a.domain.com，然后
domain.com
有关如何添加CAA记录（包括托管DNS的步骤）的详细说明，请参阅我们的相关支持文章。
关于CNAMES
注意事项：根据RFC1912，CNAME记录不允许与任何其他数据共存。在查找CAA记录时，我们将遵循FQDN的上述规则，然后向上走链条，但如果我们遇到CNAME记录，我们将忽略该域的DNSTXT和CAA记录。我们将在CNAME指向的域名上查找CAA记录，而不是在所提供的域名上查找CAA记录。
更新CAA时要谨慎
在创建CAA记录时，请务必谨慎使用。如果您有其他部门获得证书，您需要协调，以确保所有在使用的CA将被添加到您的CAA记录中。由于CAA检查是强制性的，并且导致CA无法覆盖的订单被拒绝，因此DNS管理员不要关闭公司非常重要！此外，如果您使用服务提供商来处理任何托管解决方案，他们可能会使用与您没有直接关系的CA保护这些服务器，因此请小心。
登录网站或门户网站是许多人日常生活的一部分。每次登录其中一个网站时，都会创建一个会话。以最简单的方式，会议被定义为两种系统的交流。这将保持活跃，直到用户结束通信。这可以称为用户启动的会话。
会话的开始对于通过互联网进行任何通信都至关重要。话虽如此，会议劫持的威胁不断出现。本文将讨论什么是会话劫持实际上，它是如何发生的，以及可以做些什么来防止它。
会话劫持是该术语所示。会话中的用户可能会被攻击者劫持，并完全失去对会话的控制，他们的个人数据很容易被窃取。用户开始登录银行网站等会话后，攻击者可以劫持它。
为了劫持会话，攻击者需要对用户的Cookie会话有相当的了解。虽然任何会话都可能被黑客攻击，但在Web应用程序上的浏览器会话中，它更为常见。
攻击者有许多选项来劫持用户的会话，具体取决于攻击者的位置和向量。以下是一些可以劫持会话的方法：
会话劫持的威胁存在由于无状态协议。这些协议有局限性，这就是为什么它们容易受到攻击。
为了保护用户的会话不被劫持，组织可以集成某些加密。这些加密是必要的，以保护您的消费者的会话，并以证书的形式。
会话攻击利用TLS请求压缩比中的数据泄漏。然后，他们就可以访问用户的登录Cookie，这些Cookie可用于劫持用户会话。其中一起事件发生在2012年9月，当时一个名为CRIME的会话劫持者组织破坏了该组织的网站。
CRIME最终通过解密网站设置的HTTPS Cookie并以蛮力验证自己为用户，窃取了大量数据来劫持会话。
为了保护自己在会话中不受劫持，您需要加强Web应用程序中的机制。这可以通过沟通和会话管理来完成。以下是您可以降低会话劫持风险的几种方法：
会话劫持是一个真正的威胁，用户不断面临被破坏的威胁。网站经理可以通过实施安全协议来降低这些风险。这些安全协议主要涉及整个Web应用程序中的深度加密，以关闭攻击者劫持用户会话的所有入口点。
随着在线数据的大幅增长以及越来越多的人每天使用网络，组织必须确保网站的安全。如果不这样做，可能会根据全球数据隐私法规处以巨额罚款。
每个版本的协议之间的差异可能并不大，但如果你比较SSL2.0到TLS1.3，它们之间会有一个峡谷。其核心是，每个版本的概念都是一样的。这只是不同协议完成加密有分歧的连接的任务的方式。
协议的每个新版本都附带了自己的改进和/或新/弃用功能。SSL版本一从未发布，版本二确实存在一些主要缺陷，SSL版本3是第二版的重写和TLS版本1改进了SSL版本3。在TLS1.0和1.1之间，变化很小。TLS1.2带来了一些重大变化，TLS1.3改进和简化了整个流程。
值得注意的是，SSL和TLS仅指客户端和服务器之间的握手。握手实际上并不做任何加密本身，它只是同意一个共享的秘密和类型的加密，将要使用。SSL握手使用端口进行连接。这称为明确连接。443端口是HTTPS的标准端口，但共有65，535个端口，只有少数端口专用于特定功能。
相反，TLS通过协议开始连接。这称为隐式连接。握手的第一步-开始它的行为-被称为客户你好。使用TLS，当握手开始后，通过不安全的通道和连接切换到端口443（或您指定的端口）。
传统上，握手涉及几个往返，因为身份验证和关键交换发生。通过SSL，这增加了连接的延迟。这就是神话的起源，SSL/HTTPS减慢了您的网站。协议的每一次新迭代都努力减少握手所增加的延迟。通过TLS1.2，证明HTTPS实际上比HTTP快，因为它与HTTP/2兼容。
TLS1.3进一步完善了握手。现在，它可以通过单个往返完成，并启用零往返恢复（0-RTT）。这样做的部分原因是通过将其支持的密码套件数量从四个算法减少到两个。
现在它只是一个批量加密（对称/会话）算法和散列算法。关键交换和数字签名谈判已被删除。现在使用Diffie-Hellman系列进行密钥交换，这既使默认情况下具有完美的转发保密性，又允许客户端和服务器在第一次交互时提供共享秘密的一部分。第一次交互现在也被加密了，关闭了可能的攻击向量的门。
如果您不确定您的服务器是否仍然支持SSL协议，您可以轻松地使用我们的SSL服务器测试进行检查。有关如何禁用SSL2.0和3.0的热门服务器类型的说明（包括Apache、NGINX和Tomcat），请查看我们的相关支持文章。如果您仍然需要禁用TLS1.0，我们也可以帮助您。
那么，Ssl和Tls有什么区别呢？在礼貌的谈话中，不多——很多人继续交替使用Ssl和Tls这两个术语。不过，就服务器配置而言，存在一些主要的架构和功能差异。这些差异是漏洞、过时的密码套件、浏览器安全警告和安全服务器之间的空间。当涉及到您的服务器时，您应该只启用TLS协议。
在任何人开始担心他们需要用TLS证书替换其现有的SSL证书之前，请务必注意，证书并不依赖于协议。即，您不需要使用TLS证书与SSL证书。虽然许多供应商倾向于使用短语”SSL/TLS证书”，但称它们为”用于SSL和TLS的证书”可能更准确，因为协议是由您的服务器配置决定的，而不是由证书本身决定的。
这也适用于加密强度。许多证书宣传加密强度，但真正决定这一点的是服务器和客户端的功能。在每个连接的开始，都会发生称为握手的过程。在此过程中，客户端验证服务器的TLS证书，两者决定相互支持的密码套件。密码套件是一系列算法，它们协同工作，可安全地加密您与该网站的连接。当密码套件在握手过程中协商时，将确定协议版本和支持算法。您的证书只是为流程提供了便利。
从历史上看，密码套件中有四种算法：
目前，您很可能会继续看到称为SSL证书的证书，因为此时此处是更多人熟悉的术语。我们开始看到整个行业使用TLS一词的增多，在TLS被更广泛地接受之前，SSL/TLS是一个常见的折衷方案。
SSL和TLS都是加密协议，提供通过网络运行的服务器、机器和应用程序（例如连接到Web服务器的客户端）之间的身份验证和数据加密。实际上，SSL只有大约25岁。但在互联网时代，那是古老的。SSL的第一次迭代，版本1.0，最初由Netscape于1995年开发，但从未发布，因为它充满了严重的安全缺陷。SSL2.0没有好很多，所以仅仅一年后，SSL3.0被释放。同样，它也有严重的安全缺陷。
这时，共识发展部的小伙子们对此大为抨击，并开发了TLS1.0。Tls1.0与Ssl3.0非常相似，事实上它基于它，但仍然足够不同，需要降级才能使用Ssl3.0。正如TLS协议的创建者所写：
此协议与SSL3.0之间的差异并不显著，但它们足够显著，TLS1.0和SSL3.0无法互操作。
降级到SSL3.0仍然是危险的，虽然，鉴于其已知的，可利用的漏洞。攻击者针对网站所需的所有工作都是将协议降级为SSL3.0。因此，降级攻击的诞生。这最终成为Tls1.0棺材里的钉子。
TLS1.1于七年后于2006年问世，2008年被TLS1.2取代。这伤害了Tls1.1的采用，因为许多网站只是从1.0升级到Tls1.2。我们现在在Tls1.3，这是在11年后于2018年最终确定的，近30个Ietf草案。
TLS1.3比其前身有了重大改进，目前互联网上的主要参与者正在推动其扩散。微软、苹果、谷歌、莫齐拉和云火焰都宣布计划在2020年1月同时弃用TLS1.0和TLS1.1，使TLS1.2和TLS1.3成为全城唯一的游戏。
无论如何，我们在过去几十年里一直在使用TLS。在这一点上，如果你仍然使用SSL，你落后多年，比喻生活在一个被遗弃的时代，人们仍然使用电话线拨号到互联网上。
通用名称 （CN）（也称为完全合格域名（FQDN）是尊贵名称 （DN） 中的特征值。
通常，它由主机域名组成，看起来像”www.ert7.com”或”ert7.com”。
常见名称字段经常被误解，并且填写错误。
不要使用您的组织的名称作为您的共同名称。
在注册证书之前，您必须从 Web 服务器生成证书签名请求（CSR）。
在生成 CSR 时，您需要输入共同名称字段中的信息。
证书特定于在主机级别颁发的通用名称。
通用名称必须与您在连接到安全站点时访问的 Web 地址相同。
例如，如果访问名为”www.ert7.com”或”knowledge.ert7.com”的网站，因为”www.ert7.com”和”knowledge.ert7.com”与通用名称”ert7.com”不同，则域名”digicert.com”的服务器 ID 将收到警告。
在这种情况下，您必须创建一个 CSR 以正确使用”共同名称”来解决问题。
代码签名证书的通用名称与完全合格的域名 （FQDN） 无关，应与组织名称相同。代码签名 ID 用于数字签名代码，不使用任何特定的 URL 代码。
DigiCert SSL 证书是业内历史最悠久、支持最广泛的根基之一颁发的，如今几乎每个浏览器都信任该证书，以及数十种智能手机和手持式计算设备。
作为世界上最大的证书提供商之一，DigiCert 颁发的证书受到所有普通浏览器、邮件客户端、操作系统和浏览器的信任。
我们将一些不寻常的平台排除在下面的列表中。
在线咨询
您好，请问有什么可以帮助您？
SSL证书/代码（数字）签名证书/https证书
