Again, I am grateful for all the help @LPJon, thank you.
The new server I am trying to run MeshCentral from is a managed CentOS server that I have SSH Root access to, but I cannot change from cPanel/WHM as that’s part of the build.
Here are the steps I took to get MeshCentral to install and be accessible for both Let’s Encrypt cert and for my remote clients via the Internet:
0 — Ensured the server had an unused dedicated public IP (we’ll call it: 65.75.85.95 for sanitized reference)
1 — I setup a new «mesh.server.com» (sanitized name placeholder) account in WHM using the available server IP of 65.75.85.95
2 — Tested that a placeholder http://mesh.server.com site was working, so the account was active on the 65.75.85.95 IP exposed to the Internet.
3 — Went under WHM / Apache Configuration / Reserved IP address Editor and checked off the 65.75.85.95 IP, then restarted Apache in order to stop Apache from listening on the 80 & 443 ports.
4 — Confirmed that the placeholder site was no longer responding, meaning Apache was no longer listening on the 65.75.85.95 IP, exactly as expected.
5 — Also went under WHM / IP Functions / Show/Edit Reserved IPs, and checked off the same 65.75.85.95 IP, so it is not allocated in the future to anything else by WHM / cPanel on this server.
6 — In the [/home/mesh] home folder of the account I created a [docker] directory, and in it made a new docker-compose.yml file.
7 — The docker path is now: /home/mesh/docker/
8 — The sanitized contents of the «docker-compose.yml» file (with the dedicated IP 65.75.85.95 specified) are:
version: '3'
services:
mongodb:
container_name: meshcentral_db
restart: always
image: mongo:latest
expose:
- 27017
volumes:
- '/opt/meshcentral/database:/data/db'
networks:
meshnet:
ipv4_address: 65.75.85.95
meshcentral:
restart: always
container_name: meshcentral
depends_on:
- 'mongodb'
image: typhonragewind/meshcentral:mongodb
ports:
- "443:443"
- "80:80"
networks:
meshnet:
ipv4_address: 65.75.85.95
environment:
- HOSTNAME=mesh.server.com #your hostname - SANITIZED!
- REVERSE_PROXY=false #set to your reverse proxy IP if you want to put meshcentral behind a reverse proxy
- REVERSE_PROXY_TLS_PORT=443
- IFRAME=false #set to true if you wish to enable iframe support
- ALLOW_NEW_ACCOUNTS=false #set to false if you want disable self-service creation of new accounts besides the first (admin)
- WEBRTC=true #set to true to enable WebRTC - per documentation it is not officially released with meshcentral, but is solid enough to work with. Use with caution
- NODE_ENV=production
volumes:
- ./meshcentral/data:/opt/meshcentral/meshcentral-data
- ./meshcentral/user_files:/opt/meshcentral/meshcentral-files
networks:
meshnet:
driver: bridge
ipam:
driver: default
config:
- subnet: "65.75.85.0/16"
9 — Ran the «docker system prune —all» command and Docker removed all the orphaned containers and images!
10 — Ran the «docker-compose —verbose up -d » command, this time with verbose switch, and got:
[root@host docker]# docker-compose --verbose up -d
compose.config.config.find: Using configuration files: ./docker-compose.yml
docker.utils.config.find_config_file: Trying paths: ['/root/.docker/config.json', '/root/.dockercfg']
docker.utils.config.find_config_file: No config file found
docker.utils.config.find_config_file: Trying paths: ['/root/.docker/config.json', '/root/.dockercfg']
docker.utils.config.find_config_file: No config file found
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/version HTTP/1.1" 200 847
compose.cli.command.get_client: docker-compose version 1.25.2, build 698e2846
docker-py version: 4.1.0
CPython version: 3.7.5
OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019
compose.cli.command.get_client: Docker base_url: http+docker://localhost
compose.cli.command.get_client: Docker version: Platform={'Name': 'Docker Engine - Community'}, Components=[{'Name': 'Engine', 'Version': '20.10.16', 'Details': {'ApiVersion': '1.41', 'Arch': 'amd64', 'BuildTime': '2022-05-12T09:18:08.000000000+00:00', 'Experimental': 'false', 'GitCommit': 'f756502', 'GoVersion': 'go1.17.10', 'KernelVersion': '3.10.0-1160.66.1.el7.x86_64', 'MinAPIVersion': '1.12', 'Os': 'linux'}}, {'Name': 'containerd', 'Version': '1.6.4', 'Details': {'GitCommit': '212e8b6fa2f44b9c21b2798135fc6fb7c53efc16'}}, {'Name': 'runc', 'Version': '1.1.1', 'Details': {'GitCommit': 'v1.1.1-0-g52de29d'}}, {'Name': 'docker-init', 'Version': '0.19.0', 'Details': {'GitCommit': 'de40ad0'}}], Version=20.10.16, ApiVersion=1.41, MinAPIVersion=1.12, GitCommit=f756502, GoVersion=go1.17.10, Os=linux, Arch=amd64, KernelVersion=3.10.0-1160.66.1.el7.x86_64, BuildTime=2022-05-12T09:18:08.000000000+00:00
compose.cli.verbose_proxy.proxy_callable: docker inspect_network <- ('docker_meshnet')
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/networks/docker_meshnet HTTP/1.1" 404 47
compose.cli.verbose_proxy.proxy_callable: docker info <- ()
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/info HTTP/1.1" 200 None
compose.cli.verbose_proxy.proxy_callable: docker info -> {'Architecture': 'x86_64',
'BridgeNfIp6tables': True,
'BridgeNfIptables': True,
'CPUSet': True,
'CPUShares': True,
'CgroupDriver': 'cgroupfs',
'CgroupVersion': '1',
'ContainerdCommit': {'Expected': '212e8b6fa2f44b9c21b2798135fc6fb7c53efc16',
'ID': '212e8b6fa2f44b9c21b2798135fc6fb7c53efc16'},
'Containers': 0,
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_network <- ('docker_meshnet')
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/networks/docker_meshnet HTTP/1.1" 404 47
compose.network.ensure: Creating network "docker_meshnet" with driver "bridge"
compose.cli.verbose_proxy.proxy_callable: docker create_network <- (name='docker_meshnet', driver='bridge', options=None, ipam={'Driver': 'default', 'Config': [{'Subnet': '65.75.85.0/16', 'IPRange': None, 'Gateway': None, 'AuxiliaryAddresses': None}]}, internal=None, enable_ipv6=None, labels={'com.docker.compose.project': 'docker', 'com.docker.compose.network': 'meshnet', 'com.docker.compose.version': '1.25.2'}, attachable=True, check_duplicate=True)
urllib3.connectionpool._make_request: http://localhost:None "POST /v1.25/networks/create HTTP/1.1" 201 87
compose.cli.verbose_proxy.proxy_callable: docker create_network -> {'Id': 'd3e869a29f0ea0cae3eecb584ff445dc016279ebac27fd74ef93ab21f614ab47',
'Warning': ''}
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=False, filters={'label': ['com.docker.compose.project=docker', 'com.docker.compose.oneoff=False']})
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Ddocker%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D HTTP/1.1" 200 3
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=False, filters={'label': ['com.docker.compose.project=docker', 'com.docker.compose.oneoff=False']})
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Ddocker%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D HTTP/1.1" 200 3
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={'label': ['com.docker.compose.project=docker', 'com.docker.compose.oneoff=False']})
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/containers/json?limit=-1&all=1&size=0&trunc_cmd=0&filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Ddocker%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D HTTP/1.1" 200 3
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={'label': ['com.docker.compose.project=docker', 'com.docker.compose.oneoff=False']})
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/containers/json?limit=-1&all=1&size=0&trunc_cmd=0&filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Ddocker%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D HTTP/1.1" 200 3
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={'label': ['com.docker.compose.project=docker', 'com.docker.compose.service=mongodb', 'com.docker.compose.oneoff=False']})
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/containers/json?limit=-1&all=1&size=0&trunc_cmd=0&filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Ddocker%22%2C+%22com.docker.compose.service%3Dmongodb%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D HTTP/1.1" 200 3
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={'label': ['com.docker.compose.project=docker', 'com.docker.compose.service=mongodb', 'com.docker.compose.oneoff=False']})
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/containers/json?limit=-1&all=1&size=0&trunc_cmd=0&filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Ddocker%22%2C+%22com.docker.compose.service%3Dmongodb%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D HTTP/1.1" 200 3
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={'label': ['com.docker.compose.project=docker', 'com.docker.compose.service=meshcentral', 'com.docker.compose.oneoff=False']})
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/containers/json?limit=-1&all=1&size=0&trunc_cmd=0&filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Ddocker%22%2C+%22com.docker.compose.service%3Dmeshcentral%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D HTTP/1.1" 200 3
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={'label': ['com.docker.compose.project=docker', 'com.docker.compose.service=meshcentral', 'com.docker.compose.oneoff=False']})
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/containers/json?limit=-1&all=1&size=0&trunc_cmd=0&filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Ddocker%22%2C+%22com.docker.compose.service%3Dmeshcentral%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D HTTP/1.1" 200 3
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('mongo:latest')
urllib3.connectionpool._make_request: http://localhost:None "GET /v1.25/images/mongo:latest/json HTTP/1.1" 404 71
compose.service.pull: Pulling mongodb (mongo:latest)...
compose.cli.verbose_proxy.proxy_callable: docker pull <- ('mongo', tag='latest', stream=True, platform=None)
docker.auth.get_config_header: Looking for auth config
docker.auth.get_config_header: No auth config in memory - loading from filesystem
docker.utils.config.find_config_file: Trying paths: ['/root/.docker/config.json', '/root/.dockercfg']
docker.utils.config.find_config_file: No config file found
docker.auth.resolve_authconfig: Looking for auth entry for 'docker.io'
docker.auth.resolve_authconfig: No entry found
docker.auth.get_config_header: No auth config found
urllib3.connectionpool._make_request: http://localhost:None "POST /v1.25/images/create?tag=latest&fromImage=mongo HTTP/1.1" 500 111
ERROR: compose.cli.errors.log_api_error: Get "https://registry-1.docker.io/v2/": dial tcp 3.228.155.36:443: connect: connection refused
[root@host docker]#
I believe all is configured OK but somehow unable to access «https://registry-1.docker.io/v2/» which makes no sense…
Anything from the verbose log help? Where else should I look or what can I try?
Thank you.
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?
JoeG
7,04110 gold badges58 silver badges103 bronze badges
asked Mar 1, 2013 at 21:11
meder omuralievmeder omuraliev
182k70 gold badges386 silver badges429 bronze badges
1
SSL23_GET_SERVER_HELLO:unknown protocol
This error happens when OpenSSL receives something other than a ServerHello in a protocol version it understands from the server. It can happen if the server answers with a plain (unencrypted) HTTP. It can also happen if the server only supports e.g. TLS 1.2 and the client does not understand that protocol version. Normally, servers are backwards compatible to at least SSL 3.0 / TLS 1.0, but maybe this specific server isn’t (by implementation or configuration).
It is unclear whether you attempted to pass --no-check-certificate or not. I would be rather surprised if that would work.
A simple test is to use wget (or a browser) to request http://example.com:443 (note the http://, not https://); if it works, SSL is not enabled on port 443. To further debug this, use openssl s_client with the -debug option, which right before the error message dumps the first few bytes of the server response which OpenSSL was unable to parse. This may help to identify the problem, especially if the server does not answer with a ServerHello message. To see what exactly OpenSSL is expecting, check the source: look for SSL_R_UNKNOWN_PROTOCOL in ssl/s23_clnt.c.
In any case, looking at the apache error log may provide some insight too.
Sam
11.7k9 gold badges48 silver badges68 bronze badges
answered Mar 1, 2013 at 22:50
3
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
answered May 2, 2015 at 1:03
1
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.
answered Dec 2, 2015 at 9:04
Nostalg.ioNostalg.io
3,6341 gold badge27 silver badges31 bronze badges
2
There are a few possibilities:
- Your workstation doesn’t have the root CA cert used to sign your server’s cert. How exactly you fix that depends on what OS you’re running and what release, etc. (I suspect this is not related)
- Your cert isn’t installed properly. If your SSL cert requires an intermediate cert to be presented and you didn’t set that up, you can get these warnings.
- Are you sure you’ve enabled SSL on port 443?
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.
jww
95k88 gold badges397 silver badges861 bronze badges
answered Mar 1, 2013 at 21:22
Dave S.Dave S.
6,24930 silver badges33 bronze badges
2
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.
answered Nov 9, 2015 at 20:35
Steve EllisSteve Ellis
4945 silver badges13 bronze badges
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.
answered Mar 13, 2018 at 10:26
Kirill OficerovKirill Oficerov
2,0522 gold badges15 silver badges11 bronze badges
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
answered Mar 31, 2017 at 9:47
GeekHadesGeekHades
3,0303 gold badges18 silver badges15 bronze badges
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.
answered May 31, 2019 at 16:18
masoud2011masoud2011
8559 silver badges8 bronze badges
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:1111subB.
The issue was server was hosting this on some other port e,g urla:2222subB; 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.
answered Dec 23, 2013 at 9:32
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?
JoeG
7,04110 gold badges58 silver badges103 bronze badges
asked Mar 1, 2013 at 21:11
meder omuralievmeder omuraliev
182k70 gold badges386 silver badges429 bronze badges
1
SSL23_GET_SERVER_HELLO:unknown protocol
This error happens when OpenSSL receives something other than a ServerHello in a protocol version it understands from the server. It can happen if the server answers with a plain (unencrypted) HTTP. It can also happen if the server only supports e.g. TLS 1.2 and the client does not understand that protocol version. Normally, servers are backwards compatible to at least SSL 3.0 / TLS 1.0, but maybe this specific server isn’t (by implementation or configuration).
It is unclear whether you attempted to pass --no-check-certificate or not. I would be rather surprised if that would work.
A simple test is to use wget (or a browser) to request http://example.com:443 (note the http://, not https://); if it works, SSL is not enabled on port 443. To further debug this, use openssl s_client with the -debug option, which right before the error message dumps the first few bytes of the server response which OpenSSL was unable to parse. This may help to identify the problem, especially if the server does not answer with a ServerHello message. To see what exactly OpenSSL is expecting, check the source: look for SSL_R_UNKNOWN_PROTOCOL in ssl/s23_clnt.c.
In any case, looking at the apache error log may provide some insight too.
Sam
11.7k9 gold badges48 silver badges68 bronze badges
answered Mar 1, 2013 at 22:50
3
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
answered May 2, 2015 at 1:03
1
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.
answered Dec 2, 2015 at 9:04
Nostalg.ioNostalg.io
3,6341 gold badge27 silver badges31 bronze badges
2
There are a few possibilities:
- Your workstation doesn’t have the root CA cert used to sign your server’s cert. How exactly you fix that depends on what OS you’re running and what release, etc. (I suspect this is not related)
- Your cert isn’t installed properly. If your SSL cert requires an intermediate cert to be presented and you didn’t set that up, you can get these warnings.
- Are you sure you’ve enabled SSL on port 443?
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.
jww
95k88 gold badges397 silver badges861 bronze badges
answered Mar 1, 2013 at 21:22
Dave S.Dave S.
6,24930 silver badges33 bronze badges
2
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.
answered Nov 9, 2015 at 20:35
Steve EllisSteve Ellis
4945 silver badges13 bronze badges
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.
answered Mar 13, 2018 at 10:26
Kirill OficerovKirill Oficerov
2,0522 gold badges15 silver badges11 bronze badges
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
answered Mar 31, 2017 at 9:47
GeekHadesGeekHades
3,0303 gold badges18 silver badges15 bronze badges
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.
answered May 31, 2019 at 16:18
masoud2011masoud2011
8559 silver badges8 bronze badges
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:1111subB.
The issue was server was hosting this on some other port e,g urla:2222subB; 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.
answered Dec 23, 2013 at 9:32
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?
JoeG
7,04110 gold badges58 silver badges103 bronze badges
asked Mar 1, 2013 at 21:11
meder omuralievmeder omuraliev
182k70 gold badges386 silver badges429 bronze badges
1
SSL23_GET_SERVER_HELLO:unknown protocol
This error happens when OpenSSL receives something other than a ServerHello in a protocol version it understands from the server. It can happen if the server answers with a plain (unencrypted) HTTP. It can also happen if the server only supports e.g. TLS 1.2 and the client does not understand that protocol version. Normally, servers are backwards compatible to at least SSL 3.0 / TLS 1.0, but maybe this specific server isn’t (by implementation or configuration).
It is unclear whether you attempted to pass --no-check-certificate or not. I would be rather surprised if that would work.
A simple test is to use wget (or a browser) to request http://example.com:443 (note the http://, not https://); if it works, SSL is not enabled on port 443. To further debug this, use openssl s_client with the -debug option, which right before the error message dumps the first few bytes of the server response which OpenSSL was unable to parse. This may help to identify the problem, especially if the server does not answer with a ServerHello message. To see what exactly OpenSSL is expecting, check the source: look for SSL_R_UNKNOWN_PROTOCOL in ssl/s23_clnt.c.
In any case, looking at the apache error log may provide some insight too.
Sam
11.7k9 gold badges48 silver badges68 bronze badges
answered Mar 1, 2013 at 22:50
3
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
answered May 2, 2015 at 1:03
1
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.
answered Dec 2, 2015 at 9:04
Nostalg.ioNostalg.io
3,6341 gold badge27 silver badges31 bronze badges
2
There are a few possibilities:
- Your workstation doesn’t have the root CA cert used to sign your server’s cert. How exactly you fix that depends on what OS you’re running and what release, etc. (I suspect this is not related)
- Your cert isn’t installed properly. If your SSL cert requires an intermediate cert to be presented and you didn’t set that up, you can get these warnings.
- Are you sure you’ve enabled SSL on port 443?
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.
jww
95k88 gold badges397 silver badges861 bronze badges
answered Mar 1, 2013 at 21:22
Dave S.Dave S.
6,24930 silver badges33 bronze badges
2
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.
answered Nov 9, 2015 at 20:35
Steve EllisSteve Ellis
4945 silver badges13 bronze badges
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.
answered Mar 13, 2018 at 10:26
Kirill OficerovKirill Oficerov
2,0522 gold badges15 silver badges11 bronze badges
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
answered Mar 31, 2017 at 9:47
GeekHadesGeekHades
3,0303 gold badges18 silver badges15 bronze badges
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.
answered May 31, 2019 at 16:18
masoud2011masoud2011
8559 silver badges8 bronze badges
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:1111subB.
The issue was server was hosting this on some other port e,g urla:2222subB; 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.
answered Dec 23, 2013 at 9:32
We have a script that downloads mod security from github that has recently started failing. The servers run CentOS 6 but RHEL 6 probably has the same issue. The output is:
# wget https://github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz
--2014-07-22 18:49:46-- https://github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz
Resolving github.com... 192.30.252.129
Connecting to github.com|192.30.252.129|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://cloud.github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz [following]
--2014-07-22 18:49:47-- https://cloud.github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz
Resolving cloud.github.com... 54.230.99.219, 205.251.219.190, 54.230.97.212, ...
Connecting to cloud.github.com|54.230.99.219|:443... connected.
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Unable to establish SSL connection.
Any ideas on how to fix or work around this?
asked Jul 22, 2014 at 17:02
4
You can use the curl command to download it:
curl -LO https://github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz
HalosGhost
4,64410 gold badges32 silver badges40 bronze badges
answered Aug 22, 2014 at 12:35
2
Server side has disabled the SSLv3 encryption handshake, because of SSLv3 severe security issues.
Moreover, your wget client is an outdated version and still use as default this SSLv3 encryption. You have 2 options:
- use —secure-protocol=TLSv1 flag in front of wget.
wget --secure-protocol=TLSv1 - install an updated version of wget that use as default TLSv1 protocol
answered Jun 2, 2015 at 15:07
You should check your wget version.
I had the same problem with older versions of wget (< 1.15).
Anthon
77k42 gold badges159 silver badges217 bronze badges
answered Jan 16, 2015 at 13:35
DanDan
611 silver badge1 bronze badge
1
If I’m not mistaken you mean this repo. Try to get URL form Releases.
This case work for me:
$ wget https://github.com/SpiderLabs/ModSecurity/archive/v2.8.0.tar.gz
P.S. I also have the same error message when try to run your case;
$ wget https://github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz
kenorb
19.4k14 gold badges135 silver badges158 bronze badges
answered Jul 22, 2014 at 22:19
Anton DozortsevAnton Dozortsev
2241 gold badge5 silver badges14 bronze badges
2
As for workaround, if you trust the host try specifying --no-check-certificate or add:
check_certificate = off
into your ~/.wgetrc (not recommended).
In some rare cases, it’s caused by your system time which could be out-of-sync therefore invalidating the certificates which was working before.
answered Feb 2, 2016 at 11:36
kenorbkenorb
19.4k14 gold badges135 silver badges158 bronze badges
Try this:
update-crypto-policies --set LEGACY
answered Apr 24, 2020 at 7:37
2
Запись от Airencarme размещена 13.03.2021 в 11:02
Сейчас пытался выгрузить каталог страниц с одного сайта при помощи утилиты «wget», и у меня возникла ошибка, которая, как я понял, связана с протоколом ssl. Я пробовал прописывать для параметра «—secure-protocol» значения «auto», «SSLv2», «SSLv3», «TLSv1», но установить соединение по данным протоколам всё равно не вышло.
Буду признателен, если кто-нибудь подскажет, как подправить запрос, или укажет, в какую сторону копать, (с подобной ошибкой встречаюсь всё чаще в последнее время).
Код ошибки при параметрах «—secure-protocol» — «SSLv3»
Код:
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc syswgetrc = C:Program Files (x86)GnuWin32/etc/wgetrc --2021-03-13 10:29:45-- https://prostokosaka.gitbook.io/bubble/ Распознаётся prostokosaka.gitbook.io... 104.18.1.145, 104.18.0.145 Устанавливается соединение с prostokosaka.gitbook.io|104.18.1.145|:443... соединение установлено. [U]OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure Невозможно установить соединение SSL.[/U]
Код ошибки при параметрах «—secure-protocol» — «auto», «SSLv2»
Код:
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc syswgetrc = C:Program Files (x86)GnuWin32/etc/wgetrc --2021-03-13 10:27:27-- https://prostokosaka.gitbook.io/bubble/ Распознаётся prostokosaka.gitbook.io... 104.18.0.145, 104.18.1.145 Устанавливается соединение с prostokosaka.gitbook.io|104.18.0.145|:443... соединение установлено. Невозможно установить соединение SSL.
Код ошибки при параметре «—secure-protocol» — «TLSv1»
Код:
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc syswgetrc = C:Program Files (x86)GnuWin32/etc/wgetrc --2021-03-13 10:57:09-- https://prostokosaka.gitbook.io/bubble/ Распознаётся prostokosaka.gitbook.io... 104.18.0.145, 104.18.1.145 Устанавливается соединение с prostokosaka.gitbook.io|104.18.0.145|:443... соединение установлено. OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure Невозможно установить соединение SSL.
Код запроса моего запроса:
Код:
wget -P C:SITES -r -l 3 -k -p https://prostokosaka.gitbook.io/bubble/ --no-check-certificate --secure-protocol=TLSv1
Всего комментариев