06-12-2006 03:41 PM
I am using:
HP-UX 11i v1, and the HP apache depot for version 2.0.55. The system has two network cards with one of them with two ip addresses 139.x.y.z1 and 139.x.y.z2
I can start the web server in ssl mode using ../bin/apachectl startssl.
All but the main web can only be contacted with a url like http://139.x.y.z1:443. Using a url like https:/139.x.y.z1 gives an empty page and no apparent error message. The main web service can be contacted through the other network card with something like https://139.x.y1.z3. I was also trying to trap any other access and not give any access.
I have included what I think are the relevant parts of the httpd.conf file. Any assistance greatly appreciated.
# httpd.conf bits
Deny from all
# ServerAdmin firstname.lastname@example.org
Options Indexes FollowSymLinks
Allow from all
Solved! Go to Solution.
06-12-2006 08:00 PM
Apache can handle having several SSL and non-SSL virtual hosts inside one Apache instance. You need to add the directive "SSLEngine on" for each SSL virtual host. You also need to specify a SSL certificate for them: the directive is "SSLCertificateFile /some/where/certificate.pem". You also need the private key for each certificate, which can be attached to the certificate or it can be a separate .pem file.
With the OpenSSL tools, you can create a certificate for free, but it will be "untrusted" unless the browser is explicitly configured to trust that certificate. To get a certificate that will be trusted by any Web browser, you need to buy one from a Certification Authority like VeriSign.
Currently, what you have is a simple set of HTTP virtual hosts in a non-standard port (i.e. 443).
If you try an URL like https://139.x.y.z1, the browser tries to start up a SSL negotiation, which looks like a bunch of gibberish from a HTTP server viewpoint. The browser, on the other hand, sees the server's plain-HTTP error message as "some data that is not a valid SSL session". Because the SSL session did not get established, the only possible error message is going to be the browser's "could not establish a SSL connection", when the browser finally gives up on trying.
In case you are trying name-based virtual hosting (several virtual hosts in the same IP address and TCP port), it does not work at all with HTTPS.
Basically, you have a chicken-and-egg problem: you need to know which virtual host the client wants to be able to offer the correct certificate, but that knowledge is in the SSL-secured HTTPS request, which won't even get sent before the SSL encryption session is established.
06-13-2006 10:27 AM
Thanks for the info. Just what I needed. It is all so straight forward with the right key.
I have simply taken bits from ../conf/ssl./conf and included them with each virtual host and all work great.
Thankyou for your quick response.