From: André Malo Date: Tue, 18 Oct 2005 15:20:25 +0000 (+0000) Subject: mod_version_for_2.0.x branch: X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=refs%2Fremotes%2Fmod_version_for_2.0.x;p=thirdparty%2Fapache%2Fhttpd.git mod_version_for_2.0.x branch: * Merge 291277 to 326117 from branches/2.0.x git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/mod_version_for_2.0.x@326121 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/CHANGES b/CHANGES index fd1c6c854c6..4d17685c155 100644 --- a/CHANGES +++ b/CHANGES @@ -1,5 +1,5 @@ -*- coding: utf-8 -*- -Changes with Apache 2.0.55 +Changes with Apache 2.0.56 *) Added new module mod_version, which provides version dependent configuration containers. [André Malo] @@ -8,6 +8,16 @@ Changes with Apache 2.0.55 accompanying ap_version_t structure (minor MMN bump). [André Malo] +Changes with Apache 2.0.55 + + *) SECURITY: CAN-2005-2700 (cve.mitre.org) + mod_ssl: Fix a security issue where "SSLVerifyClient" was not + enforced in per-location context if "SSLVerifyClient optional" + was configured in the vhost configuration. [Joe Orton] + + *) worker MPM: Fix a memory leak which can occur after an aborted + connection in some limited circumstances. [Greg Ames] + *) mod_ldap: Fix PR 36563. Keep track of the number of attributes retrieved from LDAP so that all of the values can be properly cached even if the value is NULL. diff --git a/STATUS b/STATUS index 2d93e2681b0..27a547cf2a4 100644 --- a/STATUS +++ b/STATUS @@ -23,7 +23,8 @@ Consult the trunk/ for all new development and documentation efforts: Release history: - 2.0.55 : in development + 2.0.56 : in development + 2.0.55 : tagged October 9, 2005 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. @@ -99,7 +100,8 @@ CURRENT RELEASE NOTES: * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, - get feedback and votes in STATUS, and then merge into branches/2.0.x. + get feedback and votes on list or in STATUS, then merge into + branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: @@ -150,17 +152,12 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK: +1: pquerna, nd, wrowe Votes from before the integration branch: +1: jerenkrantz + PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! Add all new proposals to the end of this list. ] - *) Fix CAN-2005-2700, mod_ssl SSLVerifyClient bug - http://svn.apache.org/viewcvs?rev=264800&view=rev - test case: perl-framework/t/security/CAN-2005-2700.t - +1: jorton, wrowe - wrowe cautions to backport to 2.2.x branch as well. - *) mod_headers: Support {...}s tag for SSL variable lookup. http://www.apache.org/~jorton/mod_headers-2.0-ssl.diff +1: jorton, trawick @@ -229,11 +226,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: +1: pquerna, jerenkrantz, colm jerenkrantz notes: I do prefer the version from r190033 (own if check). - *) mod_ssl: Fix buffering in SSL output filter. - http://svn.apache.org/viewcvs?rev=189971&view=rev - PR: 35279 - +1: jorton, jerenkrantz - *) Reverse Proxy fixes: bug and Cookie support Patch is at http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=112365629308138&q=p4 @@ -260,11 +252,31 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: code: http://svn.apache.org/viewcvs?view=rev&rev=157583 http://svn.apache.org/viewcvs?rev=280401&view=rev docs: http://svn.apache.org/viewcvs?rev=280384&view=rev - +1: stas + +1: stas, trawick -0: colm colm: It's a useful feature, but TCP window size selection algorithims can be pretty "interesting", probably more 2.2. + trawick: It is nevertheless true that POST performance can + sometimes improve dramatically by tweaking the receive + buffer size, and this relatively simple patch lets that + be controlled in a portable manner just for the web + server. (old way: use system-specific configuration + knobs that affect all applications.) + + *) Fix all non-http protocol modules that were modeled after the + broken mod_echo.c example; remove the -initial- timeout setting + from NET_TIME (never inserted by non-request based protocols) + and move it to the core pre_connection logic, so every core + connection can read with timeout on Linux, Solaris, instead of + read (untimed) blocking on Linux, and failing read non-block on + Solaris. Leaves NET_TIME intact until after the 2.0.x branch. + http://people.apache.org/~wrowe/httpd-2.0-proto-timeout.patch + +1: wrowe + + *) Add missing va_end call + http://svn.apache.org/viewcvs?rev=321500&view=rev + +1: nd, trawick PATCHES TO BACKPORT THAT ARE ON HOLD OR NOT GOING ANYWHERE SOON: diff --git a/build/rpm/httpd.spec.in b/build/rpm/httpd.spec.in index edba3d41b9a..26b32fea983 100644 --- a/build/rpm/httpd.spec.in +++ b/build/rpm/httpd.spec.in @@ -19,7 +19,7 @@ Group: System Environment/Daemons BuildRoot: %{_tmppath}/%{name}-root BuildPrereq: apr-devel, apr-util-devel, openldap-devel, db4-devel, expat-devel, findutils, perl, pkgconfig BuildPrereq: /usr/bin/apr-config, /usr/bin/apu-config -Requires: apr >= 0.9.5, apr-util >= 0.9.5, gawk, /usr/share/magic.mime, /usr/bin/find, openldap +Requires: apr >= 0.9.7, apr-util >= 0.9.7, gawk, /usr/share/magic.mime, /usr/bin/find, openldap Prereq: /sbin/chkconfig, /bin/mktemp, /bin/rm, /bin/mv Prereq: sh-utils, textutils, /usr/sbin/useradd Provides: webserver @@ -37,7 +37,7 @@ Group: Development/Libraries Summary: Development tools for the Apache HTTP server. Obsoletes: secureweb-devel, apache-devel Requires: libtool, httpd = %{version} -Requires: apr-devel >= 0.9.5, apr-util-devel >= 0.9.5 +Requires: apr-devel >= 0.9.7, apr-util-devel >= 0.9.7 %description devel The httpd-devel package contains the APXS binary and other files @@ -203,7 +203,6 @@ echo %{mmn} > $RPM_BUILD_ROOT%{_includedir}/httpd/.mmn # docroot mkdir $RPM_BUILD_ROOT%{contentdir}/html rm -r $RPM_BUILD_ROOT%{contentdir}/manual/style -rm $RPM_BUILD_ROOT%{contentdir}/manual/*/*.xml # logs rmdir $RPM_BUILD_ROOT%{_sysconfdir}/httpd/logs @@ -369,6 +368,10 @@ rm -rf $RPM_BUILD_ROOT %{_libdir}/httpd/build/instdso.sh %changelog +* Tue Oct 11 2005 Graham Leggett 2.0.56-dev +- Updated the apr and apr-util dependencies to require at least v0.9.7 +- Stop trying to remove *.xml doc files, the httpd build does that already. + * Thu Dec 16 2004 Graham Leggett 2.0.53-dev - Changed build to use external apr and apr-util diff --git a/docs/manual/ssl/ssl_faq.html.en b/docs/manual/ssl/ssl_faq.html.en index 417966c4320..da9e3676d5a 100644 --- a/docs/manual/ssl/ssl_faq.html.en +++ b/docs/manual/ssl/ssl_faq.html.en @@ -38,11 +38,11 @@ search for your problem here before submitting a problem report to the author.

top
@@ -60,60 +60,25 @@ author.

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.

- - -

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.

- -

After the US export restrictions for cryptographic software were - opened, mod_ssl was integrated into the code base of Apache V2 in 2001.

- - -

Is mod_ssl Year 2000 compliant?

-

Yes, mod_ssl is Year 2000 compliant.

- -

Because first mod_ssl internally never stores years as two digits. - Instead it always uses the ANSI C & POSIX numerical data type - time_t type, which on almost all Unix platforms at the moment - is a signed long (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 ``%{TIME_YEAR}'') - are done with full year value instead of abbreviating to two digits.

- + 1998.

-

Additionally according to a Year 2000 - statement 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.

+

After US export restrictions on cryptographic software were + loosened, mod_ssl became part of the Apache HTTP + Server with the release of Apache httpd 2.

-

What about mod_ssl and the Wassenaar Arrangement?

+

Is mod_ssl affected by the Wassenaar Arrangement?

First, let us explain what Wassenaar and its Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and - Technologies is: This is a international regime, established 1995, to + Technologies is: This is a international regime, established in 1995, to control trade in conventional arms and dual-use goods and technology. It - replaced the previous CoCom 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 http://www.wassenaar.org/.

+ replaced the previous CoCom regime. Further details on + both the Arrangement and its signatories are available at http://www.wassenaar.org/.

- -

In short: The aim of the Wassenaar Arrangement is to prevent the build up +

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 + cryptography as a dual-use good, that is, something 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.

@@ -121,66 +86,43 @@ author.

Munitions, under GENERAL SOFTWARE NOTE (GSN) it says The Lists do not control "software" which is either: 1. [...] 2. "in the public domain". And under DEFINITIONS OF TERMS USED IN - THESE LISTS one can find the definition: In the public - domain": This means "technology" or "software" which has been made - available without restrictions upon its further dissemination. N.B. + THESE LISTS we find In the public + domain defined as "technology" or "software" which has been made + available without restrictions upon its further dissemination. Note: Copyright restrictions do not remove "technology" or "software" from being "in the public domain".

So, both mod_ssl and OpenSSL are in the public domain for the purposes - of the Wassenaar Agreement and its List of Dual Use Goods and - Technologies And Munitions List.

+ of the Wassenaar Arrangement and its List of Dual Use Goods and + Technologies And Munitions List, and thus not affected by its provisions.

-

So, mod_ssl and OpenSSL are not affected by the Wassenaar Agreement.

top
-

About Installation

+

Installation

-

When I access my website the first time via HTTPS I get a core dump?

-

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 --enable-rule=SSL_SDBM at the - APACI command line) or switch from SSLSessionCache dbm: to the - newer SSLSessionCache shm:'' variant (after you have rebuilt - Apache with MM, of course).

- - -

When I startup Apache I get permission errors related to SSLMutex?

-

When you receive entries like ``mod_ssl: Child could not open +

Why do I get permission errors related to + SSLMutex when I start Apache?

+

Errors such as ``mod_ssl: Child could not open SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) - [...] System: Permission denied (errno: 13)'' this is usually - caused by to restrictive permissions on the parent directories. + [...] System: Permission denied (errno: 13)'' are usually + caused by overly restrictive permissions on the parent directories. Make sure that all parent directories (here /opt, /opt/apache and /opt/apache/logs) have the x-bit - set at least for the UID under which Apache's children are running (see - the User directive of Apache).

- - -

When I use the MM library and the shared memory cache each process grows -1.5MB according to `top' although I specified 512000 as the cache size?

-

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 SSLSessionCache. - But don't be confused by the display of `top': although is - indicates that each 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.

- - -

When I fire up the server, mod_ssl stops with the error -"Failed to generate temporary 512 bit RSA private key", why?

-

Cryptographic software needs a source of unpredictable data + set for, at minimum, the UID under which Apache's children are running (see + the User directive).

+ + +

Why does mod_ssl stop with the error + "Failed to generate temporary 512 bit RSA private key", when I start + Apache?

+

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 /dev/random). On other systems, applications have to @@ -188,67 +130,78 @@ author.

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 - SSLRandomSeed directives.

+ at least 128 bits of randomness.

+

To prevent this error, mod_ssl has to provide + enough entropy to the PRNG to allow it to work correctly. This can + be done via the SSLRandomSeed + directives.

top
-

About Configuration

+

Configuration

-

Is it possible to provide HTTP and HTTPS with a single server?

-

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.

+

Is it possible to provide HTTP and HTTPS + from the same server?

+

Yes. HTTP and HTTPS use different server ports (HTTP binds to + port 80, HTTPS to port 443), so there is no direct conflict between + them. You can either run two separate server instances bound to + these ports, or use Apache's elegant virtual hosting facility to + create two virtual servers over one instance of Apache - one + responding to requests on port 80 and speaking HTTP and the other + responding to requests on port 443 speaking HTTPS.

-

I know that HTTP is on port 80, but where is HTTPS?

+

Which port does HTTPS use?

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): https://secure.server.dom:666/

-

How can I speak HTTPS manually for testing purposes?

+

How do I speak HTTPS manually for testing purposes?

While you usually just use

$ telnet localhost 80
GET / HTTP/1.0

