公钥密码及相关标准和技术是许多产品（如签名和加密电子邮件、单点登录和安全套接字层（SSL）通信）安全功能的基础。本文介绍了公钥密码的基本概念。For an overview of SSL, see "Introduction to SSL." For an overview of encryption and decryption, see "Encryption and Decryption." Information on digital signatures is available from "Digital Signatures."
- 加密和解密允许两个通信方伪装他们发送给对方的信息. 发送者在发送信息之前对其进行加密. 接收者在接收到信息后对其进行解密. 在传输过程中，入侵者无法理解加密信息.
- 篡改检测允许信息接收者验证信息在传输过程中没有被修改. 任何修改数据或替换假消息的尝试都将被检测到.
A certificate 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.
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.
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.
CA颁发的证书将特定的公钥绑定到证书标识的实体的名称（例如雇员或服务器的名称）. 证书有助于防止使用假公钥进行模拟. 只有经过证书认证的公钥才能与证书标识的实体所拥有的相应私钥一起使用.
除了公钥之外，证书还始终包括它标识的实体的名称、过期日期、颁发证书的CA的名称、序列号和其他信息. 最重要的是，证书总是包含颁发CA的数字签名. CA的数字签名允许证书作为“介绍信”使用，这些用户知道并信任CA，但不知道证书标识的实体.
For more information about the role of CAs, see "How CA Certificates Are Used to Establish Trust".
Authentication 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.
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. Client authentication refers to the confident identification of a client by a server (that is, identification of the person assumed to be using the client software). Server authentication 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).
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.
Client authentication is an essential element of network security within most intranets or extranets. The sections that follow contrast two forms of client authentication:
- Password-Based Authentication. 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.
- Certificate-Based Authentication. 基于证书的客户端身份验证是SSL协议的一部分. 客户端对随机生成的数据进行数字签名，并通过网络发送证书和签名数据. 服务器使用公钥密码技术验证签名并确认证书的有效性.
Figure 4 shows the basic steps involved in authenticating a client by means of a name and password. Figure 4 assumes the following:
- The user has already decided to trust the server, either without authentication or on the basis of server authentication via SSL.
- The user has requested a resource controlled by the server.
- The server requires client authentication before permitting access to the requested resource.
These are the steps shown in Figure 4:
- 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.
- The client sends the name and password across the network, either in the clear or over an encrypted SSL connection.
- 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.
- The server determines whether the identified user is permitted to access the requested resource, and if so allows the client to access it.
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.
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.
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.
图5显示了如何使用证书和SSL协议进行客户端身份验证. 为了向服务器验证用户身份，客户端对随机生成的数据进行数字签名，并通过网络发送证书和签名数据.在本讨论中，可以将与某些数据相关联的数字签名视为客户端向服务器提供的证据. 服务器根据此证据验证用户的身份.
与图4所示的过程不同，图5所示的过程需要使用SSL. 图5还假设客户端有一个有效的证书，可以用来向服务器标识客户端. 基于证书的身份验证通常被认为比基于密码的身份验证更可取，因为它基于用户所拥有的（私钥）以及用户所知道的（保护私钥的密码）. 但是，需要注意的是，只有在未经授权的人员没有访问用户的机器或密码、设置了客户端软件的私钥数据库的密码以及设置软件以合理的频繁间隔请求密码的情况下，这两个假设才是真的.
These are the steps shown in Figure 5:
- 客户端软件（如Communicator）维护私钥数据库，这些私钥对应于为该客户端颁发的任何证书中发布的公钥. 客户端在给定会话期间第一次需要访问该数据库时（例如，用户第一次尝试访问需要基于证书的客户机身份验证的启用了SSL的服务器时），会请求该数据库的密码. 输入此密码一次后，用户在会话的其余部分不需要再次输入，即使在访问其他启用SSL的服务器时也是如此.
- 客户端解锁私钥数据库，检索用户证书的私钥，并使用该私钥对根据客户端和服务器的输入随机生成的一些数据进行数字签名. 这些数据和数字签名构成了私钥有效性的“证据”. 数字签名只能使用该私钥创建，并且可以使用对应的公钥针对已签名的数据进行验证，该数据对于SSL会话是唯一的.
- 服务器使用证书和证据来验证用户的身份. (For a detailed discussion of the way this works, see "Introduction to SSL.")
- 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.
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.
证书有一个目的：建立信任. 它们的使用取决于它们用于确保的信任类型. 某些类型的证书用于验证演示者的身份; 其他用于验证对象或项未被篡改.
SSL至少需要一个服务器SSL证书. 作为初始“握手”过程的一部分，服务器向客户机提供其证书以验证服务器的身份. 身份验证过程使用公钥加密和数字签名来确认服务器实际上就是它声称的服务器. 一旦服务器经过身份验证，客户机和服务器就使用对称密钥加密技术（这是非常快速的），对它们在会话剩余时间内交换的所有信息进行加密，并检测可能发生的任何篡改.
For an overview of client authentication over SSL and how it differs from password-based authentication, see "Authentication Confirms an Identity". For more detailed information about SSL, see "Introduction to SSL."
Signed and Encrypted Email
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.
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.
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 "Digital Signatures".)
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.
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.
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 single sign-on.
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 "Certificate-Based Authentication"). 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.
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.
- Client SSL certificates. 用于通过SSL（客户端身份验证）将客户端标识到服务器. 通常，假定客户的身份与人类的身份相同，例如企业中的员工. See "Certificate-Based Authentication" 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.
- 示例：银行向客户提供一个客户端SSL证书，该证书允许银行的服务器识别该客户并授权访问该客户的帐户. 公司可能会给新员工一个客户端SSL证书，允许公司的服务器识别该员工并授权访问公司的服务器.
- Server SSL certificates. 用于通过SSL（服务器身份验证）向客户端标识服务器. 服务器身份验证可以与客户端身份验证一起使用，也可以不使用客户端身份验证. 服务器身份验证是加密SSL会话的要求. For more information, see "SSL Protocol".
- Example: 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.
- S/MIME certificates. 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 "Signed and Encrypted Email"). S/MIME certificates can also be used as part of a single sign-on solution.
- Examples: 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.
- Example: 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.
- CA certificates. 用于识别CA. 客户端和服务器软件使用CA证书来确定哪些其他证书可以被信任. For more information, see "How CA Certificates Are Used to Establish Trust".
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.
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.
Certificate Data Formats
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:
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:
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
uid=doe, that uniquely identify an entity-that is, the certificate subject.
For example, this might be a typical DN for an employee of Example Corp:
example.net,cn=John Doe,o=Example Corp.,c=US
The abbreviations before each equal sign in this example have these meanings:
uid: user ID
e: email address
cn: the user's common name
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).
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 A String Representation of Distinguished Names] at the following URL:
A Typical Certificate
Every X.509 certificate consists of two sections:
- The data section includes the following information:
- The version number of the X.509 standard supported by the certificate.
- 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.
- Information about the user's public key, including the algorithm used and a representation of the key itself.
- The DN of the CA that issued the certificate.
- 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)
- 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.
- Optional certificate extensions, 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.
- The signature section includes the following information:
- The cryptographic algorithm, or cipher, used by the issuing CA to create its own digital signature.
- 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.
Here are the data and signature sections of a certificate in human-readable format:
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
Here is the same certificate displayed in the 64-byte-encoded form interpreted by software:
-----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-----
任何支持证书的客户端或服务器软件都维护一组受信任的CA证书。 这些CA证书确定软件可以验证哪些其他证书，换句话说，软件可以信任哪些证书的颁发者。 在最简单的情况下，软件只能验证由其中一个拥有证书的CA颁发的证书。 受信任的CA证书也可能是CA证书链的一部分，每个证书链都是由其上面的CA在证书层次结构中颁发的。
在大型组织中，可以将颁发证书的责任委派给多个不同的证书颁发机构。 例如，所需的证书数量可能太多，单个CA无法维护； 不同的组织单元可能有不同的政策要求；或者，对于CA来说，其实际位置可能与它向其颁发证书的人位于同一地理区域中是很重要的。
在这个模型中，根CA位于层次结构的顶部。 根CA的证书是一个自签名证书：也就是说，该证书由证书标识的根CA所在的同一实体进行数字签名。 直接隶属于根CA的CA具有由根CA签名的CA证书。 层次结构中下级CA下的CA的CA证书由上级下级CA签名。
在图7中，工程CA证书包含颁发该证书的CA（即USA CA）的DN。 USA CA的DN也是链中下一个证书的使用者名称。
Verifying a Certificate Chain
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:
- The certificate validity period is checked against the current time provided by the verifier's system clock.
- 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).
- The certificate signature is verified using the public key in the issuer's certificate.
- 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.
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.
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.
For general information about the way digital signatures work, see "Digital Signatures". For a more detailed description of the signature verification process in the context of SSL client and server authentication, see "Introduction to SSL."
从加密电子邮件到访问网站，许多应用程序都使用证书。 证书的生命周期分为两个主要阶段：颁发证书的时间点（颁发和注册）和证书不再有效的时间段（续订或吊销）。 还有一些方法可以在证书的生命周期中对其进行管理。 使有关证书的信息可用于其他应用程序是发布证书，然后备份密钥对，以便在证书丢失时可以恢复。
颁发证书的过程取决于颁发证书的证书颁发机构及其使用目的。 签发非数字身份证明的程序也有类似的变化。 例如，如果你想从加州机动车辆管理局（Department of Motor Vehicles in California）拿到一张普通身份证（而不是驾照），要求很简单：你需要出示一些身份证明，比如一张写有你地址的公用事业账单和一张学生身份证。 如果你想获得一张正规的驾驶执照，你还需要参加一次考试——第一次拿到驾照时要参加一次驾驶考试，续签驾照时要参加一次笔试。 如果你想得到一个18轮的商业许可证，要求要严格得多。 如果您居住在其他州或国家，对各种许可证的要求将有所不同。
同样，不同的ca对于颁发不同类型的证书有不同的过程。 在某些情况下，唯一的要求可能是你的电子邮件地址。在其他情况下，您的UNIX或Windows登录名和密码可能就足够了。 在比额表的另一端，对于证明可以批准大额支出或作出其他敏感决定的人的证书，签发过程可能需要公证文件、背景调查和个人面谈。
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.
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.
In general, high-performance directory services are an essential ingredient of any enterprise certificate management strategy.
密钥恢复，或者在精心定义的条件下检索加密密钥备份的能力，可能是证书管理的关键部分（取决于组织如何使用证书）。Key recovery schemes usually involve an m of n mechanism: for example, m of n 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. 这种机制确保在恢复加密密钥之前，必须有几个授权人员同意。
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.
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.
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.
由证书标识的实体（有时称为最终实体）和ca之间的交互是证书管理的一个重要部分。 这些交互包括证书注册、证书检索、证书续订、证书吊销以及密钥备份和恢复等操作。一般来说，CA必须能够在响应请求之前验证最终实体的身份。 此外，有些请求需要经过授权的管理员或经理的批准才能提供服务。
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.
Original Document Information
- Author(s): Ella Deon Lackey
- Last Updated Date: 2012
- Copyright Information: © 2012 Red Hat, Inc.
- Link: Red Hat Certificate System Common Criteria Certification 8.1: Deployment, Planning, and Installation