[Gllug] simple https troubleshooting?

Tue May 13 15:49:07 UTC 2008

As Bruce pointed out, you'll need to bind to an externally facing address,
not just localhost. Localhost is an interface without a physical interface -
it is only accessible from the local host. You could try binding to *, or to
a specific IP address which is externally accessible (even if it's through
some sort of NAT).
Also, SSL and Named Virtual Hosts don't work really well together, as Apache
needs to know the name in the HTTP request before it knows which Virtual
Host to serve, but the SSL handshake happens before this. Hence, there can
be no more than one SSL certificate on each IP address.
ie the sequence is:

DNS lookup for name.com, finds IP address
Connect over TCP to IP address
SSL handshake (certificate for name.com presented)
HTTP conversation - request data for name.com

Does that make sense?

So, I would rebind to an external port, then try the same steps again. To
troubleshoot effectively, perhaps try it on HTTP first - get one thing
working at a time, then slowly add complexity like you're baking a cake (
http://uk.youtube.com/watch?v=S7GGkKpBR-g).

Also, when testing with openssl, you probably want to use something like:

openssl s_client -connect host:443

...and you should see the certificate chain. There's heaps of options - h
ttp://www.madboa.com/geek/openssl is a good reference...

Richard

On Tue, May 13, 2008 at 4:16 PM, Avi Greenbury <
avismailinglistaccount at googlemail.com> wrote:

> On Fri, 9 May 2008 16:19:55 +0100
> "Richard Russell" <richard.a.russell at gmail.com> wrote:
>
> >    1. Check that your server is binding to the right port with lsof or
> >    netstat or similar (can't remember the latest tool for this job).
>
> Looks right to my untrained eye:
>
> shrek:/home/avi# lsof -i | grep https
> apache2    8798    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2    8804    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2   10585    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2   10586    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2   12482    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2   13942    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2   13944    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2   31490   root    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2   31500    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2   31502    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
> apache2   31508    dtc    5u  IPv4 6877453       TCP localhost:https
> (LISTEN)
>
> >    2. Telnet to the port from the server.
>
> I can get a connection, and a response. Not entirely sure what the HTTP400
> relates to, though.
>
> shrek:~$ telnet localhost 443
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> HEAD / HTTP/1.1
>
> HTTP/1.1 400 Bad Request
> Date: Tue, 13 May 2008 10:25:38 GMT
> Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch10 mod_ssl/2.2.3
> OpenSSL/0.9.8c
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> Connection closed by foreign host.
>
> >    3. Use openssl commandline tool to see if you can see the certificate
> on
> >    that port from the server.
>
> In trying this, I found that Apache had no certificates (which in
> hindsight is to be expected, since I don't remember creating any). I used
> mod-ssl-makecert (as suggested in, I think a debian-administration.co.ukarticle).
>
> So, having made one, I get this (is this what you meant?):
>
> shrek:~$ openssl s_server -cert /etc/apache/ssl.crt/server.crt -key
> /etc/apache/ssl.key/server.key
> Enter pass phrase for /etc/apache/ssl.key/server.key:
> Using default temp DH parameters
> Using default temp ECDH parameters
> ACCEPT
>
> >    4. Use a browser on the server to see if you can connect to the
> server
> >    locally.
>
> I can now (couldn't before I did the SSL certificate above). But I can't
> get at it from the internet.
> If I connect via clear http, I get an error telling me to use https
> (though lynx apparently doesn't renegotiate).
>
> Could this be because I've put the SSL-related directives in the
> definition of NameVirtualHost * ? I figured that'd give me the broadest
> application of https, and I'm not exactly sure how htc sets up its own
> vhosts.
>
> >    5. Check the serverlogs and the errorlogs to see what's going on.
> IIRC
> >    there's some form of ssl log on many setups - you may be able to
> configure
> >    this somewhere also.
>
> I've been looking for the log, but can't find it. I've got the mod_ssl
> docs downloaded, though, for a perusal this evening...
>
> >
> > Then try the last four from another machine on the same subnet, and then
> on
> > other networks.
> >
>
> Unfortunately, this is a box in a datacenter in Belgium - outside of the
> box itself, I can only jump straight to the Big Wide World.
>
> --
> Avi Greenbury
> --
> Gllug mailing list  -  Gllug at gllug.org.uk
> http://lists.gllug.org.uk/mailman/listinfo/gllug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20080513/75c25c3a/attachment.html>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug