I'm trying to wget to my own box, and it can't be an internal address in the wget (so says another developer).
When I wget, I get this:
wget http://example.com
--2013-03-01 15:03:30-- http://example.com/
Resolving example.com... 172.20.0.224
Connecting to example.com|172.20.0.224|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://www.example.com/ [following]
--2013-03-01 15:03:30-- https://www.example.com/
Resolving www.example.com... 172.20.0.224
Connecting to www.example.com|172.20.0.224|:443... connected.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish SSL connection.
I believe it is because I do not have the certificate setup properly. Using openssl:
openssl s_client -connect example.com:443
CONNECTED(00000003)
15586:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:588:
While if I do the same command on another site, it shows the entire cert.
Perhaps the ssl cert was never setup in the conf file on Apache for that domain?
If so, what should I be specifying in the virtualhost? Is there any alternative other than specifying --no-check-certificate because I don't want to do that?
I had this problem when setting up a new EC2 instance. I had not added HTTPS to my security group, and so port 443 was not open.
This problem happened for me only in special cases, when I called website from some internet providers,
I've configured only ip v4 in VirtualHost configuration of apache, but some of router use ip v6, and when I added ip v6 to apache config the problem solved.
The problem I faced was in client server environment. The client was trying to connect over http port 80 but wanted the server proxy to redirect the request to some other port and data was https. So basically asking secure information over http. So server should have http port 80 as well as the port client is requesting, let's say urla:1111\subB.
The issue was server was hosting this on some other port e,g urla:2222\subB; so the client was trying to access over 1111 was receiving the error. Correcting the port number should fix this issue. In this case to port number 1111.
For me a DNS name of my server was added to /etc/hosts and it was mapped to 127.0.0.1 which resulted in
SL23_GET_SERVER_HELLO:unknown protocol
Removing mapping of my real DNS name to 127.0.0.1 resolved the problem.
There are a few possibilities:
For starters, to eliminate (3), what happens if you telnet to that port?
Assuming it's not (3), then depending on your needs you may be fine with ignoring these errors and just passing --no-certificate-check. You probably want to use a regular browser (which generally will bundle the root certs directly) and see if things are happy.
If you want to manually verify the cert, post more details from the openssl s_client output. Or use openssl x509 -text -in /path/to/cert to print it out to your terminal.
In my case I had not enabled the site 'default-ssl'. Only '000-default' was listed in the /etc/apache2/sites-enabled folder.
Enable SSL site on Ubuntu 14 LTS, Apache 2.4.7:
a2ensite default-ssl
service apache2 reload
Just a quick note (and possible cause).
You can have a perfectly correct VirtualHost setup with _default_:443 etc. in your Apache .conf file.
But... If there is even one .conf file enabled with incorrect settings that also listens to port 443, then it will bring the whole SSL system down.
Therefore, if you are sure your .conf file is correct, try disabling the other site .conf files in sites-enabled.
I meet this same question. The port 443 wasn't open in Centos.
Check the 443 port with the following command:
sudo lsof -i tcp:443
In the first line of /etc/httpd/conf.d/ssl.conf add this two lines:
LoadModule ssl_module modules/mod_ssl.so
Listen 443
Source: Stackoverflow.com