- -

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 s_client command you can do a similar - check even for HTTPS:

+

for simple testing of Apache via HTTP, it's not so easy for + HTTPS because of the SSL protocol between TCP and HTTP. With the + help of OpenSSL's s_client command, however, you can + do a similar check for HTTPS:

$ openssl s_client -connect localhost:443 -state -debug
GET / HTTP/1.0

-

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 cURL - tool. With it you can directly check if your Apache is running fine on - Port 80 and 443 as following:

+

Before the actual HTTP response you will receive detailed + information about the SSL handshake. For a more general command + line client which directly understands both HTTP and HTTPS, can + perform GET and POST operations, can use a proxy, supports byte + ranges, etc. you should have a look at the nifty + cURL tool. Using this, you can + check that Apache is responding correctly on ports 80 and 443 as + follows:

$ curl http://localhost/
$ curl https://localhost/

-

Why does the connection hang when I connect to my SSL-aware Apache server?

+

Why does the connection hang when I connect + to my SSL-aware Apache server?

Because you connected with HTTP to the HTTPS port, i.e. you used an URL of the form ``http://'' instead of ``https://''. This also happens the other way round when you connect via HTTPS to a HTTP @@ -258,31 +211,31 @@ author.

your hostname, not localhost (127.0.0.1).

-

Why do I get ``Connection Refused'' messages when trying to access my freshly -installed Apache+mod_ssl server via HTTPS?

-

There can be various reasons. Some of the common mistakes is that people - start Apache with just apachectl start (or +

Why do I get ``Connection Refused'' messages, + when trying to access my newly installed Apache+mod_ssl server via HTTPS?

+

This can happen for various reasons. The most common mistakes + include starting Apache with just apachectl start (or httpd) instead of apachectl startssl (or - httpd -DSSL. Or you're configuration is not correct. At - least make sure that your Listen - directives match your <VirtualHost> - directives. And if all fails, please do yourself a favor and start over with the - default configuration mod_ssl provides you.

+ httpd -DSSL). Your configuration may also be incorrect. + Please make sure that your Listen directives match your + <VirtualHost> + directives. If all else fails, please start afresh, using the default + configuration provided by mod_ssl.

-

In my CGI programs and SSI scripts the various documented -SSL_XXX variables do not exist. Why?

-

Just make sure you have ``SSLOptions +StdEnvVars'' +

Why are the SSL_XXX variables + not available to my CGI & SSI scripts?

+

Please make sure you have ``SSLOptions +StdEnvVars'' enabled for the context of your CGI/SSI requests.

-

How can I use relative hyperlinks to switch between HTTP and -HTTPS?

+

How can I switch between HTTP and HTTPS in relative + hyperlinks?

-

Usually you have to use fully-qualified hyperlinks because - you have to change the URL scheme. But with the help of some URL - manipulations through mod_rewrite you can achieve the same effect while - you still can use relative URLs:

+

Usually, to switch between HTTP and HTTPS, you have to use + fully-qualified hyperlinks (because you have to change the URL + scheme). Using mod_rewrite however, you can + manipulate relative hyperlinks, to achieve the same effect.

RewriteEngine on
RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]
@@ -290,82 +243,127 @@ HTTPS?

This rewrite ruleset lets you use hyperlinks of the form - <a href="document.html:SSL">

+ <a href="document.html:SSL">, to switch to HTTPS + in a relative link.

top
-

About Certificates

+

Certificates

What are RSA Private Keys, CSRs and Certificates?

-

The RSA private key file is a digital file that you can use to decrypt +

An RSA private key file is a digital file that you can use to decrypt messages sent to you. It has a public component which you distribute (via your Certificate file) which allows people to encrypt those messages to - you. A Certificate Signing Request (CSR) is a digital file which contains + you.

+

A Certificate Signing Request (CSR) is a digital file which contains your public key and your name. You send the CSR to a Certifying Authority - (CA) to be converted into a real Certificate. A Certificate contains your + (CA), who will convert it into a real Certificate, by signing it.

+

A Certificate contains your RSA public key, your name, the name of the CA, and is digitally signed by - your CA. Browsers that know the CA can verify the signature on that + the CA. Browsers that know the CA can verify the signature on that Certificate, thereby obtaining your RSA public key. That enables them to - send messages which only you can decrypt. - See the Introduction chapter for a general + send messages which only you can decrypt.

+

See the Introduction chapter for a general description of the SSL protocol.

-

Seems like there is a difference on startup between the original Apache and an SSL-aware Apache?

-

Yes, in general, starting Apache with a built-in mod_ssl is just like - starting an unencumbered Apache, except for the fact that when you have a - pass phrase on your SSL private key file. Then a startup dialog pops up - asking you to enter the pass phrase.

+

Is there a difference on startup between + the original Apache and an SSL-aware Apache?

+

Yes. In general, starting Apache with + mod_ssl built-in is just like starting Apache + without it. However, if you have a passphrase on your SSL private + key file, a startup dialog will pop up which asks you to enter the + pass phrase.

-

To type in the pass phrase manually when starting the server can be - problematic, for instance when starting the server from the system boot - scripts. As an alternative to this situation you can follow the steps - below under ``How can I get rid of the pass-phrase dialog at Apache - startup time?''.

+

Having to manually enter the passphrase when starting the server + can be problematic - for example, when starting the server from the + system boot scripts. In this case, you can follow the steps + below to remove the passphrase from + your private key.

-

Ok, I've got my server installed and want to create a real SSL -server Certificate for it. How do I do it?

-

Here is a step-by-step description:

- +

How do I create a self-signed SSL +Certificate for testing purposes?

    -
  1. Make sure OpenSSL is really installed and in your PATH. - But some commands even work ok when you just run the - ``openssl'' program from within the OpenSSL source tree as - ``./apps/openssl''.
    +
  2. Make sure OpenSSL is installed and in your PATH.
    +
    +
    3. +
  3. Run the following command, to create server.key and + server.crt files:
    + $ openssl req -new -x509 -nodes -out server.crt + -keyout server.key
    + These can be used as follows in your httpd.conf + file: + 
    +             SSLCertificateFile    /path/to/this/server.crt
+             SSLCertificateKeyFile /path/to/this/server.key
+
    +
    4. +
  4. It is important that you are aware that this + server.key does not have any passphrase. + To add a passphrase to the key, you should run the following + command, and enter & verify the passphrase as requested.
    +

    $ openssl rsa -des3 -in server.key -out + server.key.new
    + $ mv server.key.new server.key

    + Please backup the server.key file, and the passphrase + you entered, in a secure location. +
    5. +
+ -
+

How do I create a real SSL Certificate?

+

Here is a step-by-step description:

+
    +
  1. Make sure OpenSSL is installed and in your PATH. +
    +
  2. Create a RSA private key for your Apache server (will be Triple-DES encrypted and PEM formatted):

    $ openssl genrsa -des3 -out server.key 1024

    - Please backup this server.key file and remember the - pass-phrase you had to enter at a secure location. - You can see the details of this RSA private key via the command:
    + Please backup this server.key file and the + pass-phrase you entered in a secure location. + You can see the details of this RSA private key by using the command:

    $ openssl rsa -noout -text -in server.key

    - And you could create a decrypted PEM version (not recommended) - of this RSA private key via:
    + If necessary, you can also create a decrypted PEM version (not + recommended) of this RSA private key with:

    $ openssl rsa -in server.key -out server.key.unsecure

    @@ -380,43 +378,39 @@ server Certificate for it. How do I do it? server when OpenSSL prompts you for the "CommonName", i.e. when you generate a CSR for a website which will be later accessed via https://www.foo.dom/, enter "www.foo.dom" here. - You can see the details of this CSR via the command
    + You can see the details of this CSR by using

    $ openssl req -noout -text -in server.csr

  3. You now have to send this Certificate Signing Request (CSR) to - a Certifying Authority (CA) for signing. The result is then a real - Certificate which can be used for Apache. Here you have two options: - First you can let the CSR sign by a commercial CA like Verisign or - Thawte. Then you usually have to post the CSR into a web form, pay for - the signing and await the signed Certificate you then can store into a - server.crt file. For more information about commercial CAs have a look - at the following locations:
    + a Certifying Authority (CA) to be signed. Once the CSR has been + signed, you will have a real Certificate, which can be used by + Apache. You can have a CSR signed by a commercial CA, or you can + create your own CA to sign it.
    + Commercial CAs usually ask you to post the CSR into a web form, + pay for the signing, and then send a signed Certificate, which + you can store in a server.crt file. For more information about + commercial CAs see the following locations:

    1. Verisign
      - http://digitalid.verisign.com/server/apacheNotice.htm
      2. -
    2. Thawte Consulting
      - - http://www.thawte.com/certs/server/request.html - +
    3. Thawte
      + http://www.thawte.com/
      4. -
    4. CertiSign Certificadora Digital Ltda.
      http://www.certisign.com.br
    5. IKS GmbH
      - - - http://www.iks-jena.de/produkte/ca/ + + http://www.iks-jena.de/leistungen/ca/
    6. Uptime Commerce Ltd.
      @@ -425,24 +419,24 @@ server Certificate for it. How do I do it?
    7. BelSign NV/SA
      - http://www.belsign.be
    - Second you can use your own CA and now have to sign the CSR yourself by - this CA. Read the next answer in this FAQ on how to sign a CSR with - your CA yourself. - You can see the details of the received Certificate via the command:
    + For details on how to create your own CA, and use this to sign + a CSR, see below.
    + + Once your CSR has been signed, you can see the details of the + Certificate as follows:

    $ openssl x509 -noout -text -in server.crt
    4. -
  4. Now you have two files: server.key and - server.crt. These now can be used as following inside your - Apache's httpd.conf file: +
  5. You should now have two files: server.key and + server.crt. These can be used as follows in your + httpd.conf file: 
            SSLCertificateFile    /path/to/this/server.crt
        SSLCertificateKeyFile /path/to/this/server.key
@@ -453,152 +447,138 @@ server Certificate for it. How do I do it?
-

How can I create and use my own Certificate Authority (CA)?

+

How do I create and use my own Certificate Authority (CA)?

The short answer is to use the CA.sh or CA.pl - - script provided by OpenSSL. The long and manual answer is this:

+ script provided by OpenSSL. Unless you have a good reason not to, + you should use these for preference. If you cannot, you can create a + self-signed Certificate as follows:

    -
  1. Create a RSA private key for your CA +
  2. Create a RSA private key for your server (will be Triple-DES encrypted and PEM formatted):

    - $ openssl genrsa -des3 -out ca.key 1024
    -
    - Please backup this ca.key file and remember the - pass-phrase you currently entered at a secure location. - You can see the details of this RSA private key via the command
    - + $ openssl genrsa -des3 -out server.key 1024

    - $ openssl rsa -noout -text -in ca.key
    + Please backup this host.key file and the + pass-phrase you entered in a secure location. + You can see the details of this RSA private key by using the + command:
    + $ openssl rsa -noout -text -in server.key

    - And you can create a decrypted PEM version (not recommended) of this - private key via:
    + If necessary, you can also create a decrypted PEM version (not + recommended) of this RSA private key with:

    - $ openssl rsa -in ca.key -out ca.key.unsecure
    + $ openssl rsa -in server.key -out server.key.unsecure

    -
    3. -
  3. Create a self-signed CA Certificate (X509 structure) - with the RSA key of the CA (output will be PEM formatted):
    +
  4. Create a self-signed Certificate (X509 structure) + with the RSA key you just created (output will be PEM formatted):

    - $ openssl req -new -x509 -days 365 -key ca.key -out ca.crt
    + $ openssl req -new -x509 -nodes -sha1 -days 365 + -key server.key -out server.crt

    - You can see the details of this Certificate via the command:
    + This signs the server CSR and results in a server.crt file.
    + You can see the details of this Certificate using:

    - - $ openssl x509 -noout -text -in ca.crt
    + $ openssl x509 -noout -text -in server.crt

    5. -
  5. Prepare a script for signing which is needed because - the ``openssl ca'' command has some strange requirements - and the default OpenSSL config doesn't allow one easily to use - ``openssl ca'' directly. So a script named - sign.sh is distributed with the mod_ssl distribution - (subdir pkg.contrib/). Use this script for signing. -
    6. - -
  6. Now you can use this CA to sign server CSR's in order to create real - SSL Certificates for use inside an Apache webserver (assuming - you already have a server.csr at hand):
    -
    - $ ./sign.sh server.csr
    -
    - This signs the server CSR and results in a server.crt file.
    - -
