diff options
Diffstat (limited to 'files/zh-cn/archive/security')
4 files changed, 0 insertions, 600 deletions
diff --git a/files/zh-cn/archive/security/digital_signatures/index.html b/files/zh-cn/archive/security/digital_signatures/index.html deleted file mode 100644 index a6bbd73af1..0000000000 --- a/files/zh-cn/archive/security/digital_signatures/index.html +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Digital Signatures -slug: Archive/Security/Digital_Signatures -translation_of: Archive/Security/Digital_Signatures ---- -<p>加密和解密解决了窃听问题，这是本文开头提到的三个互联网安全问题之一。但加密和解密本身并不能解决另一个问题：篡改。</p> - -<p>本节描述公钥加密如何解决篡改问题。</p> - -<p>篡改检测和相关的身份验证技术依赖于一个称为单向哈希（也称为消息摘要）的数学函数。单向哈希是具有以下特征的固定长度数：</p> - -<ul> - <li>哈希值对于哈希数据是唯一的。数据中的任何更改，甚至删除或更改单个字符，都会导致不同的值。</li> - <li>出于所有实际目的，哈希数据的内容不能从哈希中推断出来，这就是为什么它被称为“单向”的原因。</li> -</ul> - -<p>类似地，在公钥加密中，生成用于数字签名的密钥对。密钥对由<span style="line-height: 1.5;"> </span><strong>私有签名密钥</strong><span style="line-height: 1.5;">和</span><strong>公共验证密钥</strong><span style="line-height: 1.5;">组成. </span>公钥被广泛分发，而私钥只有其所有者知道。这些密钥在数学上是相关的，但是选择这些参数是为了从公钥中计算私钥是不可能的，或者是非常昂贵的。加密的散列以及其他信息，如散列算法，被称为数字签名。</p> - -<p>图1显示了使用数字签名来验证签名数据完整性的简化视图。</p> - -<p><img alt="Figure 3. Using a Digital Signature to Validate Data Integrity" class="internal" src="https://mdn.mozillademos.org/files/10307/04digsgn.png" style="height: 223px; width: 652px;"></p> - -<p>图1显示了传输给某些签名数据的接收者的两个项目：原始数据和数字签名，这基本上是一个单向散列（原始数据的散列），已经用签名者的私钥加密。 为了验证数据的完整性，接收软件首先使用签名者的公钥来解密散列。然后使用生成原始散列的相同散列算法生成相同数据的新单向散列。（有关使用的散列算法的信息与数字签名一起发送，但图中未显示。） 最后，接收软件将新散列与原始散列进行比较。 如果两个散列匹配，则数据自签名后没有更改。如果它们不匹配，则数据可能在签名后被篡改，或者签名可能是使用与签名者提供的公钥不对应的私钥创建的。</p> - -<p>如果两个散列匹配，则收件人可以确定用于解密数字签名的公钥与用于创建数字签名的私钥相对应。 但是，要确认签名者的身份，还需要某种方式来确认公钥确实属于某个特定的人或其他实体。For a discussion of the way this works, see "<a href="/en-US/docs/Introduction_to_Public-Key_Cryptography">Introduction to Public-Key Cryptography</a>."</p> - -<p>数字签名的重要性与手写签名的重要性相当。 一旦您签署了一些数据，就很难拒绝以后这样做，假设私钥没有被泄露或超出了所有者的控制。一旦您签署了一些数据，就很难拒绝以后这样做，假设私钥没有被泄露或超出了所有者的控制。在某些情况下，数字签名可能与手写签名一样具有法律约束力。</p> - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> - -<ul> - <li>Author(s): Ella Deon Lackey</li> - <li>Last Updated Date: 2012</li> - <li>Copyright Information: © 2012 Red Hat, Inc.</li> - <li>Link: <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System_Common_Criteria_Certification/8.1/html/Deploy_and_Install_Guide/index.html">Red Hat Certificate System Common Criteria Certification 8.1: Deployment, Planning, and Installation</a></li> -</ul> -</div> diff --git a/files/zh-cn/archive/security/encryption_and_decryption/index.html b/files/zh-cn/archive/security/encryption_and_decryption/index.html deleted file mode 100644 index 8154ffdffa..0000000000 --- a/files/zh-cn/archive/security/encryption_and_decryption/index.html +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Encryption and Decryption -slug: Archive/Security/Encryption_and_Decryption -translation_of: Archive/Security/Encryption_and_Decryption ---- -<p>加密是使预期参与者外的仍何人不可知的的信息转换过程。解密是加密的反过程以便让信息可理解。一个加密算法也被称作暗号，是一个数学函数用于加解密。大多数情况使用两个相关联函数，一个用于加密一个用于解密。</p> - -<p>凭借大多数现代密码学，保障加密信息的隐秘不是基于加密算法，这是被广泛认知的，而是通过一个被称为密钥的数字它将必须被用到算法过程中去产生一个加密后或解密后的结果。通过正确的密钥解密很简单。没有正确的密钥解密是非常困难的，并且在某些情况下所有的尝试都是不能解密的。</p> - -<p>以下部分是对密钥来加密和解密的进一步介绍</p> - -<ul> - <li><a href="#Symmetric-Key_Encryption">对称密钥加密</a></li> - <li><a href="#Public-Key_Encryption">公开密钥加密</a></li> - <li><a href="#Key_Length_and_Encryption_Strength">密钥长度和加密强度</a></li> -</ul> - -<h3 id="Symmetric-Key_Encryption" name="Symmetric-Key_Encryption">对称密钥加密</h3> - -<p>使用对称密钥加密，加密密钥可以通过加密密钥运算得出，反之亦然。大多数的对称加密算法中，使用的是相同的密钥，如图一所示。</p> - -<p><img alt="Figure 1. Symmetric-Key Encryption" class="internal" src="https://mdn.mozillademos.org/files/10303/05scrypt2.png" style="height: 125px; width: 443px;"></p> - -<p>对称密钥加密的实现可以是非常高效的，以至于使用者不会体验到非常大的延时就得到加密或解密的结果。对称密钥加密还提供了一定程度的认证机制，自从信息被一个对称密钥加密后不可被另一个对称密钥解密。因此，在加密通信中只要对称密钥隐秘的保存在通信双方，并能确认其通信另一方（的真实性）解密后的消息就存在意义。</p> - -<p>对称密钥加密仅仅当涉及到的双方秘密的保存对称密钥才是有效的。如果任何人发现了密钥，它会影响保密性和身份验证。拥有未经授权的对称密钥的人（虚假的第三方）不仅可以解密与该密钥一起发送的消息，还可以加密新消息并将它们发送，就好像它们来自最初使用密钥的两方中的一方。</p> - -<p>对称密钥加密在SSL协议中具有极其重要的作用，它被用于认证，篡改检测和在TCP/IP网络上的加密。SSL也使用到了公开密钥技术，它将在下一节中描述。</p> - -<h3 id="Public-Key_Encryption" name="Public-Key_Encryption">公开密钥加密</h3> - -<p>最常见实现公开密钥加密是基于RSA Data Security专利的算法。因此，这一节介绍RSA公钥加密方法。</p> - -<p>公开密钥加密（也被称作非对称加密）包含一对密 - 公钥和私钥与需要以电子方式验证其身份或签署或加密数据的实体相关联。任何公钥是可以公开的与之对应的私钥需要隐秘保存。使用公钥加密的数据仅能被你的私钥解密。<a href="#Figure2">图2 </a>展示了简化的使用公钥加密是如何工作的。</p> - -<p><img alt="Figure 2. Public-Key Encryption" class="internal" src="https://mdn.mozillademos.org/files/15760/06pcrypt-corrected.png" style="height: 125px; width: 443px;"></p> - -<p>图2所示的方案可让您自由分发公钥，只有您将能够读取使用此密钥加密的数据。通常，要将加密数据发送给某人，需要使用该人的公钥对数据进行加密，接收加密数据的人员使用相应的私钥对其进行解密。</p> - -<p>与对称密钥加密相比，公钥加密需要更多的计算，因此并不总是适用于大量数据。但是，可以使用公钥加密来发送对称密钥，然后可以使用该对称密钥来加密其他数据。这是SSL协议使用的方法。</p> - -<p>碰巧，图2所示方案的反面也适用：用您的私钥加密的数据只能用您的公钥解密。然而，这不会是加密敏感数据的理想方式，因为这意味着任何使用公钥定义的公开密钥都可以解密数据。不过，私钥加密很有用，因为这意味着您可以使用私钥对数据签名，这对于电子商务和其他密码学商业应用来说是一个重要要求。客户端软件例如Firefox接着可以使用你的公钥去确认这消息是否是被你的私钥签名和是否在签名之后被篡改。“数字签名”描述了此确认过程的工作原理。</p> - -<h3 id="Key_Length_and_Encryption_Strength" name="Key_Length_and_Encryption_Strength">密钥长度和加密强度</h3> - -<p>打破加密算法基本上是找到以纯文本访问加密数据的关键。对于对称算法，打破算法通常意味着试图确定用于加密文本的密钥。对于公钥算法，打破算法通常意味着获取两个接收者之间的共享秘密信息。</p> - -<p>破坏对称算法的一种方法是简单地尝试整个算法中的每个密钥，直到找到正确的密钥。对于公开密钥算法，由于密钥对的一半是公开的，所以另一半（私钥）可以使用发布的，但复杂的数学计算来导出。手工找到破解算法的关键就是蛮力攻击。</p> - -<p>打破算法引入了拦截，甚至模仿和欺骗性验证私人信息的风险。</p> - -<p>算法的关键优势在于找到最快的方法来破解算法并将其与蛮力攻击相比较。</p> - -<p>对于对称密钥，加密强度通常以用于执行加密的密钥的大小或长度来描述：通常，较长的密钥提供更强的加密。密钥长度以位为单位进行测量。例如，与SSL支持的RC4对称密钥密码一起使用的128位密钥提供比用于相同密码的40位密钥更好的加密保护。大致来讲，128位RC4加密比40位RC4加密强 3 x 10<sup>26</sup>倍。（有关用于SSL的RC4和其他密码的更多信息，参见“<a href="/en/Introduction_to_SSL" title="en/Introduction_to_SSL">SSL介绍</a>.") 如果最有名的破解密钥的攻击速度不比蛮力试图测试每个关键可能性的速度快，那么加密密钥就被认为是完备性密钥。</p> - -<p>不同的密码可能需要不同的密钥长度才能达到相同级别的加密强度。例如，用于公钥加密的RSA密码，由于其所基于的数学问题的性质，对于给定长度的密钥只能使用所有可能值的子集。其他密码，例如那些用于对称密钥加密的密码，可以为给定长度的密钥使用所有可能的值，而不是这些值的子集。</p> - -<p>因为破解RSA密钥相对简单，RSA公钥加密密码必须有一个非常长的密钥（至少1024位）被认为是密码强的。另一方面，对于大多数算法，对称密钥密码可以达到与80位密钥大致相同的强度水平。</p> - - - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> - -<ul> - <li>Author(s): Ella Deon Lackey</li> - <li>Translator: Tommy White</li> - <li>Last Updated Date: 2012</li> - <li>Last Translated Date: 2018</li> - <li>Copyright Information: © 2012 Red Hat, Inc.</li> - <li>Link: <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System_Common_Criteria_Certification/8.1/html/Deploy_and_Install_Guide/index.html">Red Hat Certificate System Common Criteria Certification 8.1: Deployment, Planning, and Installation</a></li> -</ul> -</div> diff --git a/files/zh-cn/archive/security/index.html b/files/zh-cn/archive/security/index.html deleted file mode 100644 index 63e3a0821e..0000000000 --- a/files/zh-cn/archive/security/index.html +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Security -slug: Archive/Security -tags: - - NeedsTranslation - - TopicStub -translation_of: Archive/Security ---- -<p><strong><span class="seoSummary">Relying on these obsolete security articles is highly discouraged. Doing so may put your systems at risk.</span></strong></p> - -<p></p><div class="row topicpage-table"> - <div class="section"><dl><dl><dt></dt></dl></dl></div> - <div class="section"><dl><dt class="landingPageList"><a href="/zh-CN/docs/Archive/Security/Encryption_and_Decryption">Encryption and Decryption</a></dt><dd class="landingPageList">加密是使预期参与者外的仍何人不可知的的信息转换过程。解密是加密的反过程以便让信息可理解。一个加密算法也被称作暗号，是一个数学函数用于加解密。大多数情况使用两个相关联函数，一个用于加密一个用于解密。</dd></dl></div> - </div><p></p> diff --git a/files/zh-cn/archive/security/introduction_to_public-key_cryptography/index.html b/files/zh-cn/archive/security/introduction_to_public-key_cryptography/index.html deleted file mode 100644 index b96f91ddd0..0000000000 --- a/files/zh-cn/archive/security/introduction_to_public-key_cryptography/index.html +++ /dev/null @@ -1,475 +0,0 @@ ---- -title: Introduction to Public-Key Cryptography -slug: Archive/Security/Introduction_to_Public-Key_Cryptography -translation_of: Archive/Security/Introduction_to_Public-Key_Cryptography ---- -<p>公钥密码及相关标准和技术是许多产品（如签名和加密电子邮件、单点登录和安全套接字层（SSL）通信）安全功能的基础。本文介绍了公钥密码的基本概念。For an overview of SSL, see "<a href="/en-US/docs/Archive/Security/Introduction_to_SSL" title="en/Introduction_to_SSL">Introduction to SSL</a>." For an overview of encryption and decryption, see "<a href="/en-US/docs/Encryption_and_Decryption">Encryption and Decryption</a>." Information on digital signatures is available from "<a href="/en-US/docs/Digital_Signatures">Digital Signatures</a>."</p> - -<p>公钥密码是一套成熟的技术和标准，用于保护通信免受窃听、篡改和模拟攻击.</p> - -<ul> - <li>加密和解密允许两个通信方伪装他们发送给对方的信息. 发送者在发送信息之前对其进行加密. 接收者在接收到信息后对其进行解密. 在传输过程中，入侵者无法理解加密信息.</li> - <li>篡改检测允许信息接收者验证信息在传输过程中没有被修改. 任何修改数据或替换假消息的尝试都将被检测到.</li> - <li>身份验证允许信息的接收者确定其来源，即确认发送者的身份.</li> - <li>不可否认性防止信息发送者在以后的日期声称信息从未被发送.</li> -</ul> - -<p>以下各节介绍了构成这些功能基础的公钥加密的概念.</p> - -<ul> - <li><a href="#Certificates_and_Authentication">证书和认证</a></li> - <li><a href="#Managing_Certificates">管理证书</a></li> -</ul> - -<p><font face="x-locale-heading-primary, zillaslab, Palatino, Palatino Linotype, x-locale-heading-secondary, serif"><span style="font-size: 37.33327865600586px;"><strong>证书和认证</strong></span></font></p> - -<ul> - <li><a href="#A_Certificate_Identifies_Someone_or_Something">证书证明某人或某事</a></li> - <li><a href="#Authentication_Confirms_an_Identity">身份验证</a></li> - <li><a href="#How_Certificates_Are_Used">证书应用</a></li> - <li><a href="#Contents_of_a_Certificate">证书内容</a></li> - <li><a href="#How_CA_Certificates_Are_Used_to_Establish_Trust">如何使用CA证书建立信任</a></li> -</ul> - -<h3 id="A_Certificate_Identifies_Someone_or_Something" name="A_Certificate_Identifies_Someone_or_Something">证书证明某人或某事</h3> - -<p>A <em>certificate</em> is an electronic document used to identify an individual, a server, a company, or some other entity and to associate that identity with a public key. Like a driver's license, a passport, or other commonly used personal IDs, a certificate provides generally recognized proof of a person's identity. Public-key cryptography uses certificates to address the problem of impersonation.</p> - -<p>To get a driver's license, you typically apply to a government agency, such as the Department of Motor Vehicles, which verifies your identity, your ability to drive, your address, and other information before issuing the license. To get a student ID, you apply to a school or college, which performs different checks (such as whether you have paid your tuition) before issuing the ID. To get a library card, you may need to provide only your name and a utility bill with your address on it.</p> - -<p>Certificates work much the same way as any of these familiar forms of identification. 证书颁发机构（CA）是验证身份并颁发证书的实体. 它们可以是独立的第三方，也可以是运行自己的证书颁发服务器软件（如红帽证书系统）的组织. 验证身份所用的方法因给定CA的策略而异，正如验证其他形式的身份所用的方法因颁发ID的人和使用ID的目的而异. In general, before issuing a certificate, the CA must use its published verification procedures for that type of certificate to ensure that an entity requesting a certificate is in fact who it claims to be.</p> - -<p>CA颁发的证书将特定的公钥绑定到证书标识的实体的名称（例如雇员或服务器的名称）. 证书有助于防止使用假公钥进行模拟. 只有经过证书认证的公钥才能与证书标识的实体所拥有的相应私钥一起使用.</p> - -<p>除了公钥之外，证书还始终包括它标识的实体的名称、过期日期、颁发证书的CA的名称、序列号和其他信息. 最重要的是，证书总是包含颁发CA的数字签名. CA的数字签名允许证书作为“介绍信”使用，这些用户知道并信任CA，但不知道证书标识的实体.</p> - -<p>For more information about the role of CAs, see "<a href="#How_CA_Certificates_Are_Used_to_Establish_Trust">How CA Certificates Are Used to Establish Trust</a>".</p> - -<h3 id="Authentication_Confirms_an_Identity" name="Authentication_Confirms_an_Identity">身份验证</h3> - -<p><em>Authentication</em> is the process of confirming an identity. In the context of network interactions, authentication involves the confident identification of one party by another party. Authentication over networks can take many forms. Certificates are one way of supporting authentication.</p> - -<p>Network interactions typically take place between a client, such as browser software running on a personal computer, and a server, such as the software and hardware used to host a Web site. <em>Client authentication</em> refers to the confident identification of a client by a server (that is, identification of the person assumed to be using the client software). <em>Server authentication</em> refers to the confident identification of a server by a client (that is, identification of the organization assumed to be responsible for the server at a particular network address).</p> - -<p>Client and server authentication are not the only forms of authentication that certificates support. For example, the digital signature on an email message, combined with the certificate that identifies the sender, provide strong evidence that the person identified by that certificate did indeed send that message. Similarly, a digital signature on an HTML form, combined with a certificate that identifies the signer, can provide evidence, after the fact, that the person identified by that certificate did agree to the contents of the form. In addition to authentication, the digital signature in both cases ensures a degree of nonrepudiation-that is, a digital signature makes it difficult for the signer to claim later not to have sent the email or the form.</p> - -<p>Client authentication is an essential element of network security within most intranets or extranets. The sections that follow contrast two forms of client authentication:</p> - -<ul> - <li><strong>Password-Based Authentication.</strong> Almost all server software permits client authentication by means of a name and password. For example, a server might require a user to type a name and password before granting access to the server. The server maintains a list of names and passwords; if a particular name is on the list, and if the user types the correct password, the server grants access.</li> - <li><strong>Certificate-Based Authentication.</strong> 基于证书的客户端身份验证是SSL协议的一部分. 客户端对随机生成的数据进行数字签名，并通过网络发送证书和签名数据. 服务器使用公钥密码技术验证签名并确认证书的有效性.</li> -</ul> - -<h4 id="Password-Based_Authentication" name="Password-Based_Authentication">Password-Based Authentication</h4> - -<p>Figure 4 shows the basic steps involved in authenticating a client by means of a name and password. Figure 4 assumes the following:</p> - -<ul> - <li>The user has already decided to trust the server, either without authentication or on the basis of server authentication via SSL.</li> - <li>The user has requested a resource controlled by the server.</li> - <li>The server requires client authentication before permitting access to the requested resource.</li> -</ul> - -<p><img alt="Figure 4. Using a Password to Authenticate a Client to a Server" class="internal" src="https://mdn.mozillademos.org/files/10319/01pswd.png" style="height: 189px; width: 451px;"></p> - -<p>These are the steps shown in Figure 4<span class="nowiki">:</span></p> - -<ol> - <li>In response to an authentication request from the server, the client displays a dialog box requesting the user's name and password for that server. The user must supply a name and password separately for each new server the user wishes to use during a work session.</li> - <li>The client sends the name and password across the network, either in the clear or over an encrypted SSL connection.</li> - <li>The server looks up the name and password in its local password database and, if they match, accepts them as evidence authenticating the user's identity.</li> - <li>The server determines whether the identified user is permitted to access the requested resource, and if so allows the client to access it.</li> -</ol> - -<p>With this arrangement, the user must supply a new password for each server, and the administrator must keep track of the name and password for each user, typically on separate servers.</p> - -<p>Proper implementation does not store passwords in plaintext. Instead it concatenates the password with a random per-user value (so called "salt") and stores the hash value of the result along with the salt. This makes certain kinds of brute-force atacks more difficult.</p> - -<p>As shown in the next section, one of the advantages of certificate-based authentication is that it can be used to replace the first three steps in Figure 4 with a mechanism that allows the user to supply just one password (which is not sent across the network) and allows the administrator to control user authentication centrally.</p> - -<h4 id="Certificate-Based_Authentication" name="Certificate-Based_Authentication">Certificate-Based Authentication</h4> - -<p>图5显示了如何使用证书和SSL协议进行客户端身份验证. 为了向服务器验证用户身份，客户端对随机生成的数据进行数字签名，并通过网络发送证书和签名数据.在本讨论中，可以将与某些数据相关联的数字签名视为客户端向服务器提供的证据. 服务器根据此证据验证用户的身份.</p> - -<p>与图4一样，图5假设用户已经决定信任服务器并请求了资源，并且服务器在评估是否授予对请求的资源的访问权限的过程中请求了客户端身份验证.</p> - -<p><img alt="Figure 5. Using a Certificate to Authenticate a Client to a Server" class="internal" src="https://mdn.mozillademos.org/files/10321/02cert.png" style="height: 248px; width: 479px;"></p> - -<p>与图4所示的过程不同，图5所示的过程需要使用SSL. 图5还假设客户端有一个有效的证书，可以用来向服务器标识客户端. 基于证书的身份验证通常被认为比基于密码的身份验证更可取，因为它基于用户所拥有的（私钥）以及用户所知道的（保护私钥的密码）. 但是，需要注意的是，只有在未经授权的人员没有访问用户的机器或密码、设置了客户端软件的私钥数据库的密码以及设置软件以合理的频繁间隔请求密码的情况下，这两个假设才是真的.</p> - -<div class="note">基于密码的身份验证或基于证书的身份验证都不能解决与对单个计算机或密码的物理访问相关的安全问题. 公钥密码只能验证用于签名某些数据的私钥是否与证书中的公钥对应. 用户有责任保护机器的物理安全并对私钥密码保密.</div> - -<p>These are the steps shown in Figure 5<span class="nowiki">:</span></p> - -<ol> - <li>客户端软件（如Communicator）维护私钥数据库，这些私钥对应于为该客户端颁发的任何证书中发布的公钥. 客户端在给定会话期间第一次需要访问该数据库时（例如，用户第一次尝试访问需要基于证书的客户机身份验证的启用了SSL的服务器时），会请求该数据库的密码. 输入此密码一次后，用户在会话的其余部分不需要再次输入，即使在访问其他启用SSL的服务器时也是如此.</li> - <li>客户端解锁私钥数据库，检索用户证书的私钥，并使用该私钥对根据客户端和服务器的输入随机生成的一些数据进行数字签名. 这些数据和数字签名构成了私钥有效性的“证据”. 数字签名只能使用该私钥创建，并且可以使用对应的公钥针对已签名的数据进行验证，该数据对于SSL会话是唯一的.</li> - <li>客户端通过网络发送用户证书和证据（随机生成的经过数字签名的数据片段）.</li> - <li>服务器使用证书和证据来验证用户的身份. (For a detailed discussion of the way this works, see "<a href="/en-US/docs/Archive/Security/Introduction_to_SSL" title="en/Introduction_to_SSL">Introduction to SSL</a>.")</li> - <li>At this point the server may optionally perform other authentication tasks, such as checking that the certificate presented by the client is stored in the user's entry in an LDAP directory. The server then continues to evaluate whether the identified user is permitted to access the requested resource. This evaluation process can employ a variety of standard authorization mechanisms, potentially using additional information in an LDAP directory, company databases, and so on. If the result of the evaluation is positive, the server allows the client to access the requested resource.</li> -</ol> - -<p>As you can see by comparing Figure 5 to Figure 4, certificates replace the authentication portion of the interaction between the client and the server. Instead of requiring a user to send passwords across the network throughout the day, single sign-on requires the user to enter the private-key database password just once, without sending it across the network. For the rest of the session, the client presents the user's certificate to authenticate the user to each new server it encounters. Existing authorization mechanisms based on the authenticated user identity are not affected.</p> - -<h3 id="How_Certificates_Are_Used" name="How_Certificates_Are_Used">证书应用</h3> - -<p>证书有一个目的：建立信任. 它们的使用取决于它们用于确保的信任类型. 某些类型的证书用于验证演示者的身份; 其他用于验证对象或项未被篡改.</p> - -<ul> - <li><a href="#SSL_Protocol">SSL Protocol</a></li> - <li><a href="#Signed_and_Encrypted_Email">Signed and Encrypted Email</a></li> - <li><a href="#Signle_Sign-On">Single Sign-On</a></li> - <li><a href="#Object_Signing">Object Signing</a></li> -</ul> - -<h4 id="SSL_Protocol" name="SSL_Protocol">SSL Protocol</h4> - -<p>安全套接字层（SSL）协议是一组规则，用于管理服务器身份验证、客户端身份验证以及服务器和客户端之间的加密通信. SSL在Internet上广泛使用，特别是用于涉及交换机密信息（如信用卡号码）的交互.</p> - -<p>SSL至少需要一个服务器SSL证书. 作为初始“握手”过程的一部分，服务器向客户机提供其证书以验证服务器的身份. 身份验证过程使用公钥加密和数字签名来确认服务器实际上就是它声称的服务器. 一旦服务器经过身份验证，客户机和服务器就使用对称密钥加密技术（这是非常快速的），对它们在会话剩余时间内交换的所有信息进行加密，并检测可能发生的任何篡改.</p> - -<p>可以选择将服务器配置为需要客户端身份验证和服务器身份验证. 在这种情况下，在成功完成服务器身份验证之后，客户端还必须向服务器提供其证书，以便在建立加密的SSL会话之前验证客户端的身份.</p> - -<p>For an overview of client authentication over SSL and how it differs from password-based authentication, see "<a href="#Authentication_Confirms_an_Identity">Authentication Confirms an Identity</a>". For more detailed information about SSL, see "<a href="/en-US/docs/Archive/Security/Introduction_to_SSL" title="en/Introduction_to_SSL">Introduction to SSL</a>."</p> - -<h4 id="Signed_and_Encrypted_Email" name="Signed_and_Encrypted_Email">Signed and Encrypted Email</h4> - -<p>Some email programs support digitally signed and encrypted email using a widely accepted protocol known as Secure Multipurpose Internet Mail Extension (S/MIME). Using S/MIME to sign or encrypt email messages requires the sender of the message to have an S/MIME certificate.</p> - -<p>An email message that includes a digital signature provides some assurance that it was in fact sent by the person whose name appears in the message header, thus providing authentication of the sender. If the digital signature cannot be validated by the email software on the receiving end, the user will be alerted.</p> - -<p>The digital signature is unique to the message it accompanies. If the message received differs in any way from the message that was sent-even by the addition or deletion of a comma-the digital signature cannot be validated. Therefore, signed email also provides some assurance that the email has not been tampered with. As discussed at the beginning of this document, this kind of assurance is known as nonrepudiation. In other words, signed email makes it very difficult for the sender to deny having sent the message. This is important for many forms of business communication. (For information about the way digital signatures work, see "<a href="#Digital_Signatures">Digital Signatures</a>".)</p> - -<p>S/MIME also makes it possible to encrypt email messages. This is also important for some business users. However, using encryption for email requires careful planning. If the recipient of encrypted email messages loses his or her private key and does not have access to a backup copy of the key, for example, the encrypted messages can never be decrypted.</p> - -<h4 id="Single_Sign-On" name="Single_Sign-On">Single Sign-On</h4> - -<p>Network users are frequently required to remember multiple passwords for the various services they use. For example, a user might have to type a different password to log into the network, collect email, use directory services, use the corporate calendar program, and access various servers. Multiple passwords are an ongoing headache for both users and system administrators. Users have difficulty keeping track of different passwords, tend to choose poor ones, and tend to write them down in obvious places. Administrators must keep track of a separate password database on each server and deal with potential security problems related to the fact that passwords are sent over the network routinely and frequently.</p> - -<p>Solving this problem requires some way for a user to log in once, using a single password, and get authenticated access to all network resources that user is authorized to use-without sending any passwords over the network. This capability is known as <em>single sign-on.</em></p> - -<p>Both client SSL certificates and S/MIME certificates can play a significant role in a comprehensive single sign-on solution. For example, one form of single sign-on relies on SSL client authentication (see "<a href="#Certificate-Based_Authentication">Certificate-Based Authentication</a>"). A user can log in once, using a single password to the local client's private-key database, and get authenticated access to all SSL-enabled servers that user is authorized to use-without sending any passwords over the network. This approach simplifies access for users, because they don't need to enter passwords for each new server. It also simplifies network management, since administrators can control access by controlling lists of certificate authorities (CAs) rather than much longer lists of users and passwords.</p> - -<p>In addition to using certificates, a complete single-sign on solution must address the need to interoperate with enterprise systems, such as the underlying operating system, that rely on passwords or other forms of authentication.</p> - -<h4 id="Object_Signing" name="Object_Signing">Object Signing</h4> - -<p>通信器支持一组称为对象签名的工具和技术. 对象签名使用公钥加密的标准技术，使用户可以获得关于他们下载的代码的可靠信息，就像他们可以获得关于收缩包装软件的可靠信息一样.</p> - -<p>最重要的是，对象签名帮助用户和网络管理员实现有关通过内部网或Internet分发的软件的决策，例如，是否允许由给定实体签名的Java小程序在特定用户的计算机上使用特定的计算机功能.</p> - -<p>使用对象签名技术签名的“对象”可以是applet或其他Java代码、JavaScript脚本、插件或任何类型的文件. “签名”是数字签名. 签名对象及其签名通常存储在一个称为JAR文件的特殊文件中.</p> - -<p>希望使用对象签名技术对文件进行签名的软件开发人员和其他人员必须首先获得对象签名证书.</p> - -<h3 id="Contents_of_a_Certificate" name="Contents_of_a_Certificate">证书类型</h3> - -<p>常见的证书类型包括:</p> - -<ul> - <li><strong>Client SSL certificates.</strong> 用于通过SSL（客户端身份验证）将客户端标识到服务器. 通常，假定客户的身份与人类的身份相同，例如企业中的员工. See "<a href="#Certificate-Based_Authentication">Certificate-Based Authentication</a>" for a description of the way client SSL certificates are used for client authentication. Client SSL certificates can also be used as part of a single sign-on solution.</li> -</ul> - -<dl> - <dt>示例：银行向客户提供一个客户端SSL证书，该证书允许银行的服务器识别该客户并授权访问该客户的帐户. 公司可能会给新员工一个客户端SSL证书，允许公司的服务器识别该员工并授权访问公司的服务器.</dt> -</dl> - -<ul> - <li><strong>Server SSL certificates.</strong> 用于通过SSL（服务器身份验证）向客户端标识服务器. 服务器身份验证可以与客户端身份验证一起使用，也可以不使用客户端身份验证. 服务器身份验证是加密SSL会话的要求. For more information, see "<a href="#SSL_Protocol">SSL Protocol</a>".</li> -</ul> - -<dl> - <dt><strong>Example:</strong> Internet sites that engage in electronic commerce (commonly known as e-commerce) usually support certificate-based server authentication, at a minimum, to establish an encrypted SSL session and to assure customers that they are dealing with a web site identified with a particular company. The encrypted SSL session ensures that personal information sent over the network, such as credit card numbers, cannot easily be intercepted.</dt> -</dl> - -<ul> - <li><strong>S/MIME certificates.</strong> Used for signed and encrypted email. As with client SSL certificates, the identity of the client is typically assumed to be the same as the identity of a human being, such as an employee in an enterprise. A single certificate may be used as both an S/MIME certificate and an SSL certificate (see "<a href="#Signed_and_Encrypted_Email">Signed and Encrypted Email</a>"). S/MIME certificates can also be used as part of a single sign-on solution.</li> -</ul> - -<dl> - <dt><strong>Examples:</strong> A company deploys combined S/MIME and SSL certificates solely for the purpose of authenticating employee identities, thus permitting signed email and client SSL authentication but not encrypted email. Another company issues S/MIME certificates solely for the purpose of both signing and encrypting email that deals with sensitive financial or legal matters.</dt> -</dl> - -<ul> - <li><strong>Object-signing certificates.</strong> Used to identify signers of Java code, JavaScript scripts, or other signed files. For more information, see "<a href="#Object_Signing">Object Signing</a>".</li> -</ul> - -<dl> - <dt><strong>Example:</strong> A software company signs software distributed over the Internet to provide users with some assurance that the software is a legitimate product of that company. Using certificates and digital signatures in this manner can also make it possible for users to identify and control the kind of access downloaded software has to their computers.</dt> -</dl> - -<ul> - <li><strong>CA certificates.</strong> 用于识别CA. 客户端和服务器软件使用CA证书来确定哪些其他证书可以被信任. For more information, see "<a href="#How_CA_Certificates_Are_Used_to_Establish_Trust">How CA Certificates Are Used to Establish Trust</a>".</li> -</ul> - -<dl> - <dt>示例：存储在Firefox中的CA证书决定了Firefox副本可以验证的其他证书。管理员可以通过控制存储在每个用户的Firefox副本中的CA证书来实现公司安全策略的某些方面。</dt> -</dl> - -<h3 id="证书内容">证书内容</h3> - -<p>The contents of certificates are organized according to the X.509 v3 certificate specification, which has been recommended by the International Telecommunications Union (ITU), an international standards body, since 1988.</p> - -<p>Users don't usually need to be concerned about the exact contents of a certificate. However, system administrators working with certificates may need some familiarity with the information provided here.</p> - -<h4 id="Certificate_Data_Formats">Certificate Data Formats</h4> - -<p>Certificate requests and certificates can be created, stored, and installed in multiple formats: binary and text. All of these formats conform to X.509 standards. Three examples of binary formats are DER-encoded certificates, PKCS #7 certificate chains, and Netscape Certificate Sequence. Any of the binary formats can be imported in text form, which begins with the line:</p> - -<p><code>-----BEGIN CERTIFICATE-----</code></p> - -<p>Following this line is the certificate data, which can be in any of the binary formats described. This data should be base-64 encoded, as described by RFC 1113. The certificate information is followed by this line:</p> - -<p><code>-----END CERTIFICATE-----</code></p> - -<h4 id="Distinguished_Names" name="Distinguished_Names">Distinguished Names</h4> - -<p>An X.509 v3 certificate binds a distinguished name (DN) to a public key. A DN is a series of name-value pairs, such as <code>uid=doe</code>, that uniquely identify an entity-that is, the certificate <em>subject.</em></p> - -<p>For example, this might be a typical DN for an employee of Example Corp:</p> - -<pre class="eval">uid=doe,e=doe@<code>example.net</code>,cn=John Doe,o=Example Corp.,c=US -</pre> - -<p>The abbreviations before each equal sign in this example have these meanings:</p> - -<ul> - <li><code>uid</code><span class="nowiki">: user ID</span></li> - <li><code>e</code><span class="nowiki">: email address</span></li> - <li><code>cn</code><span class="nowiki">: the user's common name</span></li> - <li><code>o</code><span class="nowiki">: organization</span></li> - <li><code>c</code><span class="nowiki">: country</span></li> -</ul> - -<p>DNs may include a variety of other name-value pairs. They are used to identify both certificate subjects and entries in directories that support the Lightweight Directory Access Protocol (LDAP).</p> - -<p>The rules governing the construction of DNs can be quite complex and are beyond the scope of this document. For comprehensive information about DNs, see <em><a class="external" href="https://www.ietf.org/rfc/rfc1485.txt">A String Representation of Distinguished Names</a>]</em> at the following URL:</p> - -<pre class="eval"><a class="external" href="https://www.ietf.org/rfc/rfc1485.txt" rel="freelink">https://www.ietf.org/rfc/rfc1485.txt</a> -</pre> - -<h4 id="A_Typical_Certificate" name="A_Typical_Certificate">A Typical Certificate</h4> - -<p>Every X.509 certificate consists of two sections:</p> - -<ul> - <li>The data section includes the following information: - <ul> - <li>The version number of the X.509 standard supported by the certificate.</li> - <li>The certificate's serial number. Every certificate issued by a CA has a serial number that is unique among the certificates issued by that CA.</li> - <li>Information about the user's public key, including the algorithm used and a representation of the key itself.</li> - <li>The DN of the CA that issued the certificate.</li> - <li>The period during which the certificate is valid (for example, between 1:00 p.m. on November 15, 1999 and 1:00 p.m. November 15, 2000)</li> - <li>The DN of the certificate subject (for example, in a client SSL certificate this would be the user's DN), also called the subject name.</li> - <li>Optional <em>certificate extensions,</em> which may provide additional data used by the client or server. For example, the certificate type extension indicates the type of certificate-that is, whether it is a client SSL certificate, a server SSL certificate, a certificate for signing email, and so on. Certificate extensions can also be used for a variety of other purposes.</li> - </ul> - </li> - <li>The signature section includes the following information: - <ul> - <li>The cryptographic algorithm, or cipher, used by the issuing CA to create its own digital signature.</li> - <li>The CA's digital signature, obtained by hashing all of the data in the certificate together and encrypting it with the CA's private key.</li> - </ul> - </li> -</ul> - -<p>Here are the data and signature sections of a certificate in human-readable format:</p> - -<pre class="eval">Certificate: -Data: - Version: v3 (0x2) - Serial Number: 3 (0x3) - Signature Algorithm: PKCS #1 MD5 With RSA Encryption - Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US - Validity: - Not Before: Fri Oct 17 18:36:25 1997 - Not After: Sun Oct 17 18:36:25 1999 - Subject: CN=Jane Doe, OU=Finance, O=Ace Industry, C=US - Subject Public Key Info: - Algorithm: PKCS #1 RSA Encryption - Public Key: - Modulus: - 00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86: - ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22: - 43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00: - 98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9: - 73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e: - 9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0: - 7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54: - 91:f4:15 - Public Exponent: 65537 (0x10001) - Extensions: - Identifier: Certificate Type - Critical: no - Certified Usage: - SSL Client - Identifier: Authority Key Identifier - Critical: no - Key Identifier: - f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36: - 26:c9 - Signature: - Algorithm: PKCS #1 MD5 With RSA Encryption - Signature: - 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06: - 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb: - f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc: - 2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5: - b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5: - 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8: - d:c4 -</pre> - -<p>Here is the same certificate displayed in the 64-byte-encoded form interpreted by software:</p> - -<pre class="eval"><span class="nowiki"> - -----BEGIN CERTIFICATE----- - MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER - MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw - MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK - EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0 - dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG - 7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L - iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ - NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV - HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt - I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3 - UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84 - hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A== - -----END CERTIFICATE----- - </span> -</pre> - -<h3 id="How_CA_Certificates_Are_Used_to_Establish_Trust" name="How_CA_Certificates_Are_Used_to_Establish_Trust">如何使用CA证书建立信任</h3> - -<p>证书颁发机构（CA）是验证身份并颁发证书的实体。它们可以是独立的第三方，也可以是运行自己的证书颁发服务器软件的组织。</p> - -<p>任何支持证书的客户端或服务器软件都维护一组受信任的CA证书。 这些CA证书确定软件可以验证哪些其他证书，换句话说，软件可以信任哪些证书的颁发者。 在最简单的情况下，软件只能验证由其中一个拥有证书的CA颁发的证书。 受信任的CA证书也可能是CA证书链的一部分，每个证书链都是由其上面的CA在证书层次结构中颁发的。</p> - -<p>以下各节说明了证书层次结构和证书链如何确定软件可以信任哪些证书。</p> - -<ul> - <li><a href="#CA_Hierarchies">CA Hierarchies</a></li> - <li><a href="#Certificate_Chains">Certificate Chains</a></li> - <li><a href="#Verifying_a_Certificate_Chain">Verifying a Certificate Chain</a></li> -</ul> - -<h4 id="CA_Hierarchies" name="CA_Hierarchies">CA Hierarchies</h4> - -<p>在大型组织中，可以将颁发证书的责任委派给多个不同的证书颁发机构。 例如，所需的证书数量可能太多，单个CA无法维护； 不同的组织单元可能有不同的政策要求；或者，对于CA来说，其实际位置可能与它向其颁发证书的人位于同一地理区域中是很重要的。</p> - -<p>可以将颁发证书的职责委托给下级CA。X.509标准包括一个用于建立如图6所示的CA层次结构的模型。</p> - -<p><img alt="Figure 6. Example of a Hierarchy of Certificate Authorities" class="internal" src="https://mdn.mozillademos.org/files/10309/14HIER.png" style="height: 317px; width: 394px;"></p> - -<p>在这个模型中，根CA位于层次结构的顶部。 根CA的证书是一个自签名证书：也就是说，该证书由证书标识的根CA所在的同一实体进行数字签名。 直接隶属于根CA的CA具有由根CA签名的CA证书。 层次结构中下级CA下的CA的CA证书由上级下级CA签名。</p> - -<p>组织在建立CA层次结构方面有很大的灵活性。 图6只显示了一个示例；还有许多其他安排是可能的。</p> - -<h4 id="Certificate_Chains" name="Certificate_Chains">Certificate Chains</h4> - -<p>CA层次结构反映在证书链中。 证书链是由连续的ca颁发的一系列证书。图7显示了一个证书链，从通过两个从属CA证书标识某个实体的证书到根CA的CA证书（基于图6所示的CA层次结构）。</p> - -<p><img alt="Figure 7. Example of a Certificate Chain" class="internal" src="https://mdn.mozillademos.org/files/10311/15chn.png" style="height: 435px; width: 439px;"></p> - -<p>证书链跟踪证书从层次结构中的分支到层次结构的根的路径。 I在证书链中，会发生以下情况：</p> - -<ul> - <li>每个证书后面都有其颁发者的证书。</li> - <li>每个证书都包含该证书颁发者的名称（DN），该名称与链中下一个证书的使用者名称相同。</li> -</ul> - -<p>在图7中，工程CA证书包含颁发该证书的CA（即USA CA）的DN。 USA CA的DN也是链中下一个证书的使用者名称。</p> - -<ul> - <li>每个证书都用其颁发者的私钥签名。签名可以使用颁发者证书中的公钥进行验证，该证书是链中的下一个证书。</li> -</ul> - -<p>在图7中，美国CA证书中的公钥可用于验证美国CA在工程CA证书上的数字签名。</p> - -<h4 id="Verifying_a_Certificate_Chain" name="Verifying_a_Certificate_Chain">Verifying a Certificate Chain</h4> - -<p>Certificate chain verification is the process of making sure a given certificate chain is well-formed, valid, properly signed, and trustworthy. Red Hat software uses the following procedure for forming and verifying a certificate chain, starting with the certificate being presented for authentication:</p> - -<ol> - <li>The certificate validity period is checked against the current time provided by the verifier's system clock.</li> - <li>The issuer's certificate is located. The source can be either the verifier's local certificate database (on that client or server) or the certificate chain provided by the subject (for example, over an SSL connection).</li> - <li>The certificate signature is verified using the public key in the issuer's certificate.</li> - <li>If the issuer's certificate is trusted by the verifier in the verifier's certificate database, verification stops successfully here. Otherwise, the issuer's certificate is checked to make sure it contains the appropriate subordinate CA indication in the Red Hat certificate type extension, and chain verification returns to step 1 to start again, but with this new certificate. Figure 8 presents an example of this process.</li> -</ol> - -<p><img alt="Figure 8. Verifying a Certificate Chain All the Way to the Root CA" class="internal" src="https://mdn.mozillademos.org/files/10313/16chver.png" style="height: 412px; width: 460px;"></p> - -<p>Figure 8 shows what happens when only Root CA is included in the verifier's local database. If a certificate for one of the intermediate CAs shown in Figure 8, such as Engineering CA, is found in the verifier's local database, verification stops with that certificate, as shown in Figure 9.</p> - -<p><img alt="Figure 9. Verifying a Certificate Chain to an Intermediate CA" class="internal" src="https://mdn.mozillademos.org/files/10315/19chver.png" style="height: 233px; width: 446px;"></p> - -<p>Expired validity dates, an invalid signature, or the absence of a certificate for the issuing CA at any point in the certificate chain causes authentication to fail. For example, Figure 10 shows how verification fails if neither the Root CA certificate nor any of the intermediate CA certificates are included in the verifier's local database.</p> - -<p><img alt="Figure 10. A Certificate Chain That Can't Be Verified" class="internal" src="https://mdn.mozillademos.org/files/10317/20chver.png" style="height: 406px; width: 456px;"></p> - -<p>For general information about the way digital signatures work, see "<a href="#Digital_Signatures">Digital Signatures</a>". For a more detailed description of the signature verification process in the context of SSL client and server authentication, see "<a href="/en-US/docs/Archive/Security/Introduction_to_SSL" title="en/Introduction_to_SSL">Introduction to SSL</a>."</p> - -<h2 id="Managing_Certificates" name="Managing_Certificates">Managing Certificates</h2> - -<p>从加密电子邮件到访问网站，许多应用程序都使用证书。 证书的生命周期分为两个主要阶段：颁发证书的时间点（颁发和注册）和证书不再有效的时间段（续订或吊销）。 还有一些方法可以在证书的生命周期中对其进行管理。 使有关证书的信息可用于其他应用程序是发布证书，然后备份密钥对，以便在证书丢失时可以恢复。</p> - -<ul> - <li><a href="#Issuing_Certificates">颁发证书</a></li> - <li><a href="#Certificates_and_the_LDAP_Directory">证书和LDAP目录</a></li> - <li><a href="#Key_Management">密钥管理</a></li> - <li><a href="#Renewing_and_Revoking_Certificates">更新和撤销证书</a></li> - <li><a href="#Registration_Authorities">Registration Authorities</a></li> -</ul> - -<h3 id="Issuing_Certificates" name="Issuing_Certificates">颁发证书</h3> - -<p>颁发证书的过程取决于颁发证书的证书颁发机构及其使用目的。 签发非数字身份证明的程序也有类似的变化。 例如，如果你想从加州机动车辆管理局（Department of Motor Vehicles in California）拿到一张普通身份证（而不是驾照），要求很简单：你需要出示一些身份证明，比如一张写有你地址的公用事业账单和一张学生身份证。 如果你想获得一张正规的驾驶执照，你还需要参加一次考试——第一次拿到驾照时要参加一次驾驶考试，续签驾照时要参加一次笔试。 如果你想得到一个18轮的商业许可证，要求要严格得多。 如果您居住在其他州或国家，对各种许可证的要求将有所不同。</p> - -<p>同样，不同的ca对于颁发不同类型的证书有不同的过程。 在某些情况下，唯一的要求可能是你的电子邮件地址。在其他情况下，您的UNIX或Windows登录名和密码可能就足够了。 在比额表的另一端，对于证明可以批准大额支出或作出其他敏感决定的人的证书，签发过程可能需要公证文件、背景调查和个人面谈。</p> - -<p>根据组织的策略，颁发证书的过程可以从对用户完全透明到需要大量用户参与和复杂的过程不等。 一般来说，颁发证书的过程应该高度灵活，因此组织可以根据其不断变化的需要对其进行调整。</p> - -<p>颁发证书是可以由单独的注册机构处理的几种管理任务之一。</p> - -<h3 id="Certificates_and_the_LDAP_Directory" name="Certificates_and_the_LDAP_Directory">证书和LDAP目录</h3> - -<p>The Lightweight Directory Access Protocol (LDAP) for accessing directory services supports great flexibility in the management of certificates within an organization. System administrators can store much of the information required to manage certificates in an LDAP-compliant directory. For example, a CA can use information in a directory to prepopulate a certificate with a new employee's legal name and other information. The CA can leverage directory information in other ways to issue certificates one at a time or in bulk, using a range of different identification techniques depending on the security policies of a given organization. Other routine management tasks, such as key management and renewing and revoking certificates, can be partially or fully automated with the aid of the directory.</p> - -<p>Information stored in the directory can also be used with certificates to control access to various network resources by different users or groups. Issuing certificates and other certificate management tasks can thus be an integral part of user and group management.</p> - -<p>In general, high-performance directory services are an essential ingredient of any enterprise certificate management strategy.</p> - -<h3 id="Key_Management" name="Key_Management">密钥管理</h3> - -<p>在颁发证书之前，必须生成证书中包含的公钥和相应的私钥。 有时，为一个人颁发一个证书和密钥对（用于签名操作）和另一个证书和密钥对（用于加密操作）可能是有用的。单独的签名和加密证书使得只在本地计算机上保留私有签名密钥成为可能，从而提供最大的不可否认性，并在某个中心位置备份私有加密密钥，在用户丢失原始密钥或离开公司时可以在该位置检索该密钥。</p> - -<p>密钥可以由客户端软件生成，也可以由CA集中生成，并通过LDAP目录分发给用户。 在本地密钥生成和集中密钥生成之间进行选择时需要权衡。例如，本地密钥生成提供了最大的不可否认性，但可能需要用户更多地参与发布过程。灵活的密钥管理能力对于大多数组织来说是必不可少的。</p> - -<p>密钥恢复，或者在精心定义的条件下检索加密密钥备份的能力，可能是证书管理的关键部分（取决于组织如何使用证书）。Key recovery schemes usually involve an <em>m of n</em> mechanism: for example, <em>m</em> of <em>n</em> managers within an organization might have to agree, and each contribute a special code or key of their own, before a particular person's encryption key can be recovered. 这种机制确保在恢复加密密钥之前，必须有几个授权人员同意。</p> - -<h3 id="Renewing_and_Revoking_Certificates" name="Renewing_and_Revoking_Certificates">Renewing and Revoking Certificates</h3> - -<p>Like a driver's license, a certificate specifies a period of time during which it is valid. Attempts to use a certificate for authentication before or after its validity period will fail. Therefore, mechanisms for managing certificate renewal are essential for any certificate management strategy. For example, an administrator may wish to be notified automatically when a certificate is about to expire, so that an appropriate renewal process can be completed in plenty of time without causing the certificate's subject any inconvenience. The renewal process may involve reusing the same public-private key pair or issuing a new one.</p> - -<p>A driver's license can be suspended even if it has not expired-for example, as punishment for a serious driving offense. Similarly, it's sometimes necessary to revoke a certificate before it has expired-for example, if an employee leaves a company or moves to a new job within the company.</p> - -<p>Certificate revocation can be handled in several different ways. For some organizations, it may be sufficient to set up servers so that the authentication process includes checking the directory for the presence of the certificate being presented. When an administrator revokes a certificate, the certificate can be automatically removed from the directory, and subsequent authentication attempts with that certificate will fail even though the certificate remains valid in every other respect. Another approach involves publishing a certificate revocation list (CRL)-that is, a list of revoked certificates-to the directory at regular intervals and checking the list as part of the authentication process. For some organizations, it may be preferable to check directly with the issuing CA each time a certificate is presented for authentication. This procedure is sometimes called real-time status checking.</p> - -<h3 id="Registration_Authorities" name="Registration_Authorities">Registration Authorities</h3> - -<p>由证书标识的实体（有时称为最终实体）和ca之间的交互是证书管理的一个重要部分。 这些交互包括证书注册、证书检索、证书续订、证书吊销以及密钥备份和恢复等操作。一般来说，CA必须能够在响应请求之前验证最终实体的身份。 此外，有些请求需要经过授权的管理员或经理的批准才能提供服务。</p> - -<p>如前所述，不同的ca在颁发证书之前用于验证身份的方法可能有很大的不同，这取决于证书的使用组织和目的。 为了提供最大的操作灵活性，与终端实体的交互可以与CA的其他功能分离，并由一个称为注册机构（RA）的单独服务处理。</p> - -<p>An RA acts as a front end to a CA by receiving end entity requests, authenticating them, and forwarding them to the CA. After receiving a response from the CA, the RA notifies the end entity of the results. RAs can be helpful in scaling an PKI across different departments, geographical areas, or other operational units with varying policies and authentication requirements.</p> - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> - -<ul> - <li>Author(s): Ella Deon Lackey</li> - <li>Last Updated Date: 2012</li> - <li>Copyright Information: © 2012 Red Hat, Inc.</li> - <li>Link: <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System_Common_Criteria_Certification/8.1/html/Deploy_and_Install_Guide/index.html">Red Hat Certificate System Common Criteria Certification 8.1: Deployment, Planning, and Installation</a></li> -</ul> -</div> |