ssl_intro.html.en

apache的软件linux版本

        <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. As an example, a Netscape browser requires that the
    Common Name for a certificate representing a server has a name which
    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>]. This encoded version is called PEM encoded
    (the name comes from "Privacy Enhanced Mail"), when placed between
    begin and end delimiter lines as illustrated in the following
    example.</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 first verifying the information in a certificate request
    before granting the certificate, the Certificate Authority assures
    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.</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:
        Since this is who vouches 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. As a result, one must 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. Browsers are preconfigured to trust
        well-known certificate authorities.</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 how long
        certificates are valid, they renew them, and they keep lists of
        certificates that have already been issued but are no longer valid
        (Certificate Revocation Lists, or CRLs). Say Alice is entitled to
        a certificate as an employee of a company. Say too, that the
        certificate needs to be revoked when Alice leaves the company. Since
        certificates are objects that get passed around, 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 not usually an automated part of the process.</p>

        <div class="note"><h3>Note</h3>
        <p>If you use a Certificate Authority that is not configured into
        browsers 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">Session Establishment</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
    certificate. Though cases exist where additional handshake steps
    are required for management of cipher information, this article
    summarizes one common scenario: see the SSL specification for the full
    range of possibilities.</p>