-

How can I change the pass-phrase on my private key file?

-

You simply have to read it with the old pass-phrase and write it again - by specifying the new pass-phrase. You can accomplish this with the following +

You simply have to read it with the old pass-phrase and write it again, + specifying the new pass-phrase. You can accomplish this with the following commands:

$ openssl rsa -des3 -in server.key -out server.key.new
$ mv server.key.new server.key

-

Here you're asked two times for a PEM pass-phrase. At the first - prompt enter the old pass-phrase and at the second prompt - enter the new pass-phrase.

+

The first time you're asked for a PEM pass-phrase, you should + enter the old pass-phrase. After that, you'll be asked again to + enter a pass-phrase - this time, use the new pass-phrase. If you + are asked to verify the pass-phrase, you'll need to enter the new + pass-phrase a second time.

How can I get rid of the pass-phrase dialog at Apache startup time?

-

The reason why this dialog pops up at startup and every re-start +

The reason this dialog pops up at startup and every re-start is that the RSA private key inside your server.key file is stored in - encrypted format for security reasons. The pass-phrase is needed to be - able to read and parse this file. When you can be sure that your server is - secure enough you perform two steps:

- + encrypted format for security reasons. The pass-phrase is needed decrypt + this file, so it can be read and parsed. Removing the pass-phrase + removes a layer of security from your server - proceed with caution!

  1. Remove the encryption from the RSA private key (while - preserving the original file):
    + keeping a backup copy of the original file):

    $ cp server.key server.key.org
    $ openssl rsa -in server.key.org -out server.key

    2. -
  2. Make sure the server.key file is now only readable by root:
    +
  3. Make sure the server.key file is only readable by root:

    $ chmod 400 server.key

-

Now server.key will contain an unencrypted copy of the key. - If you point your server at this file it will not prompt you for a +

Now server.key contains an unencrypted copy of the key. + If you point your server at this file, it will not prompt you for a pass-phrase. HOWEVER, if anyone gets this key they will be able to - impersonate you on the net. PLEASE make sure that the permissions on that - file are really such that only root or the web server user can read it + impersonate you on the net. PLEASE make sure that the permissions on this + file are such that only root or the web server user can read it (preferably get your web server to start as root but run as another - server, and have the key readable only by root).

+ user, and have the key readable only by root).

As an alternative approach you can use the ``SSLPassPhraseDialog - exec:/path/to/program'' facility. But keep in mind that this is + exec:/path/to/program'' facility. Bear in mind that this is neither more nor less secure, of course.

How do I verify that a private key matches its Certificate?

-

The private key contains a series of numbers. Two of those numbers form - the "public key", the others are part of your "private key". The "public - key" bits are also embedded in your Certificate (we get them from your - CSR). To check that the public key in your cert matches the public - portion of your private key, you need to view the cert and the key and - compare the numbers. To view the Certificate and the key run the - commands:

+

A private key contains a series of numbers. Two of these numbers form + the "public key", the others are part of the "private key". The "public + key" bits are included when you generate a CSR, and subsequently form + part of the associated Certificate.

+

To check that the public key in your Certificate matches the public + portion of your private key, you simply need to compare these numbers. + To view the Certificate and the key run the commands:

$ openssl x509 -noout -text -in server.crt
$ openssl rsa -noout -text -in server.key

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:

- + Certificate must match. As the public exponent is usually 65537 + and it's difficult to visually check that the long modulus numbers + are the same, you can use the following approach:

$ openssl x509 -noout -modulus -in server.crt | openssl md5
$ openssl rsa -noout -modulus -in server.key | openssl md5

-

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

+

This leaves you with two rather shorter numbers to compare. It is, + in theory, possible that these numbers may be the same, without the + modulus numbers being the same, but the chances of this are + overwhelmingly remote.

+

Should you wish to check to which key or certificate a particular + CSR belongs you can perform the same calculation on the CSR as + follows:

$ openssl req -noout -modulus -in server.csr | openssl md5

-

What does it mean when my connections fail with an "alert bad certificate" -error?

-

Usually when you see errors like OpenSSL: error:14094412: SSL +

Why do connections fail with an "alert +bad certificate" error?

+

Errors such as OpenSSL: error:14094412: SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate 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.

+ logfile, are usually caused a browser which is unable to handle the server + certificate/private-key. For example, Netscape Navigator 3.x is + unable to handle RSA key lengths not equal to 1024 bits.

Why does my 2048-bit private key not work?

-

The private key sizes for SSL must be either 512 or 1024 for compatibility +

The private key sizes for SSL must be either 512 or 1024 bits, 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 @@ -610,154 +590,171 @@ SSLeay version 0.8 to 0.9?

