最近更新： | 所有文档
- ACME (自动证书管理环境 - Automatic Certificate Management Environment)
- 由 Let’s Encrypt 实现的协议。 与该协议兼容的软件可以用它与 Let’s Encrypt 通信以获取证书。 参见 ACME RFC 和维基百科条目。
- ACME 客户端 (ACME Client)
- 能够与 ACME 服务器通信以获取证书的程序。
- ACME 服务器 (ACME Server)
- 兼容 ACME 协议的服务器，能够生成证书。 Let’s Encrypt 开发的软件 Boulder 与 ACME 协议兼容，但有一些差异。
- Boulder
- 一款实现了 ACME 协议的软件，由 Let’s Encrypt 开发并投入使用。 参见 GitHub 代码仓库。
- CA 颁发者 (CA Issuers)
- AIA 字段的一部分，包含证书颁发者的信息。 如果网页服务器没有提供可信的证书链，这一信息可能会有用。
- CA/浏览器论坛 (CA/Browser Forum)
- 由证书颁发机构、互联网浏览器软件的供应商、操作系统和其他使用 PKI 的应用程序组成的志愿团体。 CA/浏览器论坛发布了底线要求。 Let’s Encrypt 也是 CA/浏览器论坛的成员。 参见维基百科条目。
- CAA (证书颁发机构授权 - Certificate Authority Authorization)
- 一类 DNS 记录，用于指定哪些 CA 有权为相应的域名颁发证书。 CAA 记录需要 CA 遵守，而非由浏览器检查。 按照底线要求的规定，Let’s Encrypt 严格遵循 CAA 记录。 参见维基百科条目。
- DANE (基于 DNS 的实体认证 - DNS-based Authentication of Named Entities)
- 一种通过 DNS 表明证书或密钥验证方式的机制。 参见英文维基百科条目。
- DNSSEC (域名系统安全扩展 - Domain Name System Security Extensions)
- 一种使用密码学验证 DNS 应答的机制。 要使 DNSSEC 生效，必须在 TLD、域名所有者以及递归解析服务器上都进行部署。 目前其采用率较低。 参见维基百科条目。
- DV 证书 (域名验证型证书 - Domain-validated certificate)
- 此类证书的申请者仅证明了其对域名（而非自称的组织团体）的控制权。 Let’s Encrypt 只提供 DV 证书，不提供 OV 及 EV 证书。参见常见问题和维基百科条目。
- ECC (椭圆曲线密码学 - Elliptic Curve Cryptography)
- 基于椭圆曲线的一种公钥密码学。 相较于非椭圆曲线的加密方式，ECC 在提供同等的安全性的前提下使用更小的密钥。 参见 Cloudflare 博客文章和维基百科条目。
- ECDSA (椭圆曲线数字签名算法 - Elliptic Curve Digital Signature Algorithm)
- 一种采用椭圆曲线密码学的数字签名算法（DSA）。 参见维基百科条目。 Let’s Encrypt 支持在叶证书（最终实体证书）中使用 ECDSA，但暂时没有完整的 ECDSA 证书链。参见即将推出的功能。
- EV (扩展验证 - Extended Validation)
- CA 在颁发证书前核实对网站具有控制权的法人， 证书中包含法人的具体信息。 CA 对此类证书的控制比 OV 证书更为严格。 Let’s Encrypt 不提供 EV 证书。 参见维基百科条目。
- Ed25519
- EdDSA 的一种类型，类似的还有 Ed448。
- EdDSA (爱德华兹曲线数字签名算法 - Edwards-curve Digital Signature Algorithm)
- 基于椭圆曲线的现代公钥签名系统，其设计旨在解决椭圆曲线密码的一些常见实现问题。 Let’s Encrypt 这样的证书颁发机构暂时还不能提供 EdDSA 证书。 参见英文维基百科条目。
- FQDN (完全限定域名 - Fully qualified domain name)
- 网站的完整域名。 例如，
www.example.com就是一个 FQDN。 - HTTP 公钥固定 (HPKP - HTTP Public Key Pinning)
- 一种安全机制，要求浏览器连接网站时确保证书链必须使用特定的公钥。 Chrome 浏览器曾引入这一机制应对 CA 被入侵的情况，但网站常因此出现问题，最终 Chrome 废除了该功能。 参见维基百科条目。
- IDN (国际化域名 - Internationalized Domain Name)
- 含有
a到z、0到9、短横线（-）以外字符的域名。 此类域名中可以使用带有变音符或连字的拉丁字母，也可以使用汉字、阿拉伯文、西里尔文、泰米尔文、希伯来文等文字。 编码后的 IDN 以xn--开头。 Let’s Encrypt 支持 IDN：https://letsencrypt.org/2016/10/21/introducing-idn-support.html。 参见维基百科条目、RFC 5890 和 RFC 5891。 - IDNA (应用程序中的国际化域名 - Internationalized Domain Names for Applications)
- 参见国际化域名。
- ISRG (互联网安全研究组 - Internet Security Research Group)
- Let’s Encrypt 背后的运作机构：https://www.abetterinternet.org/about/。 参见英文维基百科条目。
- IdenTrust
- 一家证书颁发机构。 IdenTrust 为 Let’s Encrypt 的中间证书提供了交叉签名：/certificates。 参见英文维基百科条目。
- Let's Encrypt (LE)
- 一家由 ISRG 运营的证书颁发机构。 参见维基百科条目。
- OCSP (在线证书状态协议 - Online Certificate Status Protocol)
- 一种检查证书是否已被吊销的方式。 也就是询问证书颁发机构，某一份证书是否尚未到期就已提前失效。 这种方式存在隐私问题，因为证书颁发机构和网络运营商都能得知谁访问了哪些网站。 参见维基百科条目。
- OCSP 强制装订 (OCSP Must-Staple)
- 一种证书扩展，告知浏览器使用此证书的网页服务器必须采用 OCSP 装订。 这能保证每次连接时证书的实时吊销状态都能得到服务器确认，使吊销机制更加可靠。 Let’s Encrypt 可以根据申请颁发带有 OCSP 强制装订扩展的证书。 参见 Mozilla 安全博客文章和 RFC 7633。
- OCSP 装订 (OCSP stapling)
- 网页服务器将证书颁发机构签名的 OCSP 响应直接发送给浏览器，使浏览器不必再自行询问证书颁发机构，从而提升网页加载速度并保护用户隐私。 这种方式也称为 TLS 证书状态请求扩展。 参见维基百科条目和 Cloudflare 博客文章。
- OID (对象标识符 - Object identifier)
- 一种全球唯一的数字型标识符，由国际电信联盟（ITU）和 ISO/IEC 标准化。 OID 在证书中用于定义扩展、字段和制度声明， 具体用法由互联网协议、证书颁发制度和证书运作声明规定。 参见维基百科条目。
- OV (组织验证 - Organization Validation)
- CA 核实用户的法人身份后颁发的证书， 此类证书含有该法人的相关信息。 Let’s Encrypt 不提供 OV 证书。 参见维基百科条目。
- PEM 文件（.pem） (PEM file (.pem))
- 一种密码学信息的格式（原来作为“隐私增强型邮件”互联网标准的一部分被用于保护电子邮件）。 PEM 文档可以用于表示私钥、公钥、数字证书等信息。 这些文件以“—–BEGIN”加上数据类型开头。 参见维基百科条目。
- RSA
- 一种用于加密和数字签名证书的公钥加密算法。 参见维基百科条目。
- SCT (签名证书时间戳 - Signed Certificate Timestamp)
- 一种经过数字签名的、可验证的承诺，保证将证书发布至证书透明化日志系统。 严格遵循 CT 的浏览器会检查所有网站证书或 TLS 握手过程中的 SCT 字段，如果不符合其日志要求则拒绝连接。 这使得欺诈性的或错误的证书更容易被检测出来。 https://www.certificate-transparency.org/how-ct-works
- SNI (服务器名称指示 - Server Name Indication)
- 用户代理在 TLS 握手过程中发送给服务器的一个字段，表示其正在连接的域名。 如果一个 IP 地址有多个域名，服务器可以借助 SNI 提供合适的证书。 例如，网页服务器可以根据客户端指定的 SNI 域名发送不同的证书并展示相应的内容。 SNI 没有加密，但其尚处实验阶段的替代品 ESNI 是加密的。 参见维基百科条目。
- SSL (安全套接字层 - Secure Sockets Layer)
- TLS 的原名，至今仍然很常用。
- TLD (顶级域名 - Top-Level Domain)
- 域名系统中的最高层级，例如德国的
.de、中国的.cn等国家顶级域名（ccTLD），又如.com、.org等通用顶级域名（gTLD）。 参见维基百科条目。 - TLS (传输层安全 - Transport-Level Security)
- HTTPS 用于加密和认证网页访问的协议。
- TLSA
- DANE 的一部分，专门用于验证 TLS 连接。
- UCC (统一通信证书 - Unified Communications Certificate)
- 对包含多个主体备用名称（SAN）的证书的一种称呼。
- X.509
- 定义了公钥证书格式的标准。 参见维基百科条目。
- 个人信息交换文件（.pfx） (Personal Information Exchange Files)
- 一种文件格式，其中可包含叶证书及其私钥，以及该证书到根证书的证书链。 参见维基百科条目和 Microsoft 硬件开发者中心文章。
- 中间证书 (Intermediate certificate)
- 由根证书或另一中间证书签名的、能够为其他证书签名的证书。 此类证书用于为叶证书签名，从而使根证书的私钥可以在离线环境下安全存储。 中间证书会包含在证书链中。 参见维基百科条目。
- 主体备用名称 (SAN - Subject Alternative Name)
- 证书中的一个字段，表明该证书对哪些域名有效。 这一功能原先由通用名称提供，但该字段已取而代之，通用名称的这一功能也只因兼容性得以保留。 一份证书可以包含多个 SAN，从而对多个域名有效。 参见维基百科条目和速率限制。
- 交叉签名 (Cross Signing)
- 一份具备证书签发能力的证书也可以由不同的根证书签名。 例如，Let’s Encrypt 的中间证书由 IdenTrust 交叉签名，因为 Let’s Encrypt 的根证书在创立初期还没有得到证书库的广泛信任。 交叉签名在原理上需要两份主体和密钥对都相同的证书，一份由 Let’s Encrypt 的私钥签名，另一份则由 IdenTrust 根证书的私钥签名：/certificates。 参见维基百科条目。
- 依赖方 (Relying Party)
- 需要使用证书中的信息的人， 例如 HTTPS 网站的用户。
- 公共后缀列表 (PSL - Public Suffix List)
- 由 Mozilla 维护的公共后缀的列表，它包含了那些可供大量实体注册的互联网域名。 例如，
com和co.uk都在这一列表中，虽然co.uk并不是顶级域名。 网页浏览器使用这个列表和其他一些方法来防止可能是不同实体运营的网站互相共享 Cookies。 Let’s Encrypt 也使用了这一列表，用于实施速率限制。 https://publicsuffix.org/ - 关键扩展 (Critical extension)
- 证书中的扩展可以标记为“关键”扩展， 如果软件不知道如何处理此扩展，就必须拒绝使用该证书。 这使得对于安全性至关重要的功能也可以通过扩展的形式实现，不会在旧版本软件中造成风险。
- 准证书 (Precertificate)
- 证书透明化系统的一部分。 准证书由 CA 即将颁发的证书外加一项关键扩展组成，该扩展用于防止一般软件将准证书作为正常证书使用。 CA 将生成的准证书提交至 CT 日志系统，从而获得 SCT。 由于准证书与其对应的证书并不完全相同，二者最终可能都会录入证书透明化日志系统中。 参见 RFC 6962 第 3.1 节。
- 叶证书（最终实体证书） (Leaf certificate (end-entity certificate))
- 一般是由中间证书签名的一份证书，仅对一系列域名有效，且不能用于签发其他证书。 ACME 客户端申请及网页服务器使用的都是此类证书。 参见维基百科条目。
- 吊销 (Revocation)
- 证书在到期前始终有效，除非 CA 声明该证书已被提前吊销。 吊销的原因有很多种，比如私钥泄露。 浏览器可以通过 CRL、OCSP 或 OneCRL、CRLSets 等较新的方式核实证书是否已被吊销。 需要注意的是，吊销证书经常无法起到作用。 [/docs/revoking](/docs/revoking)
- 密钥对 (Key-pair)
- 用于签名或加密的公钥和私钥的组合。 公钥通常嵌入在证书中，而私钥则独立保密存储。 根据不同的应用情况，密钥对可以用于加密和解密、签名和验证数据或是协商二级密钥。 参见维基百科条目。
- 底线要求 (BRs - Baseline Requirements)
- 一组针对 CA 的技术和政策上的要求。 由于所有根证书项目都包含了底线要求，CA 若要被大多数浏览器信任就必须遵循这些要求。
- 根证书 (Root certificate)
- 一份由证书颁发机构控制的自签名证书，收录于各证书库中，用于签发其中间证书。 参见维基百科条目。
- 根证书项目 (Root Program)
- 组织机构对于哪些证书可收录于其证书库中所作的规定，即哪些 CA 可得到其软件的信任。
- 测试环境 (Staging)
- Let’s Encrypt 提供的接口，可用于调试证书申请流程，避免触发速率限制。 测试环境中生成的证书是不会被广泛信任的， 因此测试环境只应在测试、调试和 ACME 客户端开发过程中使用。 参见测试环境文档。
- 混合内容 (Mixed content)
- 在 HTTPS 网页中通过 HTTP 加载子资源（JavaScript、CSS 或图片）。 浏览器可能会屏蔽混合内容，或将含有混合内容的页面标为不安全：https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content。 要解决混合内容的问题，网页开发者必须把所有资源都改为使用 HTTPS 链接。 通过浏览器内置的开发者工具可以找到哪些资源存在混合内容的问题。
- 用户 (Subscriber)
- 申请证书的个人或组织。
- 用户代理 (User Agent)
- 能够与网页服务器通信的软件， 例如网页浏览器和 cURL。
- 真实名称记录 (CNAME - Canonical Name record)
- 将一个域名映射到另一个域名（称为真实名称）的 DNS 记录。 参见维基百科条目。
- 网页服务器 (Web server)
- 提供网页服务的软件，广义上也可以指运行该软件的硬件。 参见维基百科条目。
- 网页浏览器 (Web Browser)
- 一类用于显示网页内容的用户代理， 例如 Mozilla Firefox、Google Chrome 和 Safari。 参见维基百科条目。
- 自签名证书 (Self-signed certificate)
- 一份主体和颁发者相同的证书，由其自身的私钥签名。 自签名证书只能通过现实中的事先安排得到信任，例如收录于可信根证书列表中。 所有根证书都是自签名证书。 参见维基百科条目。
- 证书 (Certificate)
- 包含公钥以及其他一些描述何时使用该公钥的信息的特定格式的文件。 叶证书是最常见的证书类型。 另外还有中间证书和根证书这两种证书。
- 证书主体 (Certificate subject)
- 证书的“主体”表示这份证书是授予谁的， 其中常包括通用名称、国家、组织等字段。
- 证书吊销列表 (CRL - Certificate Revocation List)
- 一种将证书的吊销情况告知用户代理的方式。 列表中包含某一 CA 吊销的所有证书的序列号，由该 CA 加以数字签名。 参见维基百科条目。
- 证书库 (Certificate Store)
- 证书库包含一系列受信任的根证书。 操作系统（如 Windows、Android、Debian）和网页浏览器（如 Firefox）厂商通常会维护各自的证书库， 但也有一些浏览器直接使用操作系统的证书库。 Let’s Encrypt 提供的证书已得到大多数证书库的信任。
- 证书扩展 (Certificate extension)
- 在证书中，大多数字段都是由扩展来定义的。 例如，主体备用名称和 AIA 都属于扩展。 X.509 标准最初没有定义的字段可以通过扩展机制得到应用。
- 证书签名请求 (CSR - Certificate Signing Request)
- 一份经过数字签名的文件，包含 CA 生成证书所需的信息。 Let’s Encrypt 所需的信息包括通用名称、主体备用名称以及主体公钥信息。 通常，客户端应用程序会自动为用户生成 CSR，Web 托管提供商或相关设备也可能会生成 CSR。 参见英文维基百科条目。
- 证书管理制度 (CP - Certificate Policy)
- 一系列具体的规定，表明证书是否适用于具备一定安全需求的某一类社群和/或应用类型。 证书颁发流程的细节则由 CPS 描述。 CP 和 CPS 可以合并为一份文档。 参见 ISRG 合并后的 CP/CPS 文件、RFC 3647 和英文维基百科条目。
- 证书运作声明 (CPS - Certification Practice Statement)
- 证书颁发机构对于证书颁发、管理、吊销、续期、更换密钥的流程所作的声明。 CPS 必须遵循证书管理制度的规定。 CP 和 CPS 可以合并为一份文档。 参见 ISRG 合并后的 CP/CPS 文件、RFC 3647 第 3.4 节和英文维基百科条目。
- 证书透明化 (CT - Certificate Transparency)
- 为了增强安全性，证书（以及准证书）必须通过证书透明化日志公开发布：https://www.certificate-transparency.org/。 Let’s Encrypt 会先生成并发布准证书，随后在实际证书中列出准证书的 SCT。 部分浏览器（如 Google Chrome）要求这一可验证的承诺必须出现在证书中，以便其验证该证书。 参见维基百科条目。
- 证书透明化日志 (Certificate Transparency Log)
- 证书透明化机制的一部分，将接收到的证书和准证书加入一份永久、公开且可验证的列表中。
- 证书链 (Certificate chain)
- 包含一系列中间证书，将叶证书逐步连接到证书库中的根证书，从而协助用户代理确认叶证书是否可信。 注意：证书链并不总是唯一的，即使网站提供了一条证书链，用户代理也可以选择另一条证书链执行验证。 参见维基百科条目。
- 证书颁发机构 (CA - Certificate Authority)
- 颁发证书的组织。 Let’s Encrypt、IdenTrust、Sectigo 和 DigiCert 都是证书颁发机构。 参见维基百科条目。
- 证书颁发者 (Certificate issuer)
- 证书的“颁发者”字段表示这份证书是由谁签名的。 例如，Let’s Encrypt 颁发的终端实体证书的颁发者字段可能是：“Issuer: C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3”。 颁发者通常包含通用名称、国家、组织等字段， 且必须和某一份证书的主体字段一致。 自签名证书（如根证书）的颁发者与主体字段内容相同。 “颁发者”一词也泛指所有能够签发其他证书的证书（包括中间证书和根证书），或者有资格颁发证书的机构。
- 通用名称 (CN - Common Name)
- 证书主体信息的一部分，表示证书的所有者。 在根证书和中间证书中，通用名称即为证书颁发机构面向用户的名称， 而在叶证书中则是证书包含的一个域名。 注意：通用名称最长 63 个字符。 在过去，通用名称还用于表示证书对应的域名，但在现行的互联网标准中，软件只会通过主体备用名称确定证书的有效性。
- 通配符证书 (Wildcard Certificate)
- 对下一级子域名有效的证书。 例如，SAN 只包含
*.example.com的证书对blog.example.com和www.example.com都有效，但对bork.bork.example.com和example.com都无效。 在子域名处使用星号（*）即表示通配符。 Let’s Encrypt 从 2018 年 3 月起提供通配符证书。 参见维基百科条目。 - 颁发机构信息访问 (AIA - Authority Information Access)
- 用于提示用户代理获取证书颁发者信息的方法的证书扩展。 它通常会指定用于 OCSP 的 URI 地址和颁发者的 URI 地址。