ssl_intro.html.en

Apache2.2.4 with OpenSSL 0.9.8e 提供HTTP及HTTPS服务。 带QuickUsage

        <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-----
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/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 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 they 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. 
        When examining certificates for validity, therefore, 
        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 be
placed between a reliable connection-oriented network layer protocol
(e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides
for secure communication between client and server by allowing mutual
authentication, the use of digital signatures for integrity, and encryption
for privacy.</p>

<p>The protocol is designed to support a range of choices for specific
algorithms used for cryptography, digests, and signatures. This allows
algorithm selection for specific servers to be made based on legal, export
or other concerns, and also enables the protocol to take advantage of new
algorithms. Choices are negotiated between client and server at the start
of establishing 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 exists</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 in
SSL 3.0 is that it adds support of certificate chain loading. This feature
allows a server to pass a server certificate along with issuer certificates
to the browser. Chain loading also permits the browser to validate the
server certificate, even if Certificate Authority certificates are not
installed for the intermediate issuers, since they are included in the
certificate chain. SSL 3.0 is the basis for the Transport Layer Security 
[<a href="#TLS1">TLS</a>] protocol standard, currently in development by
the 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