The CA certificates under the path you configured with SSLCACertificatePath are found by SSLeay through hash symlinks. These hash values are generated by the `openssl x509 -noout - -hash' 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 - Makefile mod_ssl placed into this directory.

+ -hash' command. However, the algorithm used to calculate the hash for a + certificate changed between SSLeay 0.8 and 0.9. You will need to remove + all old hash symlinks and create new ones after upgrading. Use the + Makefile provided by mod_ssl.

How can I convert a certificate from PEM to DER format?

-

The default certificate format for SSLeay/OpenSSL is PEM, which actually - is Base64 encoded DER with header and footer lines. For some applications +

The default certificate format for SSLeay/OpenSSL is PEM, which is simply + 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 cert.pem into the - corresponding DER file cert.der with the following command: + corresponding DER file cert.der using the following command: $ openssl x509 -in cert.pem -out cert.der -outform DER

-

I try to install a Verisign certificate. Why can't I find neither the -getca nor getverisign programs Verisign mentions?

-

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 SSLCertificateFile directive. - Remember that you need to give the key file in as well (see - SSLCertificateKeyFile directive). For a better - CA-related overview on SSL certificate fiddling you can look at Thawte's mod_ssl instructions.

- - -

Can I use the Server Gated Cryptography (SGC) facility (aka Verisign Global -ID) also with mod_ssl?

-

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 step up of the clients are then - automatically handled by mod_ssl under run-time. For details please read - the README.GlobalID document in the mod_ssl distribution.

- - -

After I have installed my new Verisign Global ID server certificate, the -browsers complain that they cannot verify the server certificate?

-

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 - SSLCertificateChainFile 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.

+

Why can't I find the +getca or getverisign programs mentioned by +Verisign, for installing my Verisign certificate?

+

Verisign has never provided specific instructions + for Apache+mod_ssl. The instructions provided are for C2Net's + Stronghold (a commercial Apache based server with SSL support).

+

To install your certificate, all you need to do is to save the + certificate to a file, and give the name of that file to the + SSLCertificateFile directive. + You will also need to give it the key file. For more information, + see the SSLCertificateKeyFile + directive.

+ + +

Can I use the Server Gated Cryptography (SGC) +facility (aka Verisign Global ID) with mod_ssl?

+

Yes. mod_ssl has included support for the SGC + facility since version 2.1. No special configuration is required - + just use the Global ID as your server certificate. The + step up of the clients is then automatically handled by + mod_ssl at run-time.

+ + +

Why do browsers complain that they cannot +verify my Verisign Global ID server certificate?

+

Verisign uses an intermediate CA certificate between the root CA + certificate (which is installed in the browsers) and the server + certificate (which you installed on the server). You should have + received this additional CA certificate from Verisign. + If not, complain to them. Then, configure this certificate with the + SSLCertificateChainFile + directive. This ensures that the intermediate CA certificate is + sent to the browser, filling the gap in the certificate chain.

top
-

About SSL Protocol

+

The SSL Protocol

-

Why do I get lots of random SSL protocol errors under heavy server load?

+

Why do I get lots of random SSL protocol +errors under heavy server load?

There can be a number of reasons for this, but the main one is problems with the SSL session Cache specified by the SSLSessionCache directive. The DBM session - cache is most likely the source of the problem, so trying the SHM session cache or - no cache at all may help.

+ cache is the most likely source of the problem, so using the SHM session cache (or + no cache at all) may help.

-

Why has my webserver a higher load now that I run SSL there?

-

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 transferred encrypted. So, when you have a lot of HTTPS - traffic the load increases.

+

Why does my webserver have a higher load, now +that it serves SSL encrypted traffic?

+

SSL uses strong cryptographic encryption, which necessitates a lot of + number crunching. When you request a webpage via HTTPS, everything (even + the images) is encrypted before it is transferred. So increased HTTPS + traffic leads to load increases.

-

Often HTTPS connections to my server require up to 30 seconds for establishing -the connection, although sometimes it works faster?

-

Usually this is caused by using a /dev/random device for - SSLRandomSeed which is blocking in read(2) calls if not - enough entropy is available. Read more about this problem in the reference - chapter under SSLRandomSeed.

+

Why do HTTPS connections to my server +sometimes take up to 30 seconds to establish a connection?

+

This is usually caused by a /dev/random device for + SSLRandomSeed which blocks the + read(2) call until enough entropy is available to service the + request. More information is available in the reference + manual for the SSLRandomSeed + directive.

What SSL Ciphers are supported by mod_ssl?

-

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:

+

Usually, any SSL ciphers supported by the version of OpenSSL in use, + are also supported by mod_ssl. Which ciphers are + available can depend on the way you built OpenSSL. Typically, at + least the following ciphers are supported:

  1. RC4 with MD5
    2. -
  2. RC4 with MD5 (export version restricted to 40-bit key)
  3. RC2 with MD5
  4. RC2 with MD5 (export version restricted to 40-bit key)
  5. IDEA with MD5
  6. DES with MD5
  7. Triple-DES with MD5
    8. -
-

To determine the actual list of supported ciphers you can - run the following command:

+

To determine the actual list of ciphers available, you should run + the following:

$ openssl ciphers -v

-

I want to use Anonymous Diffie-Hellman (ADH) ciphers, but I always get ``no -shared cipher'' errors?

-

In order to use Anonymous Diffie-Hellman (ADH) ciphers, it is not enough - to just put ``ADH'' into your SSLCipherSuite. - Additionally you have to build OpenSSL with - ``-DSSL_ALLOW_ADH''. 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.

+

Why do I get ``no shared cipher'' errors, when +trying to use Anonymous Diffie-Hellman (ADH) ciphers?

+

By default, OpenSSL does not allow ADH ciphers, for security + reasons. Please be sure you are aware of the potential side-effects + if you choose to enable these ciphers.

+

In order to use Anonymous Diffie-Hellman (ADH) ciphers, you must + build OpenSSL with ``-DSSL_ALLOW_ADH'', and then add + ``ADH'' into your SSLCipherSuite.

-

I always just get a 'no shared ciphers' error if -I try to connect to my freshly installed server?

-

Either you have messed up your SSLCipherSuite +

Why do I get a 'no shared ciphers' +error when connecting to my newly installed server?

+

Either you have made a mistake with your + >SSLCipherSuite directive (compare it with the pre-configured example in - httpd.conf-dist) or you have chosen the DSA/DH + httpd.conf-dist) or you chose to use DSA/DH algorithms instead of RSA when you generated your private key - and ignored or overlooked the warnings. If you have chosen - 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.

+ and ignored or overlooked the warnings. If you have chosen + DSA/DH, then your server cannot communicate using RSA-based SSL + ciphers (at least until you configure an additional RSA-based + certificate/key pair). Modern browsers like NS or IE can only + communicate over SSL using RSA ciphers. The result is the + "no shared ciphers" error. To fix this, regenerate your server + certificate/key pair, using the RSA algorithm.

Why can't I use SSL with name-based/non-IP-based virtual hosts?

-

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 +

The reason is very technical, and a somewhat "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 + 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 Host HTTP header field. For this the + certificate, etc.). But in order to go to the correct virtual server + Apache has to know the Host HTTP header field. To do 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!

+ handshake is finished, but the information is needed in order to + complete the SSL handshake phase. Bingo!

Why is it not possible to use Name-Based @@ -771,17 +768,17 @@ Virtual Hosting to identify different SSL virtual hosts?

It comes as rather a shock to learn that it is impossible.

The reason is that the SSL protocol is a separate layer which - encapsulates the HTTP protocol. So the problem is that the SSL session - is a separate transaction that takes place before the HTTP session even - starts. Therefore all the server receives is an SSL request on IP - address X and port Y (usually 443). Since the SSL request does not - contain any Host: field, the server has no way to decide which SSL - virtual host to use. Usually, it will just use the first one it finds - that matches the port and IP address.

+ encapsulates the HTTP protocol. So the SSL session is a separate + transaction, that takes place before the HTTP session has begun. + The server receives an SSL request on IP address X and port Y + (usually 443). Since the SSL request does not contain any Host: + field, the server has no way to decide which SSL virtual host to use. + Usually, it will just use the first one it finds, which matches the + port and IP address specified.

You can, of course, use Name-Based Virtual Hosting to identify many - non-SSL virtual hosts (all on port 80, for example) and then you can - have no more than 1 SSL virtual host (on port 443). But if you do this, + non-SSL virtual hosts (all on port 80, for example) and then + have a single SSL virtual host (on port 443). But if you do this, you must make sure to put the non-SSL port number on the NameVirtualHost directive, e.g.

@@ -789,72 +786,88 @@ Virtual Hosting to identify different SSL virtual hosts? NameVirtualHost 192.168.1.1:80

-

Other workaround solutions are:

- -

Use separate IP addresses for different SSL hosts. - Use different port numbers for different SSL hosts.

- - -

When I use Basic Authentication over HTTPS the lock icon in Netscape browsers -still shows the unlocked state when the dialog pops up. Does this mean the -username/password is still transmitted unencrypted?

-

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 +

Other workaround solutions include:

+ +

Using separate IP addresses for different SSL hosts. + Using different port numbers for different SSL hosts.

+ + +

How do I get SSL compression working?

+

Although SSL compression negotiation was defined in the specification +of SSLv2 and TLS, it took until May 2004 for RFC 3749 to define DEFLATE as +a negotiable standard compression method. +

+

OpenSSL 0.9.8 started to support this by default when compiled with the +zlib option. If both the client and the server support compression, +it will be used. However, most clients still try to initially connect with an +SSLv2 Hello. As SSLv2 did not include an array of prefered compression algorithms +in its handshake, compression cannot be negotiated with these clients. +If the client disables support for SSLv2, either an SSLv3 or TLS Hello +may be sent, depending on which SSL library is used, and compression may +be set up. You can verify whether clients make use of SSL compression by +logging the %{SSL_COMPRESS_METHOD}x variable. +

+ + +

When I use Basic Authentication over HTTPS +the lock icon in Netscape browsers stays unlocked when the dialog pops up. +Does this mean the username/password is being sent unencrypted?

+

No, the username/password is transmitted encrypted. The icon in + Netscape browsers is not actually synchronized with the SSL/TLS layer. + It only toggles to the locked state when the first part of the actual + webpage data is transferred, which may confuse people. The Basic + Authentication facility is part of the HTTP layer, which is above + the SSL/TLS layer in HTTPS. Before any HTTP data communication takes + place in HTTPS, the SSL/TLS layer has already completed its handshake + phase, and switched to encrypted communication. So don't be confused by this icon.

-

When I connect via HTTPS to an Apache+mod_ssl+OpenSSL server with Microsoft Internet -Explorer (MSIE) I get various I/O errors. What is the reason?

+

Why do I get I/O errors when connecting via +HTTPS to an Apache+mod_ssl server with Microsoft Internet Explorer (MSIE)?

The first reason is that the SSL implementation in some MSIE versions has some subtle bugs related to the HTTP keep-alive facility and the SSL close notify alerts on socket connection close. Additionally the interaction - between SSL and HTTP/1.1 features are problematic with some MSIE versions, - too. You've to work-around these problems by forcing - Apache+mod_ssl+OpenSSL to not use HTTP/1.1, keep-alive connections or - 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:

+ between SSL and HTTP/1.1 features are problematic in some MSIE versions. + You can work around these problems by forcing Apache not to use HTTP/1.1, + keep-alive connections or send the SSL close notify messages to MSIE clients. + This can be done by using the following directive in your SSL-aware + virtual host section:

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

-

Additionally it is known some MSIE versions have also problems - with particular ciphers. Unfortunately one cannot workaround these - bugs only for those MSIE particular clients, because the ciphers - are already used in the SSL handshake phase. So a MSIE-specific - SetEnvIf doesn't work - to solve these problems. Instead one has to do more drastic - adjustments to the global parameters. But before you decide to do - this, make sure your clients really have problems. If not, do not - do this, because it affects all(!) your clients, i.e., also your - non-MSIE clients.

- -

The next problem is that 56bit export versions of MSIE 5.x browsers have a - broken SSLv3 implementation which badly interacts with OpenSSL versions - greater than 0.9.4. You can either accept this and force your clients to - upgrade their browsers, or you downgrade to OpenSSL 0.9.4 (hmmm), or you - can decide to workaround it by accepting the drawback that your workaround - will horribly affect also other browsers:

+

Further, some MSIE versions have problems with particular ciphers. + Unfortunately, it is not possible to implement a MSIE-specific + workaround for this, because the ciphers are needed as early as the + SSL handshake phase. So a MSIE-specific + SetEnvIf won't solve these + problems. Instead, you will have to make more drastic + adjustments to the global parameters. Before you decide to do + this, make sure your clients really have problems. If not, do not + make these changes - they will affect all your clients, MSIE + or otherwise.

+ +

The next problem is that 56bit export versions of MSIE 5.x + browsers have a broken SSLv3 implementation, which interacts badly + with OpenSSL versions greater than 0.9.4. You can accept this and + require your clients to upgrade their browsers, you can downgrade to + OpenSSL 0.9.4 (not advised), or you can work around this, accepting + that your workaround will affect other browsers too:

SSLProtocol all -SSLv3

-

This completely disables the SSLv3 protocol and lets those browsers work. - But usually this is an even less acceptable workaround. A more reasonable - workaround is to address the problem more closely and disable only the +

will completely disables the SSLv3 protocol and allow those + browsers to work. A better workaround is to disable only those ciphers which cause trouble.

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

-

This also lets the broken MSIE versions work, but only removes the +

This also allows the broken MSIE versions to work, but only removes the newer 56bit TLS ciphers.

Another problem with MSIE 5.x clients is that they refuse to connect to - URLs of the form https://12.34.56.78/ (IP-addresses are used + URLs of the form https://12.34.56.78/ (where IP-addresses are used instead of the hostname), if the server is using the Server Gated Cryptography (SGC) facility. This can only be avoided by using the fully qualified domain name (FQDN) of the website in hyperlinks instead, because @@ -862,31 +875,35 @@ Explorer (MSIE) I get various I/O errors. What is the reason?

And finally there are versions of MSIE which seem to require that an SSL session can be reused (a totally non standard-conforming - behaviour, of course). Connection with those MSIE versions only work + behaviour, of course). Connecting with those MSIE versions only work if a SSL session cache is used. So, as a work-around, make sure you - are using a session cache (see SSLSessionCache directive).

+ are using a session cache (see the SSLSessionCache directive).

-

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?

+

Why do I get I/O errors, or the message "Netscape has +encountered bad data from the server", when connecting via +HTTPS to an Apache+mod_ssl server with Netscape Navigator?

- The problem usually is that you had created a new server certificate with - the same DN, but you had told your browser to accept forever the old - server certificate. Once you clear the entry in your browser for the old - certificate, everything usually will work fine. Netscape's SSL + This usually occurs when you have created a new server certificate for + a given domain, but had previously told your browser to always accept + the old server certificate. Once you clear the entry for the old + certificate from your browser, everything should be fine. Netscape's SSL implementation is correct, so when you encounter I/O errors with Netscape - Navigator it is most of the time caused by the configured certificates.

+ Navigator it is usually caused by the configured certificates.

top
-

About Support

+

mod_ssl Support

What information resources are available in case of mod_ssl problems?

@@ -895,83 +912,92 @@ server" What's the reason?
Answers in the User Manual's F.A.Q. List (this)
-
- http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html
- First look inside the F.A.Q. (this text), perhaps your problem is such - popular that it was already answered a lot of times in the past. +
+ http://httpd.apache.org/docs/2.1/ssl/ssl_faq.html
+ First check the F.A.Q. (this text). If your problem is a common + one, it may have been answered several times before, and been included + in this doc.
Postings from the modssl-users Support Mailing List http://www.modssl.org/support/
-
Second search for your problem in one of the existing archives of the - modssl-users mailing list. Perhaps your problem popped up at least once for - another user, too. +
Search for your problem in the archives of the modssl-users mailing list. + You're probably not the first person to have had this problem!
-

What support contacts are available in case of mod_ssl problems?

+

What support contacts are available in case +of mod_ssl problems?

The following lists all support possibilities for mod_ssl, in order of - preference, i.e. start in this order and do not pick the support possibility - you just like most, please.

- + preference. Please go through these possibilities + in this order - don't just pick the one you like the look of.

    -
  1. Write a Problem Report into the Bug Database
    - - http://www.modssl.org/support/bugdb/
    - This is the preferred way of submitting your problem report, because this - way it gets filed into the bug database (it cannot be lost) and - send to the modssl-users mailing list (others see the current problems and - learn from answers). -
    2. - -
  2. Write a Problem Report to the modssl-users Support Mailing List
    +
  3. Send a Problem Report to the modssl-users Support Mailing List
    modssl-users@modssl.org
    - This is the second way of submitting your problem report. You have to - subscribe to the list first, but then you can easily discuss your problem - with both the author and the whole mod_ssl user community. + This is the preferred way of submitting your problem report, because this way, + others can see the problem, and learn from any answers. You must subscribe to + the list first, but you can then easily discuss your problem with both the + author and the whole mod_ssl user community. +
    4. + +
  4. Send a Problem Report to the Apache httpd Users Support Mailing List
    + + users@httpd.apache.org
    + This is the second way of submitting your problem report. Again, you must + subscribe to the list first, but you can then easily discuss your problem + with the whole Apache httpd user community. +
    5. + +
  5. Write a Problem Report in the Bug Database
    + + http://httpd.apache.org/bug_report.html
    + This is the last way of submitting your problem report. You should only + do this if you've already posted to the mailing lists, and had no success. + Please follow the instructions on the above page carefully.
-

What information and details should I - provide when writing a bug report?

-

You have to at least always provide the following information:

+

What information should I +provide when writing a bug report?

+

You should always provide at least the following information:

Apache and OpenSSL version information
The Apache version can be determined by running httpd -v. The OpenSSL version can be - determined by running openssl version. Alternatively when - you have Lynx installed you can run the command lynx -mime_header - http://localhost/ | grep Server to determine all information in a + determined by running openssl version. Alternatively, if + you have Lynx installed, you can run the command lynx -mime_header + http://localhost/ | grep Server to gather this information in a single step.
The details on how you built and installed Apache+mod_ssl+OpenSSL
For this you can provide a logfile of your terminal session which shows - the configuration and install steps. Alternatively you can at least - provide the configure command line you used. + the configuration and install steps. If this is not possible, you + should at least provide the configure command line you used.
In case of core dumps please include a Backtrace
-
In case your Apache+mod_ssl+OpenSSL should really dump core please attach - a stack-frame ``backtrace'' (see the next question on how to get it). - Without this information the reason for your core dump cannot be found. - So you have to provide the backtrace, please. +
If your Apache+mod_ssl+OpenSSL dumps its core, please attach + a stack-frame ``backtrace'' (see below + for information on how to get this). Without this information, the + reason for your core dump cannot be found
A detailed description of your problem
-
Don't laugh, I'm totally serious. I already got a lot of problem reports - where the people not really said what's the actual problem is. So, in your - own interest (you want the problem be solved, don't you?) include as much - details as possible, please. But start with the essentials first, of - course. +
Don't laugh, we really mean it! Many problem reports don't + include a description of what the actual problem is. Without this, + it's very difficult for anyone to help you. So, it's in your own + interest (you want the problem be solved, don't you?) to include as + much detail as possible, please. Of course, you should still include + all the essentials above too.
-

I got a core dump, can you help me?

+

I had a core dump, can you help me?

In general no, at least not unless you provide more details about the code location where Apache dumped core. What is usually always required in order to help you is a backtrace (see next question). Without this @@ -979,32 +1005,32 @@ server" What's the reason? fixing it.

-

Ok, I got a core dump but how do I get a backtrace to find out the reason for it?

-

Follow the following steps:

+

How do I get a backtrace, to help find +the reason for my core dump?

+

Following are the steps you will need to complete, to get a backtrace:

    -
  1. Make sure you have debugging symbols available in at least - Apache. On platforms where you use GCC/GDB you have to build - Apache+mod_ssl with ``OPTIM="-g -ggdb3"'' to achieve this. On +
  2. Make sure you have debugging symbols available, at least + in Apache. On platforms where you use GCC/GDB, you will have to build + Apache+mod_ssl with ``OPTIM="-g -ggdb3"'' to get this. On other platforms at least ``OPTIM="-g"'' is needed.
    3. -
  3. Startup the server and try to produce the core-dump. For this you perhaps +
  4. Start the server and try to reproduce the core-dump. For this you may want to use a directive like ``CoreDumpDirectory /tmp'' to - make sure that the core-dump file can be written. You then should get a - /tmp/core or /tmp/httpd.core file. When you - don't get this, try to run your server under an UID != 0 (root), because - most "current" kernels do not allow a process to dump core after it has + make sure that the core-dump file can be written. This should result + in a /tmp/core or /tmp/httpd.core file. If you + don't get one of these, try running your server under a non-root UID. + Many modern kernels do not allow a process to dump core after it has done a setuid() (unless it does an exec()) for security reasons (there can be privileged information left over in - memory). Additionally you can run /path/to/httpd -X + memory). If necessary, you can run /path/to/httpd -X manually to force Apache to not fork.
    5. -
  5. Analyze the core-dump. For this run gdb /path/to/httpd - /tmp/httpd.core or a similar command has to run. In GDB you then - just have to enter the bt command and, voila, you get the - backtrace. For other debuggers consult your local debugger manual. Send - this backtrace to the author. +
  6. Analyze the core-dump. For this, run gdb /path/to/httpd + /tmp/httpd.core or a similar command. In GDB, all you + have to do then is to enter bt, and voila, you get the + backtrace. For other debuggers consult your local debugger manual.
diff --git a/docs/manual/ssl/ssl_faq.xml b/docs/manual/ssl/ssl_faq.xml index 6498e2fa67b..8dbdf9d1a68 100644 --- a/docs/manual/ssl/ssl_faq.xml +++ b/docs/manual/ssl/ssl_faq.xml @@ -62,62 +62,26 @@ author.

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.

- - -

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.

- -

After the US export restrictions for cryptographic software were - opened, mod_ssl was integrated into the code base of Apache V2 in 2001.

- - -
Is mod_ssl Year 2000 compliant? -

Yes, mod_ssl is Year 2000 compliant.

- -

Because first mod_ssl internally never stores years as two digits. - Instead it always uses the ANSI C & POSIX numerical data type - time_t type, which on almost all Unix platforms at the moment - is a signed long (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 ``%{TIME_YEAR}'') - are done with full year value instead of abbreviating to two digits.

- + 1998.

-

Additionally according to a Year 2000 - statement 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.

+

After US export restrictions on cryptographic software were + loosened, mod_ssl became part of the Apache HTTP + Server with the release of Apache httpd 2.

-
What about mod_ssl and the Wassenaar Arrangement? +
Is mod_ssl affected by the Wassenaar Arrangement?

First, let us explain what Wassenaar and its Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and - Technologies is: This is a international regime, established 1995, to + Technologies is: This is a international regime, established in 1995, to control trade in conventional arms and dual-use goods and technology. It - replaced the previous CoCom 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 CoCom regime. Further details on + both the Arrangement and its signatories are available at http://www.wassenaar.org/.

- -

In short: The aim of the Wassenaar Arrangement is to prevent the build up +

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 + cryptography as a dual-use good, that is, something 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.

@@ -125,67 +89,44 @@ author.

Munitions, under GENERAL SOFTWARE NOTE (GSN) it says The Lists do not control "software" which is either: 1. [...] 2. "in the public domain". And under DEFINITIONS OF TERMS USED IN - THESE LISTS one can find the definition: In the public - domain": This means "technology" or "software" which has been made - available without restrictions upon its further dissemination. N.B. + THESE LISTS we find In the public + domain defined as "technology" or "software" which has been made + available without restrictions upon its further dissemination. Note: Copyright restrictions do not remove "technology" or "software" from being "in the public domain".

So, both mod_ssl and OpenSSL are in the public domain for the purposes - of the Wassenaar Agreement and its List of Dual Use Goods and - Technologies And Munitions List.

+ of the Wassenaar Arrangement and its List of Dual Use Goods and + Technologies And Munitions List, and thus not affected by its provisions.

-

So, mod_ssl and OpenSSL are not affected by the Wassenaar Agreement.

-
About Installation +
Installation -
When I access my website the first time via HTTPS I get a core dump? -

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 --enable-rule=SSL_SDBM at the - APACI command line) or switch from SSLSessionCache dbm: to the - newer SSLSessionCache shm:'' variant (after you have rebuilt - Apache with MM, of course).

-
- -
When I startup Apache I get permission errors related to SSLMutex? -

When you receive entries like ``mod_ssl: Child could not open +

Why do I get permission errors related to + SSLMutex when I start Apache? +

Errors such as ``mod_ssl: Child could not open SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) - [...] System: Permission denied (errno: 13)'' this is usually - caused by to restrictive permissions on the parent directories. + [...] System: Permission denied (errno: 13)'' are usually + caused by overly restrictive permissions on the parent directories. Make sure that all parent directories (here /opt, /opt/apache and /opt/apache/logs) have the x-bit - set at least for the UID under which Apache's children are running (see - the User directive of Apache).

-
- -
When I use the MM library and the shared memory cache each process grows -1.5MB according to `top' although I specified 512000 as the cache size? -

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 SSLSessionCache. - But don't be confused by the display of `top': although is - indicates that each 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.

