Re: RE: [users@httpd] https not working
> 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 '^]'.
>> 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
> 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
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