X509证书详解（中文翻译）

英文原文：https://blog.csdn.net/blue0bird/article/details/78656536 https://jamielinux.com/docs/openssl-certificate-authority/index.html本文源于两篇英文文档，将其合二为一，翻译过程参考了网上的其它翻译以求更加准确，再此对这些翻译文档的作者表示感谢！文中介绍的OpenSSL版本较老，与现有的版本有很多不符之处，但万变不离其宗，核心原理还是很有参考价值的。X.509标准是密码学里公钥证书的格式标准。X.509 证书己应用在包括TLS/SSL（WWW万维网安全浏览的基石）在内的众多 Internet协议里，同时它也有很多非在线的应用场景，比如电子签名服务。X.509证书含有公钥和标识（主机名、组织或个人），并由证书颁发机构（CA）签名（或自签名）。对于一份经由可信的证书签发机构签名（或者可以通过其它方式验证）的证书，证书的拥有者就可以用证书及相应的私钥来创建安全的通信，以及对文档进行数字签名。X.509最早与X.500一起发布于1988年7月3日，它假定颁发证书的证书颁发机构（CA）具有严格的层次结构。这与Web信任模型（如PGP）形成了鲜明对比，因为PGP方案是任何人都以签名（而不仅仅是地位特殊的CA），从而证明其他人的密钥证书的有效性。X.509 V3证书的设计非常灵活，除了对网桥拓扑架构网络的支持，还可以支持用于点对点方式的Mesh网，类似于OpenPGP那样的web信任机制，不过这样方式在2004年之前很少使用。
X.500系统仅由主权国家实施，以实现国家身份信息共享条约的实施目的，而IETF的公钥基础设施（X.509）或PKIX工作组已对该标准进行了调整，以适应更灵活的互联网组织结构。事实上X.509认证指的是RFC5280里定义的X.509 v3，包括对IETF的PKIX证书和证书吊销列表（CRL Profile），通常也称为公钥基础设施。在X.509系统中，证书申请者通过发起“证书签名请求（CSR）”来得到一份被签名的证书。为此，它需要生成一个密钥对，然后用其中的私钥对CSR签名（私钥本身要妥善保存，对外保密），CSR包含申请人的身份信息、用于验真CSR的申请人的公钥，以及所请求证书的专有名称（DN），CSR还可能带有CA要求的其它有关身份证明的信息，然后CA对这个专有名称发布一份证书，并绑定一个公钥。组织机构可以把受信的根证书分发给所有的成员，这样就可以使用公司的PKI系统了。像Firefox, IE, Opera, Safari 以及Google Chrome这些浏览器都预装了一组CA根证书，所以可以直接使用这些主流CA发布的SSL证书。浏览器的开发者直接影响它的用户对第三方的信任。FireFox就提供了一份csv/html格式的列表。X.509还包括证书吊销列表（CRL）实现标准，这是PKI系统经常被忽略的方面。IETF批准的检查证书有效性的方法是在线证书状态协议（OCSP），Firefox 3默认情况下启用OCSP检查，从Vista开始的高版本Windows也是如此。X.509证书的结构是用ASN.1(Abstract Syntax Notation One：抽象语法标记)来描述其数据结构，并使用ASN1语法进行编码。X.509 v3数字证书的结构如下：●Certificate证书●Version Number版本号●Serial Number序列号●IDSignature Algorithm ID签名算法●Issuer Name颁发者名称●Validity period 有效期●Not before起始日期●Not after截至日期●Subject Name主题名称●Subject pbulic Key Info 主题公钥信息●Public Key Algorithm公钥算法●Subject Public Key主题公钥●Issuer Unique Identifier (optional)颁发者唯一标识符（可选）●Subject Unique Identifier (optional)主题唯一标识符（可选）●Extensions (optional) 证书的扩展项（可选）…●Certificate Sigature Algorithm证书签名算法●Certificate Signature证书的签名所有扩展都有一个ID，由object identifier来表达，它是一个集合，并且有一个标记指示这个扩展是不是决定性的。证书使用时，如果发现一份证书带有决定性标记的扩展，而这个系统并不清楚该扩展的用途，就要拒绝使用它。但对于非决定性的扩展，不认识可以予以忽略。RFC 1422给出了v1的证书结构，ITU-T在v2里增加了颁发者和主题唯一标识符，从而可以在一段时间后重用。重用的一个例子是当一个CA破产了，它的名称也在公共列表里清除掉了，一段时间之后另一个CA可以用相同的名称来注册，即使它与之前的并没有任何瓜葛。不过IETF并不建议重用同名注册。另外v2也没有在Internet里大范围的使用。v3引入了扩展，CA使用扩展来发布一份特定使用目的的证书（比如说仅用于代码签名）。对于所有的版本，同一个CA颁发的证书序列号都必须是唯一的。RFC 5280（及后续版本）定义了数字证书扩展项，用于指示如何使用证书。它们大多来自joint-iso-ccitt（2）ds（5）id-ce（29）OID。第4.2.1节中定义的一些最常见的是： ●Basic Constraints,{id ce 19}，用于指示一份证书是不是CA证书。●Key Usage, {id ce 15}，指定了这份证书包含的公钥可以执行的密码操作，例如只能用于签名，但不能用来加密。 ●Extended Key Usage{id ce 37}，典型用法是指定叶子证书中的公钥的使用目的。它包括一系列的OID，每一个都指定一种用途。例如{id pkix 31}表示用于服务器端的TLS/SSL连接；{id pkix 34}表示密钥可以用于保护电子邮件。通常情况下，当一份证书有多个限制用途的扩展时，所有限制条件都应该满足才可以使用。RFC 5280有一个例子，该证书同时含有keyUsage和extendedKeyUsage，这样的证书只能用在被这两个扩展指定的用途，例如网络安全服务决定证书用途时，会同时对这个扩展进行判断。1-3）证书文件扩展名
X.509证书有几种常用的文件扩展名，但要注意：其中一些扩展名也有其它用途，就是说具有这个扩展名的文件可能并不是证书，比如说可能只是保存了私钥。●.pem：（隐私增强型电子邮件），DER编码的证书再进行Base64编码，数据存放于“— BEGIN CERTIFICATE —”和“ — END CERTIFICATE —”之间●.cer，.crt，.der：通常采用二进制DER形式，但Base64编码也很常见●.p7b，.p7c-PKC＃7：SignedData结构，没有数据，仅有证书或CRL●.p12-PKCS＃12：可以包含证书（公钥），也可同时包含受密码保护的私钥●.pfx ：PKCS＃12的前身（通常用PKCS＃12格式，例如IIS产生的PFX文件）PKCS#7是签名或加密数据的格式标准，官方称之为容器。由于证书是可验真的签名数据，所以可以用SignedData结构表述。.P7C文件是退化的SignedData结构，没有包括签名的数据。PKCS＃12从个人信息交换（PFX）标准发展而来，用于在单个文件中交换公共和私有对象。证书链（也就是RFC 5280里的证书路径）指的是以最终实体证书开头，后跟一个或多个CA证书，且通常最后一个是自签名证书，具有如下关系：
1.除了链上的最后一个证书外，每个证书的颁发者等于其后一个证书的主题（主题就是使用者）。2.除了链上的最后一个证书外，每个证书都是由其后的一个证书签名。3.最后一个证书是信任锚：由于是通过某种可信的过程得到的，所以你可以信任它。证书链用来检查目标证书（链中的第一个证书）中包含的公钥和其他数据是否属于其主题。检查是这么做的，用证书链中的下一个证书的公钥来验证它的签名，一直检查到证书链的尾端，由于最后一个证书是信任锚，成功达到该证书将证明目标证书可以信任。上段中的描述是根据RFC5280定义的认证路径验证过程的简化过程，实际上涉及额外的检查，例如验证证书的有效日期、查找CRL等。在研究证书链的构建和验证方式时，需要特别注意的是，具体的证书可以是不同的证书链的一部分（链上的所有证书都有效）。 这是因为可以为相同的主题和公钥生成多个CA证书，但使用不同的私钥（来自不同的CA或来自同一CA的不同的私钥）进行签名。 因此，尽管单个X.509证书只能具有一个颁发者和一个CA签名，但是它可以有效地链接到多个证书，从而建立完全不同的证书链。 这对于PKI与其他应用程序之间的交叉认证至关重要，详见以下示例。下图每个框代表一个证书，主题以粗体显示，A→B表示“ A由B签名”（或更准确地说，A由B包含公钥相对应的私钥签名），具有相同颜色（非白色/透明）的证书包含相同的公钥。例1：两个PKI之间，在根证书颁发机构（CA）级别上进行交叉认证为了让PKI 2的用户证书也得到PKI 1的信任，CA1签署包含CA2公钥的证书cert2.1，此时cert2和cert2.1具体相同的主题及公钥，cert2.2 (User 2)就有了两条合法的证书链：”cert2.2 → cert2″ and “cert2.2 → cert2.1 → cert1″。CA2也可以生成类似的包含有CA1公钥的证书cert1.1，以便PKI 1的用户(比如User 1)的证书能在PKI 2得到认证。
例2：CA证书更新 阅读这篇文章：了解认证路径构建（PDF，PKI论坛，2002）
证书颁发者为了从旧的私钥平滑地转移到新的私钥，他可以颁发两个证书，其中一个是新的私钥对旧的公钥进行签名，另一个是旧的私钥对新的公钥的签名，这两个证书都是自颁发的，但都不是自签名。注：另外还存在新旧两个自签名证书。假设cert1和cert3包含相同的公钥（旧的公钥），对于cert5来说有两条合法的证书链，cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情况也类似。这样就允许老的用户证书可以在新旧两个根证书之间平滑转移。 以下是维基百科网站Wikipedia.org和其他几家Wikipedia网站的X.509证书解码实例，由GlobalSign发布，它的颁发者字段（Subject）将Wikipedia描述为一个组织，Subject Alternative Name字段描述可以使用的主机名。Subject Public Key Info字段包含一个ECDSA公钥，而底部的签名由GlobalSign的RSA私钥生成。 3-1）最终实体证书网摘：最终实体证书就是大家通常说的用户证书，有别于CA证书，最终实体证书中的证书主体是不能使用证书所对应的私钥签发证书的。最终实体与CA是两个相对的概念：CA可以利用其私钥签发证书，而最终实体不能。虽然在X.509标准中并未明确定义最终实体证书，但是定义了“最终实体公钥证书吊销列表 （End-entity public-key certificate revocation list）”的概念，由此可见最终实体证书就是指用户证书。最终实体可以是各种类型的实体，如自然人、组织机构、设备、Web服务器等。
要验证此最终实体证书，需要一个与其颁发者和颁发机构密钥标识符（Authority Key Identifier）匹配的中间证书： 在TLS连接中，作为握手过程的一部分，正确配置的服务器将提供该中间层，但也可以通过从最终实体证书中提取“ CA Issuers” URL来检索中间证书。
3-2）中间证书网摘：什么是中间证书？ 中间证书用作根证书的替代。我们使用中间证书作为代理，因为我们必须将根证书保存在众多安全层之后，以确保其密钥绝对不可访问。由于根证书签署了中间证书，因此中间证书可用于签署客户安装和维护的SSL“信任链”。 注意：如果不使用已颁发的SSL证书安装中间证书，则可能无法建立可信链证书。这意味着，当访问者试图访问您的网站时，他们可能会收到一个“安全警报”错误，指示“安全证书是由您未选择信任的公司颁发的…”面对这样的警告，潜在客户很可能会将其业务转移到其他地方。
以下是中间证书的实例，此证书被CA根证书签署，并签署了上面的最终实体证书。 注意：此中间证书的subject字段与它所签署的最终实体证书的issuer字段相同、中间证书的subject key identifier（主题密钥标识符）字段与最终实体证书的的authority key identifier（颁发者的密钥标识符）字段相同。3-3）根证书以下是证书颁发机构的自签名根证书示例，Issuer（颁发者字段）和Subject（主题，使用者字段）是相同的，能够使用自己的公钥对签名进行验证，信任链的验证必须在此结束。如果验证程序在其信任存储中有此根证书，就可以认为在TLS连接中使用的最终实体证书是可信的。否则，最终实体证书被视为不可信。Bruce Schneier，Peter Gutmann和其他安全专家发表了许多有关PKI问题的出版物。 4-1）架构缺陷将无效的证书列入黑名单（使用CRL和OCSP）。PKI的魅力之一是脱机功能，但如果客户端仅使用CRL来判断证书的有效性，在脱机的情况下就会出现误判，因为当CRL不可用时，大多数客户端都会信任证书，于是攻.击者可以通过切断信道来禁用CRL。谷歌（Google）的亚当•兰利（Adam Langley）曾表示，CRL软故障检查就像一条安全带，只有在发生事故时才起作用。● CRL的尺寸较大且分布模式复杂，因此它不是一个很好的选择，● OCSP语义模糊，缺乏历史撤销状态；● 未解决根证书吊销的问题● 聚合问题：身份声明（通过标识符进行身份验证）、属性声明（提交一包经过审核的属性）和策略声明组合在一个容器中，这会引发隐私、策略映射和维护问题。● 委派问题：从技术上讲，CA无法限制下级CA在有限的名称空间或属性集之外颁发证书；X.509的此功能未被使用。因此，互联网上存在大量的CA，对它们进行分类和策略是一项不可完成的任务，一个组织内部的授权不能像一般的商业惯例那样处理。● 联合身份验证问题：证书链是从属CA、桥接CA和交叉签名的结果，这使得验证复杂且处理时间上昂贵、路径验证语义可能不明确。具有第三方受信任方的层次结构是唯一的模型。如果已经建立了双边信任关系，这将很不方便。为主机名颁发扩展验证（EV）证书不会阻止颁发对同一主机名较低验证证书的颁发，这意味着较高的EV验证级别无法抵御中间人攻.击。如果是主体而不是依赖方购买证书，通常会使用最便宜的颁发者，颁发者出于成本考虑，往往采用扩展验证证书来解决问题，但是在安全专家看来，信任价值正在下降。● 证书颁发机构否认对用户（包括主题或依赖方）的几乎所有保证。● 有效期应用于限制密钥强度被视为时间足够，此参数被证书颁发机构滥用以向客户端收取扩展费。这给使用密钥滚动的用户带来了不必要的负担。（没看懂啥意思）●“用户使用未定义的认证请求协议来获取证书，该证书发布于不存在的目录中的不明确位置，从而无有效手段来撤销它。” 与所有企业一样，CA受其经营站点的法律管辖，并可能被迫损害其客户和用户的利益。情报机构还利用了通过CA的法外妥协发出的虚假证书（例如DigiNotar）来进行中间人攻.击。另一个例子是荷兰政府CA的撤销请求，由于新的荷兰法律自2018年1月1日起生效，为荷兰情报和安全部门赋予了新的权力。X.509实现存在设计缺陷、错误、对标准的不同解释以及不同标准的互操作性问题，一些问题是：● 许多实现关闭吊销检查：● 策略被视为障碍，没有得到执行● 如果默认情况下在所有浏览器（包括代码签名）中都打开了它，可能会破坏基础结构● DN很复杂且不容易理解（缺乏规范化、国际化问题……）● RFC822名称有2种表示法● 几乎不支持名称和策略约束● keyUsage被忽略，使用列表中的第一个证书● 自定义oid的实施很困难● 不应将属性设为强制属性，因为它会使客户端崩溃● 未指定的属性长度会导致特定于产品的限制● X.509存在实现错误，例如允许在证书中使用以空值结尾的字符串，或通过代码注入攻.击来伪造使用者名称。● 通过使用对象标识符的0x80填充子标识符，错误的实现或通过使用客户端浏览器的整数溢出，攻.击者可以在CSR中包含一个未知属性，CA会将其签名，客户端错误地将其解释为“CN”（OID = 2.5.4.3）数字签名系统依赖于密码散列函数（哈希函数）的安全性。如果公钥基础结构（PKI）使用了不再安全的哈希函数，攻.击者可以利用哈希函数中的弱点来伪造证书。具体来说，如果攻.击者能够实现“哈希碰撞”，他们可以先说服CA用看似无害的内容签名证书，但这些内容的哈希与攻.击者创建的另一组恶意的证书内容的哈希相同，然后，攻.击者可以将CA提供的签名附加到其恶意证书之中，从而生成“似乎由CA签名”的恶意证书。由于恶意证书内容由攻.击者定制，因此它们的有效日期或主机名可能与无害证书不同；恶意证书甚至可以包含“CA:true”字段，从而使其能够颁发其他受信任证书。● 基于MD2的证书使用了很长时间，容易受到预映像攻.击。由于根证书已经有一个自签名，攻.击者可以使用此签名并将其用于中间证书。● 2005年，Arjen Lenstra和Benne de Weger演示了“如何使用哈希碰撞“构造两个X.509证书，这两个证书包含相同的签名，并且只在公钥上不同，这是通过对MD5散列函数的碰撞攻.击实现的。● 2008年，Alexander Sotirov和Marc Stevens在Chaos Communication Congress上提出了一个实用的攻.击，基于RapidSSL仍在发布基于MD5的X.509证书这一事实，他们创建了一个被所有普通浏览器接受的流氓证书颁发机构。● 2009年4月，在欧洲密码学会议上，麦格理大学（Macquarie University）的澳大利亚研究人员提出了“自动差分路径搜索SHA-1”，研究人员能够推导出一种将碰撞的可能性增加了几个数量级的方法。● 2017年2月，由Marc Stevens领导的一组研究人员制造了一次SHA-1碰撞，证明了SHA-1的弱点。利用哈希碰撞来伪造X.509签名的前提是，攻.击者能够预测证书颁发机构将要签名的数据。通过在CA签署的证书中生成一个随机因素（通常是序列号）可以在某种程度上缓解这种情况。自2011年以来，CA /浏览器论坛已在其基准要求第7.1节中要求序列号熵。 所以，序列号是作为一个随机干扰源而存在，它是保密的，在签署证书之前不能对外泄露。自2016年1月1日起，基线要求禁止使用SHA-1颁发证书。截至2017年初，Chrome 和Firefox拒绝使用SHA-1的证书。截至2017年5月，Edge和Safari都在拒绝SHA-1证书，非浏览器的X.509验证程序尚未拒绝SHA-1证书。 5）PKCS标准概述
在密码学里，PKCS代表“公钥密码学标准”。这是一组由RSA Security Inc.设计和发布的公钥密码标准，始于20世纪90年代初，该公司发布这些标准是为了推广使用他们拥有专利的密码技术，如RSA算法、Schnorr签名算法和其他一些算法。尽管不是行业标准（因为该公司保留了对它们的控制权），但近年来某些标准已经开始进入IETF和PKIX工作组等相关标准化组织的“标准跟踪”过程。● PKCS＃1 2.2 RSA加密标准参见RFC8017。定义了RSA公钥和私钥（以明文编码的ASN.1）的数学属性和格式，以及执行RSA加密、解密和生成及验证签名的基本算法和编码/填充方案。● PKCS＃2-已撤回，从2010年起不再有效，涵盖了RSA对消息摘要的加密，随后合并到PKCS＃1中。● PKCS＃3 1.4 Diffie-Hellman密钥协商标准，一种加密协议，它允许彼此不具有先验知识的双方在不安全的通信信道上共同建立共享的秘密密钥。● PKCS＃4-已撤回自2010年起不再有效，涵盖了RSA密钥语法，随后合并到PKCS＃1中。● PKCS＃5 2.1基于Password的加密标准，参见RFC 8018和PBKDF2。● PKCS＃6 1.5扩展证书语法标准，定义对旧的v1 X.509证书规范的扩展，被v3淘汰。● PKCS＃7 1.5加密消息语法标准，请参阅RFC2315。用于在PKI下对消息进行签名和/或加密。也用于证书分发（例如作为对PKCS＃10消息的响应），形成了S /MIME的基础，S /MIME于2010年基于RFC 5652（一种更新的加密消息语法标准（CMS））建立，通常用于单点登录。● PKCS＃8 1.2私钥信息语法标准，请参见RFC5958。用于携带私钥证书密钥对（加密或未加密）。● PKCS＃9 2.0选定的属性类型[，请参见RFC2985。定义选定的属性类型，以便在PKCS＃6扩展证书、PKCS＃7数字签名消息、PKCS＃8私钥信息和PKCS＃10证书签名请求中使用。● PKCS＃10 1.7认证请求标准，请参阅RFC2986。发送给认证机构以请求公钥证书的消息格式，请参阅证书签名请求。● PKCS＃11 2.40密码令牌接口，也称为“ Cryptoki”。定义密码令牌通用接口的API（另请参阅硬件安全模块）。常用于单点登录，公共密钥加密和磁盘加密[10]系统。 RSA Security已将PKCS＃11标准的进一步开发移交给了OASIS PKCS 11技术委员会。● PKCS＃12 1.1个人信息交换语法标准，请参阅RFC7292。定义一种文件格式，个人信息交换语法标准[11]见RFC 7292。定义一种文件格式，通常用于存储私钥和附带的公钥证书，并使用基于Password的对称密钥进行保护。PFX是PKCS#12的前身。此容器格式可以包含多个嵌入式对象，例如多个证书。通常使用密码进行保护/加密。可用作Java密钥存储的格式，并在Mozilla Firefox中建立客户端身份验证证书，可供Apache Tomcat使用。简单的说，PKCS#12可以包含证书（公钥），也可以包含受密码保护的私钥● PKCS＃13 椭圆曲线密码技术标准（已废弃，唯一的参考是1998年的提案）● PKCS＃14 伪随机数生成（已废弃，没有文档）● PKCS＃15 1.1加密令牌信息格式标准，定义了一个标准，允许加密令牌的用户向应用程序标识自己，而与应用程序的Cryptoki实现（PKCS＃11）或其他API无关。RSA放弃了该标准中与IC卡相关的部分，并改为ISO / IEC 7816-15。本指南演示如何使用OpenSSL命令行工具充当您自己的证书颁发机构（CA）。这在许多情况下都很有用，例如颁发服务器证书以保护intranet网站，或向客户端颁发证书以允许客户端向服务器进行身份验证。 OpenSSL是一个免费的开源加密库，它提供了一些用于处理数字证书的命令行工具，其中一些工具（也就是命令）可以充当证书颁发机构。证书颁发机构是为数字证书签名的实体。许多网站需要让其客户知道连接是安全的，因此他们向国际证书颁发机构（CA）支付费用，以为其域签署证书。 在某些情况下，自己做自己CA（而不是向DigiCert这样的CA付钱）更有意义，比如保护intranet网站的安全，或向客户端颁发证书以允许客户端向服务器进行身份验证。充当证书颁发机构意味着要处理密钥对之中的私钥和公钥证书。 我们要创建的第一个密钥对就是根对。这包括根密钥（ca.key.pem）和根证书（ca.cert.pem）。这个“根对”构成了你的CA的身份。通常，根CA不会直接为服务器或客户端证书签名，根CA仅用于创建一个或多个中间CA，这些中间CA被根CA信任，并代表根CA签署证书，这是最佳实践，它允许根密钥保持脱机状态并尽可能减少使用的次数，因为对根的任何威胁都是灾难性的。注意：最佳实践是在安全的环境中创建根对。理想情况下，该计算机应该是完全加密并且空气隔离（含义是没有任何网络接口的机器，即不能通过外部网络连接），可以考虑卸载无线网卡，并用胶水塞满以太网口。6-2-1）准备目录您必须创建一个配置文件以供OpenSSL使用。 将根CA配置文件从Appendix复制到/root/CA/openssl.cnf，其中的[ca]部分为必填项，这里告诉OpenSSL使用[CA_default]部分中的选项。创建根私钥（ca.key.pem）并确保其绝对安全，因为任何拥有根私钥的人都可以颁发“可信证书”，建议使用AES 256算法和复杂的强密码加密根私钥。注意：出于安全考虑，对所有根CA和中间CA使用4096位私钥。使用根密钥（ca.key.pem）创建根证书（ca.cert.pem），给根证书一个长的有效期，比如20年。根证书过期后，由根CA签名的所有证书都将无效。警告：无论何时使用req工具，都必须指定要与-config选项一起使用的配置文件，否则OpenSSL将默认为/etc/pki/tls/OpenSSL.cnfopenssl x509 -noout -text -in certs/ca.cert.pem这行命令的输出包括：● 使用的签名算法● 证书生效期● 公钥位长度● 颁发者，即签署证书的实体● 主体，指的是证书本身由于证书是自签名的，因此颁发者和主题相同。请注意，所有根证书都是自签名的。中间证书授权（CA）是可以代表根CA签署证书的实体，根CA签署中间证书，这就形成了信任链。使用中间证书的目的主要是：根密钥可以保持脱机状态，并尽可能不频繁地使用。如果中间密钥被泄露，根CA可以撤销中间证书并创建新的中间密钥对。根CA文件保存在/ root / ca中，选择其他目录（/root/ca/intermediate）来存储中间CA文件。6-3-2) 创建中间密钥
创建中间密钥（intermediate.key.pem），并使用AES 256算法和复杂的强密码将其加密保护。6-3-3) 创建中间证书使用中间证书创建证书签名请求（CSR），详细信息通常应与根CA相同。但 Common Name（证书持有者通用名/FQDN）必须不同：警告：请确保命令行指定的中间 CA 配置文件存在（intermediate/openssl.cnf）。要创建免费云主机域名中间证书，请使用带有v3_intermediate_CA扩展项的根CA对中间CSR进行签名。中间证书的有效期应短于根证书。十年是合理的。警告：指定根CA配置文件 /root/ca/openssl.cnf。6-3-4) 验证中间证书正如我们对根证书所做的那样，请检查中间证书的详细信息是否正确：# openssl x509 -noout -text -in intermediate/certs/intermediate.cert.pemintermediate.cert.pem: OK当应用程序（如web浏览器）尝试验证由中间CA签名的证书时，它必须对照根证书验证中间证书。要完成信任链，请创建CA证书链以呈现给应用程序。要创建CA证书链，请将中间证书和根证书连接在一起，我们稍后将使用此文件来验证由中间CA签名的证书。注意：证书链文件必须包含根证书，因为需要让客户端应用程序找到它。更好的选择（尤其是在管理Intranet的情况下）是在需要连接的每个客户端上安装根证书，在这种情况下，证书链文件仅需要包含您的中间证书。我们将使用中间 CA 签署证书。您可以在各种情况下使用这些证书，例如保护与Web 服务器的连接或对连接到服务器的客户端进行身份验证。注意：以下步骤是CA替申请者创建私钥和签名请求（CSR），但申请者从安全角度考虑也可以自己创建私钥和请求，其中的私钥妥善保存于本地，把CSR交给CA，CA则还给它一个签名的证书。在这种情况下，跳过 genrsa 和 req 命令。 我们的根密钥对和中间密钥对是4096位，服务器证书和客户端证书通常在一年后过期，因此我们可以安全地使用2048位。 注意：尽管4096位比2048位更安全，但它会减慢TLS握手速度并显着增加握手期间的处理器负载。因此，大多数网站使用2048位的密钥对。 译者注：2048位已经不再安全，建议使用4096或8192位。 如果要创建用于网络服务器的密钥对，每次重启该服务器时都需要输保护密码，如果嫌麻烦可以不使用-aes256选项以创建没有密码的私钥。6-4-2) 创建证书 使用私钥创建证书签名请求（CSR），并且CSR的详细信息无需与中间CA相匹配。对于服务器证书，Common Name（公用名）必须是FQDN（完全限定的域名，例如，www.example.com），而对于客户端证书，Common Name可以是任何唯一标识符（例如电子邮件地址），请注意，客户端证书的Common Name与根证书或中间证书的Common Name不同。要创建证书，请使用中间CA对CSR进行签名。如果要在服务器上使用证书，请使用 server_cert扩展项;如果证书将用于用户身份验证，请使用usr_cert扩展项。证书的有效期通常为一年，不过为了方便起见，CA通常会多给几天时间。6-4-3) 验证证书 # openssl x509 -noout -text -in intermediate/certs/www.example.com.cert.pem6-4-4) 部署证书现在，您可以将新证书部署到服务器，也可以将证书分发给客户端。部署到服务器应用程序（例如Apache）时，确保以下文件可用：ca-chain.cert.comwww.example.com.key.pemwww.example.com.cert.pem如果您是从第三方获得CSR，那就无需使用它的私钥，因此只需将证书链文件（ca-chain.cert.pem）和证书（www.example.com.cert.pem）发回给它们。证书吊销列表 （CRL，见RFC5280） 提供已吊销的证书的列表。客户端应用程序（如 Web 浏览器）可以使用 CRL 检查服务器的真实性。服务器应用程序（如Apache或OpenV.P.N）可以使用 CRL 拒绝访问不再受信任的客户端。 在公共可访问的位置（例如http://example.com/intermediate.crl.pem）发布 CRL，第三方可以从此位置获取 CRL，以检查他们依赖的证书是否已被吊销。注意：一些应用程序供应商已弃用CRL，而是使用联机证书状态协议（OCSP，百度RFC2560，有中文版）。 证书颁发机构在签署证书时，通常会将CRL位置编码到证书中，将crlDistributionPoints添加到适当的部分，对于本例，将其添加到[server_cert]部分。[ server_cert ]# … snipped …crlDistributionPoints = URI:http://example.com/intermediate.crl.pem# cd /root/ca# openssl ca -config intermediate/openssl.cnf -gencrl -out intermediate/crl/intermediate.crl.pem注意：ca手册页的CRL OPTIONS部分包含有关如何创建CRL的更多信息。您可以使用crl 工具检查 CRL 的内容：openssl crl -in intermediate/crl/intermediate.crl.pem -noout -text尚未吊销任何证书，因此输出将显示“无吊销证书”您应该定期重新创建CRL。默认情况下，CRL在30天后过期。这由[CA_default]部分的default_crl_days选项控制。让我们看一个例子。爱丽丝（Alice）正在运行Apache服务器，并有一个私人文件夹，上面放着可爱的小猫图片。 爱丽丝想授予她的朋友鲍勃（Bob）访问此收藏的权限。①Bob创建一个私钥和证书签名请求（CSR）:②Bob将自己的CSR发送给爱丽丝，爱丽丝随后对其进行签名：
③Alice 验证证书是否有效：现在index.txt文件应包含一个新条目：V 160420124740Z 1001 unknown … /CN=bob@example.comAlice向Bob发送签名证书，Bob将证书安装在自己的网络浏览器中，现在可以访问爱丽丝的小猫图片，欢呼吧！④但可悲的是，事实证明Bob行为不端，Bob将Alice的小猫图片发布到了《***新闻》上，声称是他自己的照片并广受欢迎，爱丽丝发现了，需要立即撤销了他的访问权限：现在index.txt中与Bob的证书相对应的行以字符R开头，这表示证书已被吊销：R 160420124740Z 150411125310Z 1001 unknown … /CN=bob@example.com撤销Bob的证书后，Alice必须重新创建CRL。6-5-4) 服务器端使用CRL
对于客户端证书，通常是服务器端应用程序（如Apache）进行验证。此应用程序需要具有对CRL的本地访问权限。对于Alice，她可以将SSLCARevocationPath指令添加到Apache配置中，然后将CRL复制到她的Web服务器上，下次Bob连接到Web服务器时，Apache将根据CRL检查其客户端证书并拒绝访问。同样，OpenV.P.N具有crl-verfiy指令，因此它可以阻止证书被吊销的客户端。对于服务器证书，通常是服务器端应用程序（如web浏览器）（译者注：不知是否是英文原文的笔误，Web浏览器应该是客户端程序）进行验证。此应用程序必须具有对CRL的删除访问权限。如果使用包含crlDistributionPoints的扩展项签署了证书，则客户端应用程序可以读取此信息并从指定位置获取CRL。CRL分发点在证书X509v3详细信息中可见。6-6) 在线证书状态协议OCSP百度RFC2560，有中文版。联机证书状态协议（OCSP）是证书吊销列表（CRL）的替代方案。与CRL类似，OCSP允许请求方（如web浏览器）确定证书的吊销状态。当CA签署证书时，它们通常会在证书中包含OCSP服务器地址。这在功能上与用于CRL的crlDistributionPoints相似。例如，当服务器向web浏览器提供了证书，浏览器将向证书中指定的OCSP服务器地址发送查询，OCSP响应者在此地址侦听查询，并以证书的吊销状态做出响应。注：建议在可能的情况下使用OCSP，实际上您只需要OCSP来获得网站证书，因为一些web浏览器已不再支持CRL。要使用OCSP，CA必须将OCSP服务器位置编码到它所签署的证书中。在适当的部分中使用authorityInfoAccess选项，在本例中指的是[ server_cert ]部分。[ server_cert ]# … snipped …authorityInfoAccess = OCSP;URI:http://ocsp.example.comOCSP响应程序需要一个密钥对，用来对发回给请求方的响应进行签名。OCSP密钥对必须由当前正在检查的证书的同一CA签署。创建私钥并使用 AES-256 对其进行加密保护：创建证书签名请求（CSR），详细信息通常应与签名CA的详细信息匹配。但是，公用名必须是完全限定的域名：6-6-3) 吊销证书OpenSSL ocsp工具可以充当OCSP响应程序，但仅用于测试。存在可用于生产的OCSP响应程序，但是这些响应程序不在本指南的范围内。创建要测试的服务器证书：在本地主机上运行OCSP响应程序。OCSP响应程序不会将吊销状态存储在单独的CRL文件中，而是直接读取index.txt。响应使用OCSP私钥对签名（使用-rkey和-rsigner选项）：另一个终端向OCSP响应程序发送查询。-cert选项指定要查询的证书：输出的开头显示：● 是否收到成功响应（OCSP 响应状态：OCSP Response Status）● 然后是响应者的身份（应答器 ID：Responder Id）● 证书的吊销状态（证书状态：Cert Status）吊销证书：如前所述，本机运行OCSP响应程序，另一个终端发送查询。这次的输出显示的证书状态已经改变：已吊销和吊销时间： 6-7) 附录

相关推荐: linux如何查找目录或文件是否存在

本篇内容主要讲解“linux如何查找目录或文件是否存在”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“linux如何查找目录或文件是否存在”吧! 方法：1、利用find命令，语法为“find 目录或文件 查找规则”；…