SSL certificates on Apache Virtual Servers

Discussion in 'Linux Networking' started by KM, Oct 3, 2005.

  1. KM

    KM Guest

    Cross posted to alt.apache.config and comp.os.linux.networking

    Hi,

    I want to create a number of Apache Virtual Servers for different customers.
    I have a requirement to provide a Secure Sockets Layer using HTTPS.

    http://www.instantssl.com/ssl-certificate-support/server_faq/ssl-server-certificate-apache.html

    has a line saying:

    <snip>
    When I access my secure site, a certificate for another site is displayed
    This problem occurs if you assign the same IP address to each host in your
    config file. SSL does not support name based virtual hosting (host headers
    are encrypted in SSL), so only the first certificate listed in your config
    file will be used.
    </snip>

    So, as these are commercial customers, how can I configure the Virtual
    Servers/Certificates so that they authenticate properly. We were planning to
    use a single IP address for all servers, behind a content switch, but now I
    am unsure exactly what configuration options I have available.

    Anyone suggest a solution or have I misunderstood the problem.

    Thanks


    Martyn
     
    KM, Oct 3, 2005
    #1
    1. Advertisements

  2. As far as I know this is just not possible. For a detailed explanation
    see:

    http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts

    Essentially the problem is that https handshake occurs before your
    server can get to the host name in the request. While it can direct a
    client to the right virtual host, the server certificate will allready
    have been presented to the client.
     
    tim.bruijnzeels, Oct 3, 2005
    #2
    1. Advertisements

  3. KM

    KM Guest

    Thanks

    I was starting to suspect that. :-(

    Martyn

    --
    ===========================
    Martyn Kinder G0CZD

    Open-Xchange 0.8b5

    http://www.czd.org.uk
     
    KM, Oct 3, 2005
    #3
  4. However, you can do it for subdomains with a wildcard SSL cert so that
    *.exmaple.com all use the same cert without warnings (AIUI). The only
    thing you'd have to do is get the one wildcard cert and set up each
    client with a subdomain instead... May not be what you are after, but
    gives you another option to look into anyway.
     
    Justin Koivisto, Oct 3, 2005
    #4
  5. You really should not be hosting commercial customers on a shared IP
    address. You should by now have discovered at least one reason why that
    doesn't make very much sense.

    DS
     
    David Schwartz, Oct 4, 2005
    #5
  6. You really should not be hosting commercial customers on a shared IP address. You should by now have discovered at least one reason
    and why not host on a shared ip address as isp's do this all the time to reserve ip addresses for other services !!!
     
    Newsgroup Poster, Oct 4, 2005
    #6
  7. I think the present case serves as a very good demonstration of what
    some of the problems are. There are lots more. For example:

    1) Not all protocols (for example SSL) can support name-based hosting.
    What do you do when the customer decides they need an FTP site as well?

    2) Reverse address resolution will not give any information about the
    host the user tried to reach. This can cause problems with logfiles,
    firewalls, and other issues. If a program legitimately tries to access
    'www.trustedsite.com' but the firewall/router log or alter box shows a
    connection attempt to 'www.siteineverheardof.com', how do I know the
    connection should be allowed? If the web site, for example, is used as a
    place for compromised machines to post their IP addresses, network logs
    won't show the appropriate person to contact.

    3) Even for HTTP, name-based hosting is a hack. Not all browsers even
    support name-based hosting. What do you do if you receive a request that has
    no headers? (Which is perfectly legal.)

    4) It creates cross-site security issues with Java. (Java's security
    model assumes that the IP of the server that sent the Java client can be
    trusted. If that IP is not under common administration, that assumption
    becomes false.)

    5) It just doesn't look professional. Sometimes it can result in the
    hosting company being contacted when the customer should be contacted (due
    to reverse DNS). This forces the hosting company to figure out the right
    customer and refer a contact to them. This makes your customer look
    amateurish.

    6) Error messages can't always be appropriate. Server administration
    identification can't always be correct. Log files can't always be correct.
    (For example, suppose some error causes a connection to break before the
    Host header is sent or received. What customer is having the issue?)

    7) If DNS has problems, troubleshooting is much harder. How can you tell
    if your web page is working if DNS is not working?

    These are just the most obvious reasons. There are lots of subtle and
    more bizarre ones that you run into. The plus is what exactly? IPs are not
    that scarce.

    DS
     
    David Schwartz, Oct 4, 2005
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.