+ set for, at minimum, the UID under which Apache's children are running (see + the User directive).

-
When I fire up the server, mod_ssl stops with the error -"Failed to generate temporary 512 bit RSA private key", why? -

Cryptographic software needs a source of unpredictable data +

Why does mod_ssl stop with the error + "Failed to generate temporary 512 bit RSA private key", when I start + Apache? +

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 /dev/random). On other systems, applications have to @@ -193,68 +134,79 @@ author.

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 - SSLRandomSeed directives.

+ at least 128 bits of randomness.

+

To prevent this error, mod_ssl has to provide + enough entropy to the PRNG to allow it to work correctly. This can + be done via the SSLRandomSeed + directives.

-
About Configuration +
Configuration -
Is it possible to provide HTTP and HTTPS with a single server? -

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.

+
Is it possible to provide HTTP and HTTPS + from the same server? +

Yes. HTTP and HTTPS use different server ports (HTTP binds to + port 80, HTTPS to port 443), so there is no direct conflict between + them. You can either run two separate server instances bound to + these ports, or use Apache's elegant virtual hosting facility to + create two virtual servers over one instance of Apache - one + responding to requests on port 80 and speaking HTTP and the other + responding to requests on port 443 speaking HTTPS.

-
I know that HTTP is on port 80, but where is HTTPS? +
Which port does HTTPS use?

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): https://secure.server.dom:666/

-
How can I speak HTTPS manually for testing purposes? +
How do I speak HTTPS manually for testing purposes?

While you usually just use

$ telnet localhost 80
GET / HTTP/1.0 - -

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 s_client command you can do a similar - check even for HTTPS:

+

for simple testing of Apache via HTTP, it's not so easy for + HTTPS because of the SSL protocol between TCP and HTTP. With the + help of OpenSSL's s_client command, however, you can + do a similar check for HTTPS:

$ openssl s_client -connect localhost:443 -state -debug
GET / HTTP/1.0 -

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 cURL - tool. With it you can directly check if your Apache is running fine on - Port 80 and 443 as following:

+

Before the actual HTTP response you will receive detailed + information about the SSL handshake. For a more general command + line client which directly understands both HTTP and HTTPS, can + perform GET and POST operations, can use a proxy, supports byte + ranges, etc. you should have a look at the nifty + cURL tool. Using this, you can + check that Apache is responding correctly on ports 80 and 443 as + follows:

$ curl http://localhost/
$ curl https://localhost/
-
Why does the connection hang when I connect to my SSL-aware Apache server? +
Why does the connection hang when I connect + to my SSL-aware Apache server?

Because you connected with HTTP to the HTTPS port, i.e. you used an URL of the form ``http://'' instead of ``https://''. This also happens the other way round when you connect via HTTPS to a HTTP @@ -264,31 +216,32 @@ author.

your hostname, not localhost (127.0.0.1).

-
Why do I get ``Connection Refused'' messages when trying to access my freshly -installed Apache+mod_ssl server via HTTPS? -

There can be various reasons. Some of the common mistakes is that people - start Apache with just apachectl start (or +

Why do I get ``Connection Refused'' messages, + when trying to access my newly installed Apache+mod_ssl server via HTTPS? +

This can happen for various reasons. The most common mistakes + include starting Apache with just apachectl start (or httpd) instead of apachectl startssl (or - httpd -DSSL. Or you're configuration is not correct. At - least make sure that your Listen - directives match your VirtualHost - directives. And if all fails, please do yourself a favor and start over with the - default configuration mod_ssl provides you.

+ httpd -DSSL). Your configuration may also be incorrect. + Please make sure that your Listen directives match your + VirtualHost + directives. If all else fails, please start afresh, using the default + configuration provided by mod_ssl.

-
In my CGI programs and SSI scripts the various documented -<code>SSL_XXX</code> variables do not exist. Why? -

Just make sure you have ``SSLOptions +StdEnvVars'' +

Why are the <code>SSL_XXX</code> variables + not available to my CGI & SSI scripts? +

Please make sure you have ``SSLOptions +StdEnvVars'' enabled for the context of your CGI/SSI requests.

-How can I use relative hyperlinks to switch between HTTP and -HTTPS? -

Usually you have to use fully-qualified hyperlinks because - you have to change the URL scheme. But with the help of some URL - manipulations through mod_rewrite you can achieve the same effect while - you still can use relative URLs:

+How can I switch between HTTP and HTTPS in relative + hyperlinks? +

Usually, to switch between HTTP and HTTPS, you have to use + fully-qualified hyperlinks (because you have to change the URL + scheme). Using mod_rewrite however, you can + manipulate relative hyperlinks, to achieve the same effect.

RewriteEngine on
RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]
@@ -296,83 +249,128 @@ HTTPS?

This rewrite ruleset lets you use hyperlinks of the form - <a href="document.html:SSL">

+ <a href="document.html:SSL">, to switch to HTTPS + in a relative link.

-
About Certificates +
Certificates
What are RSA Private Keys, CSRs and Certificates? -

The RSA private key file is a digital file that you can use to decrypt +

An RSA private key file is a digital file that you can use to decrypt messages sent to you. It has a public component which you distribute (via your Certificate file) which allows people to encrypt those messages to - you. A Certificate Signing Request (CSR) is a digital file which contains + you.

+

A Certificate Signing Request (CSR) is a digital file which contains your public key and your name. You send the CSR to a Certifying Authority - (CA) to be converted into a real Certificate. A Certificate contains your + (CA), who will convert it into a real Certificate, by signing it.

+

A Certificate contains your RSA public key, your name, the name of the CA, and is digitally signed by - your CA. Browsers that know the CA can verify the signature on that + the CA. Browsers that know the CA can verify the signature on that Certificate, thereby obtaining your RSA public key. That enables them to - send messages which only you can decrypt. - See the Introduction chapter for a general + send messages which only you can decrypt.

+

See the Introduction chapter for a general description of the SSL protocol.

-
Seems like there is a difference on startup between the original Apache and an SSL-aware Apache? -

Yes, in general, starting Apache with a built-in mod_ssl is just like - starting an unencumbered Apache, except for the fact that when you have a - pass phrase on your SSL private key file. Then a startup dialog pops up - asking you to enter the pass phrase.

+
Is there a difference on startup between + the original Apache and an SSL-aware Apache? +

Yes. In general, starting Apache with + mod_ssl built-in is just like starting Apache + without it. However, if you have a passphrase on your SSL private + key file, a startup dialog will pop up which asks you to enter the + pass phrase.

-

To type in the pass phrase manually when starting the server can be - problematic, for instance when starting the server from the system boot - scripts. As an alternative to this situation you can follow the steps - below under ``How can I get rid of the pass-phrase dialog at Apache - startup time?''.

+

