Ive downloaded the Enhanced Tight VNC Viewer (http://www.karlrunge.com/x11vnc/ssvnc.html) and followed instructions to connect the viewer on my local machine(running Win 7) to another machine running the x11vnc server.
The remote machine is running ubuntu 16.04 and has x11vnc server installed (v0.9.13). I am able to connect to it without the ssl option but it fails when I use SSL.
Steps followed
This dialog helps you to create a simple Self-Signed SSL certificate.
On Unix the openssl(1) program must be installed and in $PATH.
On Windows, a copy of the openssl program is provided for convenience.
The resulting certificate files can be used for either:
1) authenticating yourself (VNC Viewer) to a VNC Server
or 2) your verifying the identity of a remote VNC Server.
In either case you will need to safely copy one of the generated key or
certificate files to the remote VNC Server and have the VNC Server use
it. Or you could send it to the system administrator of the VNC Server.
For the purpose of description, assume that the filename selected in the
"Save to file" entry is "vnccert.pem". That file will be generated
by this process and so will the "vnccert.crt" file. "vnccert.pem"
contains both the Private Key and the Public Certificate. "vnccert.crt"
only contains the Public Certificate.
For case 1) you would copy "vnccert.crt" to the VNC Server side and
instruct the server to use it. For x11vnc it would be for example:
x11vnc -sslverify /path/to/vnccert.crt -ssl SAVE ...
(it is also possible to handle many client certs at once in a directory,
see the -sslverify documentation). Then you would use "vnccert.pem"
as the MyCert entry in the SSL Certificates dialog.
For case 2) you would copy "vnccert.pem" to the VNC Server side and
instruct the server to use it. For x11vnc it would be for example:
x11vnc -ssl /path/to/vnccert.pem
Then you would use "vnccert.crt" as the as the ServerCert entry in the
"SSL Certificates" dialog.
Creating the Certificate:
Choose a output filename (ending in .pem) in the "Save to file" entry.
Then fill in the identification information (Country, State or Province,
etc).
The click on "Create" to generate the certificate files.
Encrypting the Private Key: It is a very good idea to encrypt the
Private Key that goes in the "vnccert.pem". The downside is that
whenever that key is used (e.g. starting up x11vnc using it) then
the passphrase will need to be created. If you do not encrypt it and
somebody steals a copy of the "vnccert.pem" file then they can pretend
to be you.
After you have created the certificate files, you must copy and import
either "vnccert.pem" or "vnccert.pem" to the remote VNC Server and
also select the other file in the "SSL Certificates" dialog.
See the description above.
For more information see:
http://www.karlrunge.com/x11vnc/ssl.html
http://www.karlrunge.com/x11vnc/faq.html#faq-ssl-tunnel-int
The first one describes how to use x11vnc to create Certificate
Authority (CA) certificates in addition to Self-Signed ones.
Tip: if you choose the "Common Name" to be the internet hostname
(e.g. gateway.mydomain.com) that connections will be made to or
from that will avoid many dialogs when connecting mentioning that
the hostname does not match the Common Name.
So, I've followed steps for Option 1 i.e., to authenticate VNC Viewer to a VNC Server.
Started the server using the command
x11vnc -display :0 -sslverify ~/vnccert2.crt -ssl SAVE
Client Side:
Provided the path of the pem file generated in the client system to
the viewer (vnccert2.pem file) in MyCert field
Clicked Connect with option Use SSL selected
Saved the certificate received from the remote server into Accepted Certs dir
The logs at the server are as below
16/07/2018 16:28:34 SSL: accept_openssl(OPENSSL_VNC)
16/07/2018 16:28:34 SSL: spawning helper process to handle: 10.221.49.127:56668
16/07/2018 16:28:34 SSL: helper for peerport 56668 is pid 17094:
16/07/2018 16:28:34 connect_tcp: trying: 127.0.0.1 20000
16/07/2018 16:28:34 check_vnc_tls_mode: waited: 0.000008 / 1.40 input: SSL Handshake
16/07/2018 16:28:34 SSL: ssl_init[17094]: 12/12 initialization timeout: 20 secs.
16/07/2018 16:28:34 SSL: ssl_helper[17094]: SSL_accept() *FATAL: -1 SSL FAILED
16/07/2018 16:28:34 SSL: error:140890C7:SSL routines:ssl3_get_client_certificate:peer did not return a certificate
16/07/2018 16:28:34 SSL: ssl_helper[17094]: Proto: TLSv1
16/07/2018 16:28:34 SSL: ssl_helper[17094]: exit case 2 (ssl_init failed)
16/07/2018 16:28:34 SSL: accept_openssl: cookie from ssl_helper[17094] FAILED. 0
16/07/2018 16:28:39 SSL: accept_openssl(OPENSSL_VNC)
16/07/2018 16:28:39 SSL: spawning helper process to handle: 10.221.49.127:56670
16/07/2018 16:28:39 SSL: helper for peerport 56670 is pid 17095:
16/07/2018 16:28:39 connect_tcp: trying: 127.0.0.1 20000
16/07/2018 16:28:39 check_vnc_tls_mode: waited: 0.000013 / 1.40 input: SSL Handshake
16/07/2018 16:28:39 SSL: ssl_init[17095]: 12/12 initialization timeout: 20 secs.
16/07/2018 16:28:39 SSL: ssl_helper[17095]: SSL_accept() *FATAL: -1 SSL FAILED
16/07/2018 16:28:39 SSL: error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number
16/07/2018 16:28:39 SSL: ssl_helper[17095]: Proto: nosession
16/07/2018 16:28:39 SSL: ssl_helper[17095]: exit case 2 (ssl_init failed)
16/07/2018 16:28:39 SSL: accept_openssl: cookie from ssl_helper[17095] FAILED. 0
I'm not sure where I am going wrong as the certificate at the client side exists but still the server throws the message
"ssl3_get_client_certificate:peer did not return a certificate" also after this it throws another error "ssl3_get_client_hello:wrong version number"
Have you checked the ports used on both attempts?
SSL connections may require a different port.
Also, I've found this article on the ServerFault site. The accepted response stands:
The stunnel server has options = NO_SSLv3, but the client is trying to
connect using SSLv3. You need to upgrade the client to support a newer
version of SSL or you need to change the stunnel configuration to
accept SSLv3.
Related
I'm using 'OpenConnect version v8.05' on Red Hat Enterprise Linux 8.1 (Ootpa) in order to connect to a server.
The server only accepts SSLv3, TLSv1.0 ciphers and I don't have access to the server for security update/upgrade.
When I try to connect:
[root#RHEL8 ~]# openconnect --authenticate XXX.XXX.XXX.XXX:443 -status -msg -debug
MTU 0 too small
POST https://XXX.XXX.XXX.XXX/
Connected to XXX.XXX.XXX.XXX:443
SSL negotiation with XXX.XXX.XXX.XXX
SSL connection failure: A packet with illegal or unsupported version was received.
Failed to open HTTPS connection to XXX.XXX.XXX.XXX
Failed to obtain WebVPN cookie
I have changed OpenSSL Min SSL Protocol by changing:
/etc/crypto-policies/back-ends/opensslcnf.config
MinProtocol = TLSv1.0
Now I'm able to handshake the server using 'openssl s_client -connect'. But the openconnect client is not yet able to connect to the server.
How can I force it to use TLS 1.0?
I have filed an issue on their community issue tracker and got useful info.
It is possible to allow this insecure connection with any version newer than 8.05(currently not available on rpm repositories) as mentioned by the maintainer:
$ ./openconnect --gnutls-priority "NONE:+VERS-SSL3.0:+VERS-TLS1.0:%NO_EXTENSIONS:%SSL3_RECORD_VERSION:+3DES-CBC:+ARCFOUR-128:+MD5:+SHA1:+COMP-ALL:+KX-ALL" ***
I try to enable ssl for Saltstack master and minion by following https://docs.saltstack.com/en/latest/ref/configuration/master.html#ssl But I am not sure how to verify it is using SSL.
I added this in master configuration:
ssl:
keyfile: /etc/salt/ssl/master/key.pem
certfile: /etc/salt/ssl/master/cert.pem
ssl_version: PROTOCOL_TLSv1_2
I added similar settings in minion. However, when I use openssl to test the port:
openssl s_client -connect <master ip>:4505 -debug and I get SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol. It seems the SSL is not enabled at all. How to verify if the SSL is enabled? The master and minion communication seems fine. I just to need to verify it is using SSL. I am on Centos 7 with python 2.7. Do I need to install any additional packages?
You also need to add
transport: tcp
Then you will at least get some SSL related error in /var/log/salt/master or /var/log/salt/minion
You can use tcpdump to capture some traffic and analyze it in wireshark to verify if the connection is ssl encrypted.
I've recently created a PKCS keystore using LetsEncrypt and I configured my production profile for JHipster to run Tomcat on 8443 using the new keystore. I can get the application to run if I call "ciwiseaccounting.com:8443" but when the page arrives Chrome shows the "!" meaning the page is not secure. This is odd because I didn't see the SSL challenge occur. If I call "https://ciwiseaccounting.com:8443" this does not work. Does anyone know what I'm doing wrong? IPTables is wide open for now and I can nmap the 8443 listener. Here's my server config snippet:
server:
port: 8443
server.ssl.key-store:
/etc/letsencrypt/live/ciwiseaccounting.com/keystore.p12
server.ssl.key-store-password: password
server.ssl.keyStoreType: PKCS12
server.ssl.keyAlias: tomcat
You are using the server key twice in your configuration (line 1, then again on lines 3-6). This means the properties aren't parsed into the correct variables, resulting in regular http instead of https.
Try with the below config:
server:
port: 8443
ssl:
key-store: /etc/letsencrypt/live/ciwiseaccounting.com/keystore.p12
key-store-password: password
keyStoreType: PKCS12
keyAlias: tomcat
I use squid 3.5 with its sslbump feature for https traffic filtering. I generated my private key and cert files with openssl. However,the browser received the warning message when i open https websites that the certificate was issued by an unknown authority. I created ssl certificates with comodo but i still got the same warning message.
Is there a way to remove this warning?
# Squid normally listens to port 3128
http_port 3128 ssl-bump cert=/var/tmp/example.com.cert key=/var/tmp/example.com.private
# Squid listen Port
cert=/var/tmp/example.com.cert
# SSL Bump Config
always_direct allow all
ssl_bump server-first all
url_rewrite_program /usr/bin/sh /var/tmp/middle_squid_wrapper.sh start -C /var/tmp/middle_squid_config.rb
# required to fix HTTPS sites (if SslBump is enabled)
acl fix_ssl_rewrite method GET
acl fix_ssl_rewrite method POST
url_rewrite_access allow fix_ssl_rewrite
url_rewrite_access deny all
You don't say what client OS you are using, but it sounds very much like you didn't import your squid certificate to the correct certificate store on the client.
When you install the certificate on a Windows client it should be imported into the Trusted Root Certificate Authorities'->'certificates folder.
The client should then trust the certificate.
I am setting up Chef workstation by configuring knife.rb using "knife configure -i" configure command. After PROPERLY answering all question, I get the following error :
ERROR: SSL Validation failure connecting to host: 172.xx.x.xx - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
ERROR: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
My goal is to disable this SSL certificate verification forever and use knife utility to bootstrap my all nodes.
I had the same issue running chef-client after upgrading to the version 12.xx. Steps to solve:
Pull crt from server. Run on node:
knife ssl fetch -s https://yourchefserver01.com:443
Note: If fetch doesnt work copy from yourchefserver01.com:/var/opt/chef-server/nginx/ca/yourchefserver01.com.crt to client:/root/.chef/trusted_certs/yourchefserver01.com.crt
Verify it pulled:
knife ssl check -s https://yourchefserver01.com:443
export SSL_CERT_FILE="/root/.chef/trusted_certs/yourchefserver01.com.crt"
Run chef-client
Your problem is the validation of the chef server certificate.
Install a proper certificate on the chef server
or add your chef server certificate (located in /etc/chef-server/hostname.crt) to your workstation cacert.pem (located by default in <install path>/opscode/chef/embedded/ssl/certs).
With chef 12 you'll have to ditribute it too on your nodes to validate the chef API server or you'll have a warning at the start of each chef-client run about it.
Issue seems to be concerned with the .pem validator. your validation are misconfigured. Try create new validation key from chef server and place it under the node.
If you are running Chef Server on-premise, it will easier in the long run to install a third-party SSL cert, e.g. Verisign, on the Chef Server (or load balancer). chef-client and knife come with OpenSSL which will trust a valid third-party cert automatically with no configuation required on each node.
Please don't turn off SSL cert validation. SSL validation is additional protection that the server you are trusting with root access to your Chef nodes is the real Chef server, not a man-in-the-middle attack.