📄 ssl_intro.html.en
字号:
<th>Description</th> <th>Example</th></tr> <tr><td>Common Name</td> <td>CN</td> <td>Name being certified</td> <td>CN=Joe Average</td></tr> <tr><td>Organization or Company</td> <td>O</td> <td>Name is associated with this<br />organization</td> <td>O=Snake Oil, Ltd.</td></tr> <tr><td>Organizational Unit</td> <td>OU</td> <td>Name is associated with this <br />organization unit, such as a department</td> <td>OU=Research Institute</td></tr> <tr><td>City/Locality</td> <td>L</td> <td>Name is located in this City</td> <td>L=Snake City</td></tr> <tr><td>State/Province</td> <td>ST</td> <td>Name is located in this State/Province</td> <td>ST=Desert</td></tr> <tr><td>Country</td> <td>C</td> <td>Name is located in this Country (ISO code)</td> <td>C=XZ</td></tr> </table> <p>A Certificate Authority may define a policy specifying which distinguished field names are optional and which are required. It may also place requirements upon the field contents, as may users of certificates. For example, a Netscape browser requires that the Common Name for a certificate representing a server matches a wildcard pattern for the domain name of that server, such as <code>*.snakeoil.com</code>.</p> <p>The binary format of a certificate is defined using the ASN.1 notation [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. This notation defines how to specify the contents and encoding rules define how this information is translated into binary form. The binary encoding of the certificate is defined using Distinguished Encoding Rules (DER), which are based on the more general Basic Encoding Rules (BER). For those transmissions which cannot handle binary, the binary form may be translated into an ASCII form by using Base64 encoding [<a href="#MIME">MIME</a>]. When placed between begin and end delimiter lines (as below), this encoded version is called a PEM ("Privacy Enhanced Mail") encoded certificate.</p> <div class="example"><h3>Example of a PEM-encoded certificate (snakeoil.crt)</h3><pre>-----BEGIN CERTIFICATE-----MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBzbmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzELMAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcNAQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8bvKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaalWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNVHRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOBgQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==-----END CERTIFICATE-----</pre></div><h3><a name="certificateauthorities" id="certificateauthorities">Certificate Authorities</a></h3> <p>By verifying the information in a certificate request before granting the certificate, the Certificate Authority assures itself of the identity of the private key owner of a key-pair. For instance, if Alice requests a personal certificate, the Certificate Authority must first make sure that Alice really is the person the certificate request claims she is.</p> <h4><a name="certificatechains" id="certificatechains">Certificate Chains</a></h4> <p>A Certificate Authority may also issue a certificate for another Certificate Authority. When examining a certificate, Alice may need to examine the certificate of the issuer, for each parent Certificate Authority, until reaching one which she has confidence in. She may decide to trust only certificates with a limited chain of issuers, to reduce her risk of a "bad" certificate in the chain.</p> <h4><a name="rootlevelca" id="rootlevelca">Creating a Root-Level CA</a></h4> <p>As noted earlier, each certificate requires an issuer to assert the validity of the identity of the certificate subject, up to the top-level Certificate Authority (CA). This presents a problem: who can vouch for the certificate of the top-level authority, which has no issuer? In this unique case, the certificate is "self-signed", so the issuer of the certificate is the same as the subject. Browsers are preconfigured to trust well-known certificate authorities, but it is important to exercise extra care in trusting a self-signed certificate. The wide publication of a public key by the root authority reduces the risk in trusting this key -- it would be obvious if someone else publicized a key claiming to be the authority.</p> <p>A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and <a href="http://www.verisign.com/">VeriSign</a> have established themselves as Certificate Authorities. These companies provide the following services:</p> <ul> <li>Verifying certificate requests</li> <li>Processing certificate requests</li> <li>Issuing and managing certificates</li> </ul> <p>It is also possible to create your own Certificate Authority. Although risky in the Internet environment, it may be useful within an Intranet where the organization can easily verify the identities of individuals and servers.</p> <h4><a name="certificatemanagement" id="certificatemanagement">Certificate Management</a></h4> <p>Establishing a Certificate Authority is a responsibility which requires a solid administrative, technical and management framework. Certificate Authorities not only issue certificates, they also manage them -- that is, they determine for how long certificates remain valid, they renew them and keep lists of certificates that were issued in the past but are no longer valid (Certificate Revocation Lists, or CRLs).</p> <p>For example, if Alice is entitled to a certificate as an employee of a company but has now left that company, her certificate may need to be revoked. Because certificates are only issued after the subject's identity has been verified and can then be passed around to all those with whom the subject may communicate, it is impossible to tell from the certificate alone that it has been revoked. Therefore when examining certificates for validity it is necessary to contact the issuing Certificate Authority to check CRLs -- this is usually not an automated part of the process.</p> <div class="note"><h3>Note</h3> <p>If you use a Certificate Authority that browsers are not configured to trust by default, it is necessary to load the Certificate Authority certificate into the browser, enabling the browser to validate server certificates signed by that Certificate Authority. Doing so may be dangerous, since once loaded, the browser will accept all certificates signed by that Certificate Authority.</p> </div> </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="ssl" id="ssl">Secure Sockets Layer (SSL)</a></h2><p>The Secure Sockets Layer protocol is a protocol layer which may beplaced between a reliable connection-oriented network layer protocol(e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL providesfor secure communication between client and server by allowing mutualauthentication, the use of digital signatures for integrity and encryptionfor privacy.</p><p>The protocol is designed to support a range of choices for specificalgorithms used for cryptography, digests and signatures. This allowsalgorithm selection for specific servers to be made based on legal, exportor other concerns and also enables the protocol to take advantage of newalgorithms. Choices are negotiated between client and server whenestablishing a protocol session.</p><h3><a name="table4" id="table4">Table 4: Versions of the SSL protocol</a></h3> <table class="bordered"> <tr><th>Version</th> <th>Source</th> <th>Description</th> <th>Browser Support</th></tr> <tr><td>SSL v2.0</td> <td>Vendor Standard (from Netscape Corp.) [<a href="#SSL2">SSL2</a>]</td> <td>First SSL protocol for which implementations exist</td> <td>- NS Navigator 1.x/2.x<br /> - MS IE 3.x<br /> - Lynx/2.8+OpenSSL</td></tr> <tr><td>SSL v3.0</td> <td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3">SSL3</a>]</td> <td>Revisions to prevent specific security attacks, add non-RSA ciphers and support for certificate chains</td> <td>- NS Navigator 2.x/3.x/4.x<br /> - MS IE 3.x/4.x<br /> - Lynx/2.8+OpenSSL</td></tr> <tr><td>TLS v1.0</td> <td>Proposed Internet Standard (from IETF) [<a href="#TLS1">TLS1</a>]</td> <td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for block ciphers, message order standardization and more alert messages.</td> <td>- Lynx/2.8+OpenSSL</td></tr> </table><p>There are a number of versions of the SSL protocol, as shown in <a href="#table4">Table 4</a>. As noted there, one of the benefits inSSL 3.0 is that it adds support of certificate chain loading. This featureallows a server to pass a server certificate along with issuer certificatesto the browser. Chain loading also permits the browser to validate theserver certificate, even if Certificate Authority certificates are notinstalled for the intermediate issuers, since they are included in thecertificate chain. SSL 3.0 is the basis for the Transport Layer Security [<a href="#TLS1">TLS</a>] protocol standard, currently in development bythe Internet Engineering Task Force (IETF).</p><h3><a name="session" id="session">Establishing a Session</a></h3> <p>The SSL session is established by following a handshake sequence between client and server, as shown in <a href="#figure1">Figure 1</a>. This sequence may vary, depending on whether the server is configured to provide a server certificate or request a client
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -