Re: RE: [users@httpd] https not working
> Date: Sunday, June 24, 2018 14:22:10 +0000
> From: Richard <lists-apache@xxxxxxxxxxxxxxxxxxxxx>
>> 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
> 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
A clarification, the last part of this line:
> If you need ipv4 too you'll need to configure things
> appropriately -- that's a host networking, not
> apache/httpd, issue.
is imprecise. See:
for more detail on ipv4/ipv6 bindings.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx