ssl_faq.html

apach加密模块

    <code><strong>$ openssl x509 -noout -text -in server.crt</strong></code><br>
    <code><strong>$ openssl rsa -noout -text -in server.key</strong></code>
    <p>
    The `modulus' and the `public exponent' portions in the key and the
    Certificate must match. But since the public exponent is usually 65537
    and it's bothering comparing long modulus you can use the following
    approach:
    <p>
    <code><strong>$ openssl x509 -noout -modulus -in server.crt | openssl md5</strong></code><br>
    <code><strong>$ openssl rsa -noout -modulus -in server.key | openssl md5</strong></code>
    <p>
    And then compare these really shorter numbers. With overwhelming
    probability they will differ if the keys are different. BTW, if I want to
    check to which key or certificate a particular CSR belongs you can compute
    <p>
    <code><strong>$ openssl req -noout -modulus -in server.csr | openssl md5</strong></code>
<p>
<li><a name="ToC32"></a>
    <a name="keysize1"></a>
    <strong id="faq">What does it mean when my connections fail with an "alert bad certificate"
error?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#keysize1"><b>L</b></a>]
    <p>
    Usually when you see errors like ``<tt>OpenSSL: error:14094412: SSL
    routines:SSL3_READ_BYTES:sslv3 alert bad certificate</tt>'' in the SSL
    logfile, this means that the browser was unable to handle the server
    certificate/private-key which perhaps contain a RSA-key not equal to 1024
    bits. For instance Netscape Navigator 3.x is one of those browsers.
<p>
<li><a name="ToC33"></a>
    <a name="keysize2"></a>
    <strong id="faq">Why does my 2048-bit private key not work?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#keysize2"><b>L</b></a>]
    <p>
    The private key sizes for SSL must be either 512 or 1024 for compatibility
    with certain web browsers. A keysize of 1024 bits is recommended because
    keys larger than 1024 bits are incompatible with some versions of Netscape
    Navigator and Microsoft Internet Explorer, and with other browsers that
    use RSA's BSAFE cryptography toolkit.
<p>
<li><a name="ToC34"></a>
    <a name="hash-symlinks"></a>
    <strong id="faq">Why is client authentication broken after upgrading from
