In this issue

The ApacheCon Europe 2001 conference scheduled for Dublin in October has been cancelled, due to financial difficulties with Camelot Communications. Camelot are the production company who produced all but the very first ApacheCon conferences. The Apache Software Foundation today released the following statement:

Due to financial considerations beyond our control and unrelated to past ApacheCon conferences, our conference producer has decided that they are unable to produce the upcoming ApacheCon Europe 2001 in Dublin. With only three months left before the conference was scheduled to begin, The Apache Software Foundation has decided that it is in the best interests of attendees to cancel the show now rather than attempt to find another conference organizer for the Dublin event.

We had suspected there was a problem with the conference when we were contacted by Peter Moulding, a speaker at ApacheCon 2001 in Santa Clara. Peter said that he had not had his travel refunded and that the conference organisers, Camelot Communications, had called him to tell him they were closing the company. We were unable to get an official response from Camelot or the Apache Software Foundation in time to run the story in issue 254 (13th July 2001).

It is disappointing that Camelot is unable to produce the conference; the previous conferences that they have run have been well attended, made a profit, and been highly rewarding for everyone involved. The Apache Software Foundation are about to begin evaluating proposals by other conference organisers so that future ApacheCon events will not be affected. More news in Apache Week and on the conference web site as it becomes available.

We've received a large number of messages over the last few days from system administrators who have seen worrying entries in their Apache access logs. The requests look like this:

192.168.2.12 - - [19/Jul/2001:16:55:47 +0100] "GET /default.ida?NNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%
u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a
  HTTP/1.0" 400 252 -

If you are running Apache there is nothing to worry about, these requests are part of the Code Red Worm virus designed to search out vulnerable IIS servers running on Windows.

However if you'd like to become vulnerable to attacks such as this, Microsoft have a toolkit that will let to migrate from Apache to IIS. (Allegedly the last step is append the text "3L33T crew ownz you" to the bottom of all your web pages to save the crackers some time)

A server certificate is a piece of digitally signed information that lets the browser know what organisation it is accessing when making SSL/TLS transactions. To prevent people from just making up certificates and pretending to be official organisations, certificates can be obtained from certificate authorities (CAs), who use their position as a third-party to verify that the organisation using the certificate is who they say they are.

Probably the best known CA is Verisign in the US. In fact, early versions of Netscape Navigator (version 1) would only accept certificates from Verisign. Other CAs can be used but unless they are recognised by the browser manufacturers they will either be rejected when a user tries to connect or the user will be given a long sequence of warning screens. So basically the browser providers get to choose which CAs their browser will accept, and therefore control the list of companies you can pay to obtain one from.

Because the CA usually has to do some work checking your credentials and signing your requests they charge for this service. Certificates can cost from US$125 to US$350 or more. Earlier this month we were alerted to a company providing SSL certificates for free. It sounded too good to be true, but it works; when we tried it we got our certificate back within a few hours of the request.

However there is a catch; the certificate is only compatible with Internet Explorer version 5 or above. Try accessing a secure site with their certificate installed from a different browser such as Netscape or Mozilla and the standard warnings are displayed. Perhaps this is why they've purchased a certificate from Equifax for their own site.

In this section we highlight some of the articles on the web that are of interest to Apache users.

John Coggeshall continues with Part 3 of "Sending MIME e-mail from PHP" by completing his discussion on the MIME format. He explains about the multipart/related content-type and multi-bounding MIME messages, and will implement all these using PHP in Part 4 of the MIME mail series.

This basic tutorial shows you how to configure client authentication for an existing Apache+mod_ssl Web server. It only outlines the steps for creating a personal Certificate Authority (CA) and server certificate but you may refer to the links provided for more information.

PC Quest have a short and simple article on various load-balancing techniques for Web servers in general. It serves as a good introduction to this subject.

Next week we'll be bringing you a special issue of Apache Week live from the O'Reilly Open Source Convention in San Diego. If you are going to the conference come and look for us in the Red Hat booth on Friday and pick up an exclusive Apache Week postcard.