Having to manually enter the passphrase when starting the server + can be problematic - for example, when starting the server from the + system boot scripts. In this case, you can follow the steps + below to remove the passphrase from + your private key.

-
Ok, I've got my server installed and want to create a real SSL -server Certificate for it. How do I do it? -

Here is a step-by-step description:

- +
How do I create a self-signed SSL +Certificate for testing purposes?
    -
  1. Make sure OpenSSL is really installed and in your PATH. - But some commands even work ok when you just run the - ``openssl'' program from within the OpenSSL source tree as - ``./apps/openssl''.
    +
  2. Make sure OpenSSL is installed and in your PATH.
    +
    +
    3. +
  3. Run the following command, to create server.key and + server.crt files:
    + $ openssl req -new -x509 -nodes -out server.crt + -keyout server.key
    + These can be used as follows in your httpd.conf + file: + 
    +             SSLCertificateFile    /path/to/this/server.crt
+             SSLCertificateKeyFile /path/to/this/server.key
+
    +
    4. +
  4. It is important that you are aware that this + server.key does not have any passphrase. + To add a passphrase to the key, you should run the following + command, and enter & verify the passphrase as requested.
    +

    $ openssl rsa -des3 -in server.key -out + server.key.new
    + $ mv server.key.new server.key

    + Please backup the server.key file, and the passphrase + you entered, in a secure location. +
    5. +
+
-
+
How do I create a real SSL Certificate? +

Here is a step-by-step description:

+
    +
  1. Make sure OpenSSL is installed and in your PATH. +
    +
  2. Create a RSA private key for your Apache server (will be Triple-DES encrypted and PEM formatted):

    $ openssl genrsa -des3 -out server.key 1024

    - Please backup this server.key file and remember the - pass-phrase you had to enter at a secure location. - You can see the details of this RSA private key via the command:
    + Please backup this server.key file and the + pass-phrase you entered in a secure location. + You can see the details of this RSA private key by using the command:

    $ openssl rsa -noout -text -in server.key

    - And you could create a decrypted PEM version (not recommended) - of this RSA private key via:
    + If necessary, you can also create a decrypted PEM version (not + recommended) of this RSA private key with:

    $ openssl rsa -in server.key -out server.key.unsecure

    @@ -387,43 +385,39 @@ server Certificate for it. How do I do it? server when OpenSSL prompts you for the "CommonName", i.e. when you generate a CSR for a website which will be later accessed via https://www.foo.dom/, enter "www.foo.dom" here. - You can see the details of this CSR via the command
    + You can see the details of this CSR by using

    $ openssl req -noout -text -in server.csr

  3. You now have to send this Certificate Signing Request (CSR) to - a Certifying Authority (CA) for signing. The result is then a real - Certificate which can be used for Apache. Here you have two options: - First you can let the CSR sign by a commercial CA like Verisign or - Thawte. Then you usually have to post the CSR into a web form, pay for - the signing and await the signed Certificate you then can store into a - server.crt file. For more information about commercial CAs have a look - at the following locations:
    + a Certifying Authority (CA) to be signed. Once the CSR has been + signed, you will have a real Certificate, which can be used by + Apache. You can have a CSR signed by a commercial CA, or you can + create your own CA to sign it.
    + Commercial CAs usually ask you to post the CSR into a web form, + pay for the signing, and then send a signed Certificate, which + you can store in a server.crt file. For more information about + commercial CAs see the following locations:

    1. Verisign
      - http://digitalid.verisign.com/server/apacheNotice.htm
      2. -
    2. Thawte Consulting
      - - http://www.thawte.com/certs/server/request.html - +
    3. Thawte
      + http://www.thawte.com/
      4. -
    4. CertiSign Certificadora Digital Ltda.
      http://www.certisign.com.br
    5. IKS GmbH
      - - - http://www.iks-jena.de/produkte/ca/ + + http://www.iks-jena.de/leistungen/ca/
    6. Uptime Commerce Ltd.
      @@ -432,24 +426,24 @@ server Certificate for it. How do I do it?
    7. BelSign NV/SA
      - http://www.belsign.be
    - Second you can use your own CA and now have to sign the CSR yourself by - this CA. Read the next answer in this FAQ on how to sign a CSR with - your CA yourself. - You can see the details of the received Certificate via the command:
    + For details on how to create your own CA, and use this to sign + a CSR, see below.
    + + Once your CSR has been signed, you can see the details of the + Certificate as follows:

    $ openssl x509 -noout -text -in server.crt
    4. -
  4. Now you have two files: server.key and - server.crt. These now can be used as following inside your - Apache's httpd.conf file: +
  5. You should now have two files: server.key and + server.crt. These can be used as follows in your + httpd.conf file: 
            SSLCertificateFile    /path/to/this/server.crt
        SSLCertificateKeyFile /path/to/this/server.key
@@ -460,152 +454,138 @@ server Certificate for it. How do I do it?
-
How can I create and use my own Certificate Authority (CA)? +
How do I create and use my own Certificate Authority (CA)?

The short answer is to use the CA.sh or CA.pl - - script provided by OpenSSL. The long and manual answer is this:

+ script provided by OpenSSL. Unless you have a good reason not to, + you should use these for preference. If you cannot, you can create a + self-signed Certificate as follows:

    -
  1. Create a RSA private key for your CA +
  2. Create a RSA private key for your server (will be Triple-DES encrypted and PEM formatted):

    - $ openssl genrsa -des3 -out ca.key 1024
    -
    - Please backup this ca.key file and remember the - pass-phrase you currently entered at a secure location. - You can see the details of this RSA private key via the command
    - + $ openssl genrsa -des3 -out server.key 1024

    - $ openssl rsa -noout -text -in ca.key
    + Please backup this host.key file and the + pass-phrase you entered in a secure location. + You can see the details of this RSA private key by using the + command:
    + $ openssl rsa -noout -text -in server.key

    - And you can create a decrypted PEM version (not recommended) of this - private key via:
    + If necessary, you can also create a decrypted PEM version (not + recommended) of this RSA private key with:

    - $ openssl rsa -in ca.key -out ca.key.unsecure
    + $ openssl rsa -in server.key -out server.key.unsecure

    -
    3. -
  3. Create a self-signed CA Certificate (X509 structure) - with the RSA key of the CA (output will be PEM formatted):
    -
    - $ openssl req -new -x509 -days 365 -key ca.key -out ca.crt
    -
    - You can see the details of this Certificate via the command:
    +
  4. Create a self-signed Certificate (X509 structure) + with the RSA key you just created (output will be PEM formatted):

    - - $ openssl x509 -noout -text -in ca.crt
    + $ openssl req -new -x509 -nodes -sha1 -days 365 + -key server.key -out server.crt

    -
    5. -
  5. Prepare a script for signing which is needed because - the ``openssl ca'' command has some strange requirements - and the default OpenSSL config doesn't allow one easily to use - ``openssl ca'' directly. So a script named - sign.sh is distributed with the mod_ssl distribution - (subdir pkg.contrib/). Use this script for signing. -
    6. - -
  6. Now you can use this CA to sign server CSR's in order to create real - SSL Certificates for use inside an Apache webserver (assuming - you already have a server.csr at hand):
    + This signs the server CSR and results in a server.crt file.
    + You can see the details of this Certificate using:

    - $ ./sign.sh server.csr
    + $ openssl x509 -noout -text -in server.crt

    - This signs the server CSR and results in a server.crt file.
    -
-
How can I change the pass-phrase on my private key file? -

You simply have to read it with the old pass-phrase and write it again - by specifying the new pass-phrase. You can accomplish this with the following +

You simply have to read it with the old pass-phrase and write it again, + specifying the new pass-phrase. You can accomplish this with the following commands:

$ openssl rsa -des3 -in server.key -out server.key.new
$ mv server.key.new server.key

-

Here you're asked two times for a PEM pass-phrase. At the first - prompt enter the old pass-phrase and at the second prompt - enter the new pass-phrase.

+

The first time you're asked for a PEM pass-phrase, you should + enter the old pass-phrase. After that, you'll be asked again to + enter a pass-phrase - this time, use the new pass-phrase. If you + are asked to verify the pass-phrase, you'll need to enter the new + pass-phrase a second time.

How can I get rid of the pass-phrase dialog at Apache startup time? -

The reason why this dialog pops up at startup and every re-start +

The reason this dialog pops up at startup and every re-start is that the RSA private key inside your server.key file is stored in - encrypted format for security reasons. The pass-phrase is needed to be - able to read and parse this file. When you can be sure that your server is - secure enough you perform two steps:

- + encrypted format for security reasons. The pass-phrase is needed decrypt + this file, so it can be read and parsed. Removing the pass-phrase + removes a layer of security from your server - proceed with caution!

  1. Remove the encryption from the RSA private key (while - preserving the original file):
    + keeping a backup copy of the original file):

    $ cp server.key server.key.org
    $ openssl rsa -in server.key.org -out server.key

    2. -
  2. Make sure the server.key file is now only readable by root:
    +
  3. Make sure the server.key file is only readable by root:

    $ chmod 400 server.key

-

Now server.key will contain an unencrypted copy of the key. - If you point your server at this file it will not prompt you for a +

Now server.key contains an unencrypted copy of the key. + If you point your server at this file, it will not prompt you for a pass-phrase. HOWEVER, if anyone gets this key they will be able to - impersonate you on the net. PLEASE make sure that the permissions on that - file are really such that only root or the web server user can read it + impersonate you on the net. PLEASE make sure that the permissions on this + file are such that only root or the web server user can read it (preferably get your web server to start as root but run as another - server, and have the key readable only by root).

+ user, and have the key readable only by root).

As an alternative approach you can use the ``SSLPassPhraseDialog - exec:/path/to/program'' facility. But keep in mind that this is + exec:/path/to/program'' facility. Bear in mind that this is neither more nor less secure, of course.

How do I verify that a private key matches its Certificate? -

The private key contains a series of numbers. Two of those numbers form - the "public key", the others are part of your "private key". The "public - key" bits are also embedded in your Certificate (we get them from your - CSR). To check that the public key in your cert matches the public - portion of your private key, you need to view the cert and the key and - compare the numbers. To view the Certificate and the key run the - commands:

+

A private key contains a series of numbers. Two of these numbers form + the "public key", the others are part of the "private key". The "public + key" bits are included when you generate a CSR, and subsequently form + part of the associated Certificate.

+

To check that the public key in your Certificate matches the public + portion of your private key, you simply need to compare these numbers. + To view the Certificate and the key run the commands:

$ openssl x509 -noout -text -in server.crt
$ openssl rsa -noout -text -in server.key

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:

- + Certificate must match. As the public exponent is usually 65537 + and it's difficult to visually check that the long modulus numbers + are the same, you can use the following approach:

$ openssl x509 -noout -modulus -in server.crt | openssl md5
$ openssl rsa -noout -modulus -in server.key | openssl md5

-

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

+

This leaves you with two rather shorter numbers to compare. It is, + in theory, possible that these numbers may be the same, without the + modulus numbers being the same, but the chances of this are + overwhelmingly remote.

+

Should you wish to check to which key or certificate a particular + CSR belongs you can perform the same calculation on the CSR as + follows:

$ openssl req -noout -modulus -in server.csr | openssl md5

-
What does it mean when my connections fail with an "alert bad certificate" -error? -

Usually when you see errors like OpenSSL: error:14094412: SSL +

Why do connections fail with an "alert +bad certificate" error? +

Errors such as OpenSSL: error:14094412: SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate 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.

+ logfile, are usually caused a browser which is unable to handle the server + certificate/private-key. For example, Netscape Navigator 3.x is + unable to handle RSA key lengths not equal to 1024 bits.

Why does my 2048-bit private key not work? -

The private key sizes for SSL must be either 512 or 1024 for compatibility +

The private key sizes for SSL must be either 512 or 1024 bits, 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 @@ -617,156 +597,173 @@ SSLeay version 0.8 to 0.9?