SSLeay version 0.8 to 0.9?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#hash-symlinks"><b>L</b></a>]
    <p>
    The CA certificates under the path you configured with
    <code>SSLCACertificatePath</code> are found by SSLeay through hash
    symlinks. These hash values are generated by the `<code>openssl x509 -noout
    -hash</code>' command. But the algorithm used to calculate the hash for a
    certificate has changed between SSLeay 0.8 and 0.9. So you have to remove
    all old hash symlinks and re-create new ones after upgrading. Use the
    <code>Makefile</code> mod_ssl placed into this directory.
<p>
<li><a name="ToC35"></a>
    <a name="pem-to-der"></a>
    <strong id="faq">How can I convert a certificate from PEM to DER format?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#pem-to-der"><b>L</b></a>]
    <p>
    The default certificate format for SSLeay/OpenSSL is PEM, which actually
    is Base64 encoded DER with header and footer lines. For some applications
    (e.g. Microsoft Internet Explorer) you need the certificate in plain DER
    format. You can convert a PEM file <code>cert.pem</code> into the
    corresponding DER file <code>cert.der</code> with the following command:
    <code><strong>$ openssl x509 -in cert.pem -out cert.der -outform DER</strong></code>
<p>
<li><a name="ToC36"></a>
    <a name="verisign-getca"></a>
    <strong id="faq">I try to install a Verisign certificate. Why can't I find neither the
<code>getca</code> nor <code>getverisign</code> programs Verisign mentions?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#verisign-getca"><b>L</b></a>]
    <p>
    This is because Verisign has never provided specific instructions
    for Apache+mod_ssl. Rather they tell you what you should do
    if you were using C2Net's Stronghold (a commercial Apache
    based server with SSL support). The only thing you have to do
    is to save the certificate into a file and give the name of
    that file to the <code>SSLCertificateFile</code> directive.
    Remember that you need to give the key file in as well (see
    <code>SSLCertificateKeyFile</code> directive). For a better
    CA-related overview on SSL certifiate fiddling you can look at <a
    href="http://www.thawte.com/certs/server/keygen/mod_ssl.html">
    Thawte's mod_ssl instructions</a>.
<p>
<li><a name="ToC37"></a>
    <a name="gid"></a>
    <strong id="faq">Can I use the Server Gated Cryptography (SGC) facility (aka Verisign Global
ID) also with mod_ssl?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#gid"><b>L</b></a>]
    <p>
    Yes, mod_ssl since version 2.1 supports the SGC facility. You don't have
    to configure anything special for this, just use a Global ID as your
    server certificate. The <i>step up</i> of the clients are then
    automatically handled by mod_ssl under run-time. For details please read
    the <tt>README.GlobalID</tt> document in the mod_ssl distribution.
<p>
<li><a name="ToC38"></a>
    <a name="gid"></a>
    <strong id="faq">After I have installed my new Verisign Global ID server certificate, the
browsers complain that they cannot verify the server certificate?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#gid"><b>L</b></a>]
    <p>
    That is because Verisign uses an intermediate CA certificate between
    the root CA certificate (which is installed in the browsers) and
    the server certificate (which you installed in the server). You
    should have received this additional CA certificate from Verisign.
    If not, complain to them. Then configure this certificate with the
    <code>SSLCertificateChainFile</code> directive in the server. This
    makes sure the intermediate CA certificate is send to the browser
    and this way fills the gap in the certificate chain.
</ul>
<p>
<br>
<H2><a name="ToC39">About SSL Protocol</a></H2>
<ul>
<p>
<li><a name="ToC40"></a>
    <a name="load"></a>
    <strong id="faq">Why has my webserver a higher load now that I run SSL there?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#load"><b>L</b></a>]
    <p>
    Because SSL uses strong cryptographic encryption and this needs a lot of
    number crunching. And because when you request a webpage via HTTPS even
    the images are transfered encrypted. So, when you have a lot of HTTPS
    traffic the load increases.
<p>
<li><a name="ToC41"></a>
    <a name="random"></a>
    <strong id="faq">Often HTTPS connections to my server require up to 30 seconds for establishing
the connection, although sometimes it works faster?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#random"><b>L</b></a>]
    <p>
    Usually this is caused by using a <code>/dev/random</code> device for
    <code>SSLRandomSeed</code> which is blocking in read(2) calls if not
    enough entropy is available. Read more about this problem in the refernce
    chapter under <code>SSLRandomSeed</code>.
<p>
<li><a name="ToC42"></a>
    <a name="ciphers"></a>
    <strong id="faq">What SSL Ciphers are supported by mod_ssl?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#ciphers"><b>L</b></a>]
    <p>
    Usually just all SSL ciphers which are supported by the
    version of OpenSSL in use (can depend on the way you built
    OpenSSL). Typically this at least includes the following:
    <p>
    <ul>
    <li>RC4 with MD5
    <li>RC4 with MD5 (export version restricted to 40-bit key)
    <li>RC2 with MD5
    <li>RC2 with MD5 (export version restricted to 40-bit key)
    <li>IDEA with MD5
    <li>DES with MD5
    <li>Triple-DES with MD5
    </ul>
    <p>
    To determine the actual list of supported ciphers you can
    run the following command:
    <p>
    <code><strong>$ openssl ciphers -v</strong></code><br>
<p>
<li><a name="ToC43"></a>
    <a name="cipher-adh"></a>
    <strong id="faq">I want to use Anonymous Diffie-Hellman (ADH) ciphers, but I always get ``no
shared cipher'' errors?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#cipher-adh"><b>L</b></a>]
    <p>
    In order to use Anonymous Diffie-Hellman (ADH) ciphers, it is not enough
    to just put ``<code>ADH</code>'' into your <code>SSLCipherSuite</code>.
    Additionally you have to build OpenSSL with
    ``<code>-DSSL_ALLOW_ADH</code>''. Because per default OpenSSL does not
    allow ADH ciphers for security reasons. So if you are actually enabling
    these ciphers make sure you are informed about the side-effects.
<p>
<li><a name="ToC44"></a>
    <a name="cipher-shared"></a>
    <strong id="faq">I always just get a 'no shared ciphers' error if
I try to connect to my freshly installed server?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#cipher-shared"><b>L</b></a>]
    <p>
    Either you have messed up your <code>SSLCipherSuite</code>
    directive (compare it with the pre-configured example in
    <code>httpd.conf-dist</code>) or you have choosen the DSA/DH
    algorithms instead of RSA under "<code>make certificate</code>"
    and ignored or overseen the warnings. Because if you have choosen
    DSA/DH, then your server no longer speaks RSA-based SSL ciphers
    (at least not until you also configure an additional RSA-based
    certificate/key pair). But current browsers like NS or IE only speak
    RSA ciphers. The result is the "no shared ciphers" error. To fix
    this, regenerate your server certificate/key pair and this time
    choose the RSA algorithm.
<p>
<li><a name="ToC45"></a>
    <a name="vhosts"></a>
    <strong id="faq">Why can't I use SSL with name-based/non-IP-based virtual hosts?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#vhosts"><b>L</b></a>]
    <p>
    The reason is very technical. Actually it's some sort of a chicken and
    egg problem: The SSL protocol layer stays below the HTTP protocol layer
    and encapsulates HTTP. When an SSL connection (HTTPS) is established
    Apache/mod_ssl has to negotiate the SSL protocol parameters with the
    client. For this mod_ssl has to consult the configuration of the virtual
    server (for instance it has to look for the cipher suite, the server
    certificate, etc.). But in order to dispatch to the correct virtual server
    Apache has to know the <code>Host</code> HTTP header field. For this the
    HTTP request header has to be read. This cannot be done before the SSL
    handshake is finished. But the information is already needed at the SSL
    handshake phase. Bingo!
<p>
<li><a name="ToC46"></a>
    <a name="lock-icon"></a>
    <strong id="faq">When I use Basic Authentication over HTTPS the lock icon in Netscape browsers
still show the unlocked state when the dialog pops up. Does this mean the
username/password is still transmitted unencrypted?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#lock-icon"><b>L</b></a>]
    <p>
    No, the username/password is already transmitted encrypted. The icon in
    Netscape browsers is just not really synchronized with the SSL/TLS layer
    (it toggles to the locked state when the first part of the actual webpage
    data is transferred which is not quite correct) and this way confuses
    people. The Basic Authentication facility is part of the HTTP layer and
    this layer is above the SSL/TLS layer in HTTPS. And before any HTTP data
    communication takes place in HTTPS the SSL/TLS layer has already done the
    handshake phase and switched to encrypted communication. So, don't get
    confused by this icon.
<p>
<li><a name="ToC47"></a>
    <a name="io-ie"></a>
    <strong id="faq">When I connect via HTTPS to an Apache+mod_ssl server with Microsoft Internet
Explorer (MSIE) I sometimes get I/O errors and the message "bad data from the
server". What's the reason?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#io-ie"><b>L</b></a>]
    <p>
    The reason is that MSIE's SSL implementation has some subtle bugs related
    to the HTTP keep-alive facility and the SSL close notify alerts on socket
    connection close. You've to work-around this by forcing Apache+mod_ssl to
    not use keep-alive connections and not sending the SSL close notify
    messages to MSIE clients. This can be done by using the following
    directive in your SSL-aware virtual host section:
    <pre>
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
    </pre>
<p>
<li><a name="ToC48"></a>
    <a name="io-ns"></a>
    <strong id="faq">When I connect via HTTPS to an Apache+mod_ssl server with Netscape Navigator I
get I/O errors and the message "Netscape has encountered bad data from the
server" What's the reason?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/ssl_faq.html#io-ns"><b>L</b></a>]
    <p>
    The problem usually is tha