ssl_faq.html.en
来自「Apache HTTP Server 是一个功能强大的灵活的与HTTP/1.1相」· EN 代码 · 共 1,017 行 · 第 1/4 页
EN
1,017 行
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!-- XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX This file is generated from xml source: DO NOT EDIT XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --><title>SSL/TLS Strong Encryption: FAQ - Apache HTTP Server</title><link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /><link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /><link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link href="../images/favicon.ico" rel="shortcut icon" /></head><body id="manual-page"><div id="page-header"><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p><p class="apache">Apache HTTP Server Version 2.0</p><img alt="" src="../images/feather.gif" /></div><div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div><div id="path"><a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.0</a> > <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS Strong Encryption: FAQ</h1><div class="toplang"><p><span>Available Languages: </span><a href="../en/ssl/ssl_faq.html" title="English"> en </a></p></div><blockquote><p>The wise man doesn't give the right answers,he poses the right questions.</p><p class="cite">-- <cite>Claude Levi-Strauss</cite></p></blockquote><p>This chapter is a collection of frequently asked questions (FAQ) andcorresponding answers following the popular USENET tradition. Most of thesequestions occurred on the Newsgroup <code><a href="news:comp.infosystems.www.servers.unix">comp.infosystems.www.servers.unix</a></code> or the mod_ssl SupportMailing List <code><a href="mailto:modssl-users@modssl.org">modssl-users@modssl.org</a></code>. They are collected at this placeto avoid answering the same questions over and over.</p><p>Please read this chapter at least once when installing mod_ssl or at leastsearch for your problem here before submitting a problem report to theauthor.</p></div><div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#about">About The Module</a></li><li><img alt="" src="../images/down.gif" /> <a href="#installation">About Installation</a></li><li><img alt="" src="../images/down.gif" /> <a href="#aboutconfig">About Configuration</a></li><li><img alt="" src="../images/down.gif" /> <a href="#aboutcerts">About Certificates</a></li><li><img alt="" src="../images/down.gif" /> <a href="#aboutssl">About SSL Protocol</a></li><li><img alt="" src="../images/down.gif" /> <a href="#support">About Support</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="about" id="about">About The Module</a></h2><ul><li><a href="#history">What is the history of mod_ssl?</a></li><li><a href="#y2k">mod_ssl and Year 2000?</a></li><li><a href="#wassenaar">mod_ssl and Wassenaar Arrangement?</a></li></ul><h3><a name="history" id="history">What is the history of mod_ssl?</a></h3><p>The mod_ssl v1 package was initially created in April 1998 by <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> via porting <a href="mailto:ben@algroup.co.uk">Ben Laurie</a>'s <a href="http://www.apache-ssl.org/">Apache-SSL</a> 1.17 source patches for Apache 1.2.6 to Apache 1.3b6. Because of conflicts with Ben Laurie's development cycle it then was re-assembled from scratch for Apache 1.3.0 by merging the old mod_ssl 1.x with the newer Apache-SSL 1.18. From this point on mod_ssl lived its own life as mod_ssl v2. The first publicly released version was mod_ssl 2.0.0 from August 10th, 1998. As of this writing (August 1999) the current mod_ssl version is 2.4.0.</p> <p>After one year of very active development with over 1000 working hours and over 40 releases mod_ssl reached its current state. The result is an already very clean source base implementing a very rich functionality. The code size increased by a factor of 4 to currently a total of over 10.000 lines of ANSI C consisting of approx. 70% code and 30% code documentation. From the original Apache-SSL code currently approx. 5% is remaining only.</p> <p>After the US export restrictions for cryptographic software were opened, mod_ssl was integrated into the code base of Apache V2 in 2001.</p><h3><a name="y2k" id="y2k">Is mod_ssl Year 2000 compliant?</a></h3><p>Yes, mod_ssl is Year 2000 compliant.</p> <p>Because first mod_ssl internally never stores years as two digits. Instead it always uses the ANSI C & POSIX numerical data type <code>time_t</code> type, which on almost all Unix platforms at the moment is a <code>signed long</code> (usually 32-bits) representing seconds since epoch of January 1st, 1970, 00:00 UTC. This signed value overflows in early January 2038 and not in the year 2000. Second, date and time presentations (for instance the variable ``<code>%{TIME_YEAR}</code>'') are done with full year value instead of abbreviating to two digits.</p> <p>Additionally according to a <a href="http://www.apache.org/docs/misc/FAQ.html#year2000">Year 2000 statement</a> from the Apache Group, the Apache webserver is Year 2000 compliant, too. But whether OpenSSL or the underlying Operating System (either a Unix or Win32 platform) is Year 2000 compliant is a different question which cannot be answered here.</p><h3><a name="wassenaar" id="wassenaar">What about mod_ssl and the Wassenaar Arrangement?</a></h3><p>First, let us explain what <dfn>Wassenaar</dfn> and its <dfn>Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies</dfn> is: This is a international regime, established 1995, to control trade in conventional arms and dual-use goods and technology. It replaced the previous <dfn>CoCom</dfn> regime. 33 countries are signatories: Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, the Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, Ukraine, the United Kingdom and the United States. For more details look at <a href="http://www.wassenaar.org/">http://www.wassenaar.org/</a>.</p> <p>In short: The aim of the Wassenaar Arrangement is to prevent the build up of military capabilities that threaten regional and international security and stability. The Wassenaar Arrangement controls the export of cryptography as a dual-use good, i.e., one that has both military and civilian applications. However, the Wassenaar Arrangement also provides an exemption from export controls for mass-market software and free software.</p> <p>In the current Wassenaar <cite>List of Dual Use Goods and Technologies And Munitions</cite>, under <q>GENERAL SOFTWARE NOTE (GSN)</q> it says <q>The Lists do not control "software" which is either: 1. [...] 2. "in the public domain".</q> And under <q>DEFINITIONS OF TERMS USED IN THESE LISTS</q> one can find the definition: <q>In the public domain": This means "technology" or "software" which has been made available without restrictions upon its further dissemination. N.B. Copyright restrictions do not remove "technology" or "software" from being "in the public domain".</q></p> <p>So, both mod_ssl and OpenSSL are <q>in the public domain</q> for the purposes of the Wassenaar Agreement and its <q>List of Dual Use Goods and Technologies And Munitions List</q>.</p> <p>So, mod_ssl and OpenSSL are not affected by the Wassenaar Agreement.</p></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="installation" id="installation">About Installation</a></h2><ul><li><a href="#coredump">Core dumps for HTTPS requests?</a></li><li><a href="#mutex">Permission problem on SSLMutex</a></li><li><a href="#mm">Shared memory and process size?</a></li><li><a href="#entropy">PRNG and not enough entropy?</a></li></ul><h3><a name="coredump" id="coredump">When I access my website the first time via HTTPS I get a core dump?</a></h3><p>There can be a lot of reasons why a core dump can occur, of course. Ranging from buggy third-party modules, over buggy vendor libraries up to a buggy mod_ssl version. But the above situation is often caused by old or broken vendor DBM libraries. To solve it either build mod_ssl with the built-in SDBM library (specify <code>--enable-rule=SSL_SDBM</code> at the APACI command line) or switch from <code>SSLSessionCache dbm:</code> to the newer <code>SSLSessionCache shm:</code>'' variant (after you have rebuilt Apache with MM, of course).</p><h3><a name="mutex" id="mutex">When I startup Apache I get permission errors related to SSLMutex?</a></h3><p>When you receive entries like ``<code>mod_ssl: Child could not open SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) [...] System: Permission denied (errno: 13)</code>'' this is usually caused by to restrictive permissions on the <em>parent</em> directories. Make sure that all parent directories (here <code>/opt</code>, <code>/opt/apache</code> and <code>/opt/apache/logs</code>) have the x-bit set at least for the UID under which Apache's children are running (see the <code class="directive"><a href="../mod/mpm_common.html#user">User</a></code> directive of Apache).</p><h3><a name="mm" id="mm">When I use the MM library and the shared memory cache each process grows1.5MB according to `top' although I specified 512000 as the cache size?</a></h3><p>The additional 1MB are caused by the global shared memory pool Apache allocates for all modules and which is not used by mod_ssl for various reasons. So the actually allocated shared memory is always 1MB more than what you specify on <code class="directive"><a href="../mod/mod_ssl.html#sslsessioncache">SSLSessionCache</a></code>. But don't be confused by the display of `top': although is indicates that <em>each</em> process grow, this is not reality, of course. Instead the additional memory consumption is shared by all processes, i.e. the 1.5MB are allocated only once per Apache instance and not once per Apache server process.</p><h3><a name="entropy" id="entropy">When I fire up the server, mod_ssl stops with the error"Failed to generate temporary 512 bit RSA private key", why?</a></h3><p>Cryptographic software needs a source of unpredictable data to work correctly. Many open source operating systems provide a "randomness device" that serves this purpose (usually named <code>/dev/random</code>). On other systems, applications have to seed the OpenSSL Pseudo Random Number Generator (PRNG) manually with appropriate data before generating keys or performing public key encryption. As of version 0.9.5, the OpenSSL functions that need randomness report an error if the PRNG has not been seeded with at least 128 bits of randomness. So mod_ssl has to provide enough entropy to the PRNG to work correctly. For this one has to use the <code>SSLRandomSeed</code> directives.</p></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="aboutconfig" id="aboutconfig">About Configuration</a></h2><ul><li><a href="#parallel">HTTP and HTTPS with a single server?</a></li><li><a href="#ports">Where is the HTTPS port?</a></li><li><a href="#httpstest">How to test HTTPS manually?</a></li><li><a href="#hang">Why does my connection hang?</a></li><li><a href="#refused">Why do I get connection refused?</a></li><li><a href="#envvars">Why are the <code>SSL_XXX</code> variables missing?</a></li><li><a href="#relative">How to switch with relative hyperlinks?</a></li></ul><h3><a name="parallel" id="parallel">Is it possible to provide HTTP and HTTPS with a single server?</a></h3><p>Yes, HTTP and HTTPS use different server ports, so there is no direct conflict between them. Either run two separate server instances (one binds to port 80, the other to port 443) or even use Apache's elegant virtual hosting facility where you can easily create two virtual servers which Apache dispatches: one responding to port 80 and speaking HTTP and one responding to port 443 speaking HTTPS.</p><h3><a name="ports" id="ports">I know that HTTP is on port 80, but where is HTTPS?</a></h3><p>You can run HTTPS on any port, but the standards specify port 443, which is where any HTTPS compliant browser will look by default. You can force your browser to look on a different port by specifying it in the URL like this (for port 666): <code>https://secure.server.dom:666/</code></p><h3><a name="httpstest" id="httpstest">How can I speak HTTPS manually for testing purposes?</a></h3> <p>While you usually just use</p> <div class="example"><p><code>$ telnet localhost 80<br /> GET / HTTP/1.0</code></p></div> <p>for simple testing the HTTP protocol of Apache, it's not so easy for HTTPS because of the SSL protocol between TCP and HTTP. But with the help of OpenSSL's <code>s_client</code> command you can do a similar check even for HTTPS:</p> <div class="example"><p><code>$ openssl s_client -connect localhost:443 -state -debug<br /> GET / HTTP/1.0</code></p></div> <p>Before the actual HTTP response you receive detailed information about the SSL handshake. For a more general command line client which directly understands both the HTTP and HTTPS scheme, can perform GET and POST methods, can use a proxy, supports byte ranges, etc. you should have a look at nifty <a href="http://curl.haxx.se/">cURL</a> tool. With it you can directly check if your Apache is running fine on Port 80 and 443 as following:</p> <div class="example"><p><code>$ curl http://localhost/<br /> $ curl https://localhost/</code></p></div><h3><a name="hang" id="hang">Why does the connection hang when I connect to my SSL-aware Apache server?</a></h3><p>Because you connected with HTTP to the HTTPS port, i.e. you used an URL of the form ``<code>http://</code>'' instead of ``<code>https://</code>''. This also happens the other way round when you connect via HTTPS to a HTTP port, i.e. when you try to use ``<code>https://</code>'' on a server that⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?