The CA certificates under the path you configured with SSLCACertificatePath are found by SSLeay through hash symlinks. These hash values are generated by the `openssl x509 -noout - -hash' 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 - Makefile mod_ssl placed into this directory.

+ -hash' command. However, the algorithm used to calculate the hash for a + certificate changed between SSLeay 0.8 and 0.9. You will need to remove + all old hash symlinks and create new ones after upgrading. Use the + Makefile provided by mod_ssl.

How can I convert a certificate from PEM to DER format? -

The default certificate format for SSLeay/OpenSSL is PEM, which actually - is Base64 encoded DER with header and footer lines. For some applications +

The default certificate format for SSLeay/OpenSSL is PEM, which is simply + 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 cert.pem into the - corresponding DER file cert.der with the following command: + corresponding DER file cert.der using the following command: $ openssl x509 -in cert.pem -out cert.der -outform DER

-
I try to install a Verisign certificate. Why can't I find neither the -<code>getca</code> nor <code>getverisign</code> programs Verisign mentions? -

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 SSLCertificateFile directive. - Remember that you need to give the key file in as well (see - SSLCertificateKeyFile directive). For a better - CA-related overview on SSL certificate fiddling you can look at Thawte's mod_ssl instructions.

+
Why can't I find the +<code>getca</code> or <code>getverisign</code> programs mentioned by +Verisign, for installing my Verisign certificate? +

Verisign has never provided specific instructions + for Apache+mod_ssl. The instructions provided are for C2Net's + Stronghold (a commercial Apache based server with SSL support).

+

To install your certificate, all you need to do is to save the + certificate to a file, and give the name of that file to the + SSLCertificateFile directive. + You will also need to give it the key file. For more information, + see the SSLCertificateKeyFile + directive.

-
Can I use the Server Gated Cryptography (SGC) facility (aka Verisign Global -ID) also with mod_ssl? -

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 step up of the clients are then - automatically handled by mod_ssl under run-time. For details please read - the README.GlobalID document in the mod_ssl distribution.

+
Can I use the Server Gated Cryptography (SGC) +facility (aka Verisign Global ID) with mod_ssl? +

Yes. mod_ssl has included support for the SGC + facility since version 2.1. No special configuration is required - + just use the Global ID as your server certificate. The + step up of the clients is then automatically handled by + mod_ssl at run-time.

-
After I have installed my new Verisign Global ID server certificate, the -browsers complain that they cannot verify the server certificate? -

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 - SSLCertificateChainFile 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.

+
Why do browsers complain that they cannot +verify my Verisign Global ID server certificate? +

Verisign uses an intermediate CA certificate between the root CA + certificate (which is installed in the browsers) and the server + certificate (which you installed on the server). You should have + received this additional CA certificate from Verisign. + If not, complain to them. Then, configure this certificate with the + SSLCertificateChainFile + directive. This ensures that the intermediate CA certificate is + sent to the browser, filling the gap in the certificate chain.

-
About SSL Protocol +
The SSL Protocol -
Why do I get lots of random SSL protocol errors under heavy server load? +
Why do I get lots of random SSL protocol +errors under heavy server load?

There can be a number of reasons for this, but the main one is problems with the SSL session Cache specified by the SSLSessionCache directive. The DBM session - cache is most likely the source of the problem, so trying the SHM session cache or - no cache at all may help.

+ cache is the most likely source of the problem, so using the SHM session cache (or + no cache at all) may help.

-
Why has my webserver a higher load now that I run SSL there? -

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 transferred encrypted. So, when you have a lot of HTTPS - traffic the load increases.

+
Why does my webserver have a higher load, now +that it serves SSL encrypted traffic? +

SSL uses strong cryptographic encryption, which necessitates a lot of + number crunching. When you request a webpage via HTTPS, everything (even + the images) is encrypted before it is transferred. So increased HTTPS + traffic leads to load increases.

-
Often HTTPS connections to my server require up to 30 seconds for establishing -the connection, although sometimes it works faster? -

Usually this is caused by using a /dev/random device for - SSLRandomSeed which is blocking in read(2) calls if not - enough entropy is available. Read more about this problem in the reference - chapter under SSLRandomSeed.

+
Why do HTTPS connections to my server +sometimes take up to 30 seconds to establish a connection? +

This is usually caused by a /dev/random device for + SSLRandomSeed which blocks the + read(2) call until enough entropy is available to service the + request. More information is available in the reference + manual for the SSLRandomSeed + directive.

What SSL Ciphers are supported by mod_ssl? -

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:

+

Usually, any SSL ciphers supported by the version of OpenSSL in use, + are also supported by mod_ssl. Which ciphers are + available can depend on the way you built OpenSSL. Typically, at + least the following ciphers are supported:

  1. RC4 with MD5
    2. -
  2. RC4 with MD5 (export version restricted to 40-bit key)
  3. RC2 with MD5
  4. RC2 with MD5 (export version restricted to 40-bit key)
  5. IDEA with MD5
  6. DES with MD5
  7. Triple-DES with MD5
    8. -
-

To determine the actual list of supported ciphers you can - run the following command:

+

To determine the actual list of ciphers available, you should run + the following:

$ openssl ciphers -v
-
I want to use Anonymous Diffie-Hellman (ADH) ciphers, but I always get ``no -shared cipher'' errors? -

In order to use Anonymous Diffie-Hellman (ADH) ciphers, it is not enough - to just put ``ADH'' into your SSLCipherSuite. - Additionally you have to build OpenSSL with - ``-DSSL_ALLOW_ADH''. 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.

+
Why do I get ``no shared cipher'' errors, when +trying to use Anonymous Diffie-Hellman (ADH) ciphers? +

By default, OpenSSL does not allow ADH ciphers, for security + reasons. Please be sure you are aware of the potential side-effects + if you choose to enable these ciphers.

+

In order to use Anonymous Diffie-Hellman (ADH) ciphers, you must + build OpenSSL with ``-DSSL_ALLOW_ADH'', and then add + ``ADH'' into your SSLCipherSuite.

-
I always just get a 'no shared ciphers' error if -I try to connect to my freshly installed server? -

Either you have messed up your SSLCipherSuite +

Why do I get a 'no shared ciphers' +error when connecting to my newly installed server? +

Either you have made a mistake with your + >SSLCipherSuite directive (compare it with the pre-configured example in - httpd.conf-dist) or you have chosen the DSA/DH + httpd.conf-dist) or you chose to use DSA/DH algorithms instead of RSA when you generated your private key - and ignored or overlooked the warnings. If you have chosen - 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.

+ and ignored or overlooked the warnings. If you have chosen + DSA/DH, then your server cannot communicate using RSA-based SSL + ciphers (at least until you configure an additional RSA-based + certificate/key pair). Modern browsers like NS or IE can only + communicate over SSL using RSA ciphers. The result is the + "no shared ciphers" error. To fix this, regenerate your server + certificate/key pair, using the RSA algorithm.

Why can't I use SSL with name-based/non-IP-based virtual hosts? -

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 +

The reason is very technical, and a somewhat "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 + 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 Host HTTP header field. For this the + certificate, etc.). But in order to go to the correct virtual server + Apache has to know the Host HTTP header field. To do 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!

+ handshake is finished, but the information is needed in order to + complete the SSL handshake phase. Bingo!

Why is it not possible to use Name-Based @@ -780,17 +777,17 @@ Virtual Hosting to identify different SSL virtual hosts?

It comes as rather a shock to learn that it is impossible.

The reason is that the SSL protocol is a separate layer which - encapsulates the HTTP protocol. So the problem is that the SSL session - is a separate transaction that takes place before the HTTP session even - starts. Therefore all the server receives is an SSL request on IP - address X and port Y (usually 443). Since the SSL request does not - contain any Host: field, the server has no way to decide which SSL - virtual host to use. Usually, it will just use the first one it finds - that matches the port and IP address.

+ encapsulates the HTTP protocol. So the SSL session is a separate + transaction, that takes place before the HTTP session has begun. + The server receives an SSL request on IP address X and port Y + (usually 443). Since the SSL request does not contain any Host: + field, the server has no way to decide which SSL virtual host to use. + Usually, it will just use the first one it finds, which matches the + port and IP address specified.

You can, of course, use Name-Based Virtual Hosting to identify many - non-SSL virtual hosts (all on port 80, for example) and then you can - have no more than 1 SSL virtual host (on port 443). But if you do this, + non-SSL virtual hosts (all on port 80, for example) and then + have a single SSL virtual host (on port 443). But if you do this, you must make sure to put the non-SSL port number on the NameVirtualHost directive, e.g.

@@ -798,72 +795,88 @@ Virtual Hosting to identify different SSL virtual hosts? NameVirtualHost 192.168.1.1:80 -

Other workaround solutions are:

+

Other workaround solutions include:

-

Use separate IP addresses for different SSL hosts. - Use different port numbers for different SSL hosts.

+

Using separate IP addresses for different SSL hosts. + Using different port numbers for different SSL hosts.

-
When I use Basic Authentication over HTTPS the lock icon in Netscape browsers -still shows the unlocked state when the dialog pops up. Does this mean the -username/password is still transmitted unencrypted? -

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 +

How do I get SSL compression working? +

Although SSL compression negotiation was defined in the specification +of SSLv2 and TLS, it took until May 2004 for RFC 3749 to define DEFLATE as +a negotiable standard compression method. +

+

OpenSSL 0.9.8 started to support this by default when compiled with the +zlib option. If both the client and the server support compression, +it will be used. However, most clients still try to initially connect with an +SSLv2 Hello. As SSLv2 did not include an array of prefered compression algorithms +in its handshake, compression cannot be negotiated with these clients. +If the client disables support for SSLv2, either an SSLv3 or TLS Hello +may be sent, depending on which SSL library is used, and compression may +be set up. You can verify whether clients make use of SSL compression by +logging the %{SSL_COMPRESS_METHOD}x variable. +

+
+ +
When I use Basic Authentication over HTTPS +the lock icon in Netscape browsers stays unlocked when the dialog pops up. +Does this mean the username/password is being sent unencrypted? +

No, the username/password is transmitted encrypted. The icon in + Netscape browsers is not actually synchronized with the SSL/TLS layer. + It only toggles to the locked state when the first part of the actual + webpage data is transferred, which may confuse people. The Basic + Authentication facility is part of the HTTP layer, which is above + the SSL/TLS layer in HTTPS. Before any HTTP data communication takes + place in HTTPS, the SSL/TLS layer has already completed its handshake + phase, and switched to encrypted communication. So don't be confused by this icon.

-
When I connect via HTTPS to an Apache+mod_ssl+OpenSSL server with Microsoft Internet -Explorer (MSIE) I get various I/O errors. What is the reason? +
Why do I get I/O errors when connecting via +HTTPS to an Apache+mod_ssl server with Microsoft Internet Explorer (MSIE)?

The first reason is that the SSL implementation in some MSIE versions has some subtle bugs related to the HTTP keep-alive facility and the SSL close notify alerts on socket connection close. Additionally the interaction - between SSL and HTTP/1.1 features are problematic with some MSIE versions, - too. You've to work-around these problems by forcing - Apache+mod_ssl+OpenSSL to not use HTTP/1.1, keep-alive connections or - 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:

+ between SSL and HTTP/1.1 features are problematic in some MSIE versions. + You can work around these problems by forcing Apache not to use HTTP/1.1, + keep-alive connections or send the SSL close notify messages to MSIE clients. + This can be done by using the following directive in your SSL-aware + virtual host section:

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0 -

Additionally it is known some MSIE versions have also problems - with particular ciphers. Unfortunately one cannot workaround these - bugs only for those MSIE particular clients, because the ciphers - are already used in the SSL handshake phase. So a MSIE-specific - SetEnvIf doesn't work - to solve these problems. Instead one has to do more drastic - adjustments to the global parameters. But before you decide to do - this, make sure your clients really have problems. If not, do not - do this, because it affects all(!) your clients, i.e., also your - non-MSIE clients.

- -

The next problem is that 56bit export versions of MSIE 5.x browsers have a - broken SSLv3 implementation which badly interacts with OpenSSL versions - greater than 0.9.4. You can either accept this and force your clients to - upgrade their browsers, or you downgrade to OpenSSL 0.9.4 (hmmm), or you - can decide to workaround it by accepting the drawback that your workaround - will horribly affect also other browsers:

+

Further, some MSIE versions have problems with particular ciphers. + Unfortunately, it is not possible to implement a MSIE-specific + workaround for this, because the ciphers are needed as early as the + SSL handshake phase. So a MSIE-specific + SetEnvIf won't solve these + problems. Instead, you will have to make more drastic + adjustments to the global parameters. Before you decide to do + this, make sure your clients really have problems. If not, do not + make these changes - they will affect all your clients, MSIE + or otherwise.

+ +

The next problem is that 56bit export versions of MSIE 5.x + browsers have a broken SSLv3 implementation, which interacts badly + with OpenSSL versions greater than 0.9.4. You can accept this and + require your clients to upgrade their browsers, you can downgrade to + OpenSSL 0.9.4 (not advised), or you can work around this, accepting + that your workaround will affect other browsers too:

SSLProtocol all -SSLv3 -

This completely disables the SSLv3 protocol and lets those browsers work. - But usually this is an even less acceptable workaround. A more reasonable - workaround is to address the problem more closely and disable only the +

will completely disables the SSLv3 protocol and allow those + browsers to work. A better workaround is to disable only those ciphers which cause trouble.

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

-

This also lets the broken MSIE versions work, but only removes the +

This also allows the broken MSIE versions to work, but only removes the newer 56bit TLS ciphers.

Another problem with MSIE 5.x clients is that they refuse to connect to - URLs of the form https://12.34.56.78/ (IP-addresses are used + URLs of the form https://12.34.56.78/ (where IP-addresses are used instead of the hostname), if the server is using the Server Gated Cryptography (SGC) facility. This can only be avoided by using the fully qualified domain name (FQDN) of the website in hyperlinks instead, because @@ -871,33 +884,37 @@ Explorer (MSIE) I get various I/O errors. What is the reason?

And finally there are versions of MSIE which seem to require that an SSL session can be reused (a totally non standard-conforming - behaviour, of course). Connection with those MSIE versions only work + behaviour, of course). Connecting with those MSIE versions only work if a SSL session cache is used. So, as a work-around, make sure you - are using a session cache (see SSLSessionCache directive).

-
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? +
Why do I get I/O errors, or the message "Netscape has +encountered bad data from the server", when connecting via +HTTPS to an Apache+mod_ssl server with Netscape Navigator?

- The problem usually is that you had created a new server certificate with - the same DN, but you had told your browser to accept forever the old - server certificate. Once you clear the entry in your browser for the old - certificate, everything usually will work fine. Netscape's SSL + This usually occurs when you have created a new server certificate for + a given domain, but had previously told your browser to always accept + the old server certificate. Once you clear the entry for the old + certificate from your browser, everything should be fine. Netscape's SSL implementation is correct, so when you encounter I/O errors with Netscape - Navigator it is most of the time caused by the configured certificates.

+ Navigator it is usually caused by the configured certificates.

-
About Support +
mod_ssl Support
What information resources are available in case of mod_ssl problems? @@ -906,84 +923,93 @@ server" What's the reason?
Answers in the User Manual's F.A.Q. List (this)
-
- http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html
- First look inside the F.A.Q. (this text), perhaps your problem is such - popular that it was already answered a lot of times in the past. +
+ http://httpd.apache.org/docs/2.1/ssl/ssl_faq.html
+ First check the F.A.Q. (this text). If your problem is a common + one, it may have been answered several times before, and been included + in this doc.
Postings from the modssl-users Support Mailing List http://www.modssl.org/support/
-
Second search for your problem in one of the existing archives of the - modssl-users mailing list. Perhaps your problem popped up at least once for - another user, too. +
Search for your problem in the archives of the modssl-users mailing list. + You're probably not the first person to have had this problem!
-
What support contacts are available in case of mod_ssl problems? +
What support contacts are available in case +of mod_ssl problems?

The following lists all support possibilities for mod_ssl, in order of - preference, i.e. start in this order and do not pick the support possibility - you just like most, please.

- + preference. Please go through these possibilities + in this order - don't just pick the one you like the look of.

    -
  1. Write a Problem Report into the Bug Database
    - - http://www.modssl.org/support/bugdb/
    - This is the preferred way of submitting your problem report, because this - way it gets filed into the bug database (it cannot be lost) and - send to the modssl-users mailing list (others see the current problems and - learn from answers). -
    2. - -
  2. Write a Problem Report to the modssl-users Support Mailing List
    +
  3. Send a Problem Report to the modssl-users Support Mailing List
    modssl-users@modssl.org
    - This is the second way of submitting your problem report. You have to - subscribe to the list first, but then you can easily discuss your problem - with both the author and the whole mod_ssl user community. + This is the preferred way of submitting your problem report, because this way, + others can see the problem, and learn from any answers. You must subscribe to + the list first, but you can then easily discuss your problem with both the + author and the whole mod_ssl user community. +
    4. + +
  4. Send a Problem Report to the Apache httpd Users Support Mailing List
    + + users@httpd.apache.org
    + This is the second way of submitting your problem report. Again, you must + subscribe to the list first, but you can then easily discuss your problem + with the whole Apache httpd user community. +
    5. + +
  5. Write a Problem Report in the Bug Database
    + + http://httpd.apache.org/bug_report.html
    + This is the last way of submitting your problem report. You should only + do this if you've already posted to the mailing lists, and had no success. + Please follow the instructions on the above page carefully.
-
What information and details should I - provide when writing a bug report? -

You have to at least always provide the following information:

+
What information should I +provide when writing a bug report? +

You should always provide at least the following information:

Apache and OpenSSL version information
The Apache version can be determined by running httpd -v. The OpenSSL version can be - determined by running openssl version. Alternatively when - you have Lynx installed you can run the command lynx -mime_header - http://localhost/ | grep Server to determine all information in a + determined by running openssl version. Alternatively, if + you have Lynx installed, you can run the command lynx -mime_header + http://localhost/ | grep Server to gather this information in a single step.
The details on how you built and installed Apache+mod_ssl+OpenSSL
For this you can provide a logfile of your terminal session which shows - the configuration and install steps. Alternatively you can at least - provide the configure command line you used. + the configuration and install steps. If this is not possible, you + should at least provide the configure command line you used.
In case of core dumps please include a Backtrace
-
In case your Apache+mod_ssl+OpenSSL should really dump core please attach - a stack-frame ``backtrace'' (see the next question on how to get it). - Without this information the reason for your core dump cannot be found. - So you have to provide the backtrace, please. +
If your Apache+mod_ssl+OpenSSL dumps its core, please attach + a stack-frame ``backtrace'' (see below + for information on how to get this). Without this information, the + reason for your core dump cannot be found
A detailed description of your problem
-
Don't laugh, I'm totally serious. I already got a lot of problem reports - where the people not really said what's the actual problem is. So, in your - own interest (you want the problem be solved, don't you?) include as much - details as possible, please. But start with the essentials first, of - course. +
Don't laugh, we really mean it! Many problem reports don't + include a description of what the actual problem is. Without this, + it's very difficult for anyone to help you. So, it's in your own + interest (you want the problem be solved, don't you?) to include as + much detail as possible, please. Of course, you should still include + all the essentials above too.
-
I got a core dump, can you help me? +
I had a core dump, can you help me?

In general no, at least not unless you provide more details about the code location where Apache dumped core. What is usually always required in order to help you is a backtrace (see next question). Without this @@ -991,32 +1017,32 @@ server" What's the reason? fixing it.

-
Ok, I got a core dump but how do I get a backtrace to find out the reason for it? -

Follow the following steps:

+
How do I get a backtrace, to help find +the reason for my core dump? +

Following are the steps you will need to complete, to get a backtrace:

    -
  1. Make sure you have debugging symbols available in at least - Apache. On platforms where you use GCC/GDB you have to build - Apache+mod_ssl with ``OPTIM="-g -ggdb3"'' to achieve this. On +
  2. Make sure you have debugging symbols available, at least + in Apache. On platforms where you use GCC/GDB, you will have to build + Apache+mod_ssl with ``OPTIM="-g -ggdb3"'' to get this. On other platforms at least ``OPTIM="-g"'' is needed.
    3. -
  3. Startup the server and try to produce the core-dump. For this you perhaps +
  4. Start the server and try to reproduce the core-dump. For this you may want to use a directive like ``CoreDumpDirectory /tmp'' to - make sure that the core-dump file can be written. You then should get a - /tmp/core or /tmp/httpd.core file. When you - don't get this, try to run your server under an UID != 0 (root), because - most "current" kernels do not allow a process to dump core after it has + make sure that the core-dump file can be written. This should result + in a /tmp/core or /tmp/httpd.core file. If you + don't get one of these, try running your server under a non-root UID. + Many modern kernels do not allow a process to dump core after it has done a setuid() (unless it does an exec()) for security reasons (there can be privileged information left over in - memory). Additionally you can run /path/to/httpd -X + memory). If necessary, you can run /path/to/httpd -X manually to force Apache to not fork.
    5. -
  5. Analyze the core-dump. For this run gdb /path/to/httpd - /tmp/httpd.core or a similar command has to run. In GDB you then - just have to enter the bt command and, voila, you get the - backtrace. For other debuggers consult your local debugger manual. Send - this backtrace to the author. +
  6. Analyze the core-dump. For this, run gdb /path/to/httpd + /tmp/httpd.core or a similar command. In GDB, all you + have to do then is to enter bt, and voila, you get the + backtrace. For other debuggers consult your local debugger manual.
diff --git a/docs/manual/style/build.properties b/docs/manual/style/build.properties index 9a3cd6acfa6..35705593706 100644 --- a/docs/manual/style/build.properties +++ b/docs/manual/style/build.properties @@ -4,4 +4,4 @@ noxml.fr=new_features_2_0.html.fr upgrading.html.fr # (pending) httpd version -httpd.version=2.0.55 +httpd.version=2.0.56 diff --git a/docs/manual/style/latex/latex.xsl b/docs/manual/style/latex/latex.xsl index 59002e2c279..b4068b268da 100644 --- a/docs/manual/style/latex/latex.xsl +++ b/docs/manual/style/latex/latex.xsl @@ -107,7 +107,7 @@ \section*{About The PDF Documentation} -Copyright \copyright 2004 The Apache Software Foundation +Copyright \copyright 2005 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. @@ -138,6 +138,9 @@ Server Documentation Project. More information is available at } + + + \end{document} diff --git a/docs/manual/vhosts/mass.html.en b/docs/manual/vhosts/mass.html.en index 6732be8ad2e..2c53a8a5659 100644 --- a/docs/manual/vhosts/mass.html.en +++ b/docs/manual/vhosts/mass.html.en @@ -432,7 +432,7 @@ RewriteRule ^/(.*)$ %1/docs/$1
RewriteCond %{REQUEST_URI} ^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
-RewriteRule ^/(.*)$ %1/cgi-bin/$1 +RewriteRule ^/(.*)$ %1/cgi-bin/$1 [T=application/x-httpd-cgi]

diff --git a/docs/manual/vhosts/mass.html.ko.euc-kr b/docs/manual/vhosts/mass.html.ko.euc-kr index 759e82d2eb7..e3a1797422d 100644 --- a/docs/manual/vhosts/mass.html.ko.euc-kr +++ b/docs/manual/vhosts/mass.html.ko.euc-kr @@ -21,6 +21,8 @@

°¡´ÉÇÑ ¾ð¾î:  en  |  ko 

+
ÀÌ ¹®¼­´Â ÃÖ½ÅÆÇ ¹ø¿ªÀÌ ¾Æ´Õ´Ï´Ù. + ÃÖ±Ù¿¡ º¯°æµÈ ³»¿ëÀº ¿µ¾î ¹®¼­¸¦ Âü°íÇϼ¼¿ä.

ÀÌ ¹®¼­´Â ¾ÆÆÄÄ¡ 1.3¿¡¼­ ´ë·®ÀÇ °¡»óÈ£½ºÆ®¸¦ È¿À²ÀûÀ¸·Î diff --git a/docs/manual/vhosts/mass.xml b/docs/manual/vhosts/mass.xml index 8e3dc063e12..8b47adf8d84 100644 --- a/docs/manual/vhosts/mass.xml +++ b/docs/manual/vhosts/mass.xml @@ -430,7 +430,7 @@ RewriteRule ^/(.*)$ %1/docs/$1
RewriteCond %{REQUEST_URI} ^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
-RewriteRule ^/(.*)$ %1/cgi-bin/$1 +RewriteRule ^/(.*)$ %1/cgi-bin/$1 [T=application/x-httpd-cgi] diff --git a/docs/manual/vhosts/mass.xml.ko b/docs/manual/vhosts/mass.xml.ko index 280d2626e7a..a6108e8b5af 100644 --- a/docs/manual/vhosts/mass.xml.ko +++ b/docs/manual/vhosts/mass.xml.ko @@ -1,7 +1,7 @@ - +