> Date: Saturday, June 23, 2018 17:09:41 +0000 > From: Mahmood Naderan <nt_mahmood@xxxxxxxxx.INVALID> > >> Try "openssl s_client -debug -connect host:port" to see if your >> machine can contact the server at all. > Should I run that on my laptop (the remote machine) or the server? > > >> You should try to telnet to port 443 from a) the localhost > > The output seems to be fine > mahmood@ce:~$ telnet localhost 443 > Trying ::1... > Connected to localhost. > Escape character is '^]'. > ^] > telnet> > >> Note, from your output it looks like you only have this (only) >> configured for ipv6, which constrains what is and isn't going to >> work. You're going to need to understand whether the telnet test >> above is being done from ipv4 or v6 in order to interpret the >> results. > > Where do you mean? I have no problem with removing ipv6. > > What I have done already is to test one of the websites (and not a > subdomain) with https. I mean if you consider the main url as > http://myuni.com then http://myuni.com/shb works fine. What I have > done is that I have created an entry in default-ssl.conf for > /var/www/html/shb. Therefore, I want to test https://myuni.com/shb > Does that matter? > To get this to work: > Therefore, I want to test https://myuni.com/shb > Does that matter? you need to have https/port 443 configured correctly and open (including through firewalls) to whatever networks you want to give it access from (localhost, internal, external). Your telnet test shows you successfully connecting -- via ipv6 (Trying ::1...) -- to port 443 on the local machine. You need to continue testing the "b" and "c" options from my earlier message: > b) a machine on the same network, c) a machine on a different > (ideally external) network if you want clients to be able to connect from "b" internal networks and/or "c" external networks. As noted earlier, your netstat output is only showing ipv6 for port 443. That may be what you want, but generally isn't sufficient for full external client access. If you need ipv4 too you'll need to configure things appropriately -- that's a host networking, not apache/httpd, issue. By the way, the "s_client" test that was suggested is useful, but I think is harder to get the different types of server side responses from than a simple telnet. If the port is open but it's potentially a security protocol/certificate issue, then s_client is the right tool. Trying to debug your current issue with a browser is almost useless. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|