[libvirt] libvirt tls vnc

Hi, is there a comprehensive howto/tutorial you can recommend me on how to set up libvirt with vnc over tls properly? What I'm trying to do is to use vnc for production use outside my local network and therefore I'd like to secure the vnc sessions. I already made some attempts with ssvnc and Ultr@VNC (both windows clients) but these attemps all failed. I can't get the vnc server (launched by virt-install / kvm) to be displayed via tls. It all runs perfectly without tls. Thanx for any hints! Michael

On Thu, Feb 26, 2009 at 11:47:15AM +0100, Michael Kress wrote:
Hi, is there a comprehensive howto/tutorial you can recommend me on how to set up libvirt with vnc over tls properly? What I'm trying to do is to use vnc for production use outside my local network and therefore I'd like to secure the vnc sessions. I already made some attempts with ssvnc and Ultr@VNC (both windows clients) but these attemps all failed. I can't get the vnc server (launched by virt-install / kvm) to be displayed via tls. It all runs perfectly without tls.
There are some notes here http://virt-manager.org/page/RemoteTLS For QEMU driver you need to setup /etc/libvirt/qemu.conf suitably and then restart libvirtd. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Daniel P. Berrange wrote:
I already made some attempts with ssvnc and Ultr@VNC (both windows clients) but these attemps all failed. I can't get the vnc server (launched by virt-install / kvm) to be displayed via tls. It all runs perfectly without tls.
There are some notes here
Thanks Daniel for the quick reply, I already did what the page says for "KVM VNC Server". So here's the long version: I have set these files up: -----8<-----8<-----SNIP-----8<-----8<----- |x:/etc/pki/libvirt-vnc# ls -l insgesamt 36 -rw-r--r-- 1 root root 1111 26. Feb 01:57 ca-cert.pem -rw-r--r-- 1 root root 53 26. Feb 01:56 ca.info -rw------- 1 root root 1679 26. Feb 01:56 ca-key.pem -rw-r--r-- 1 root root 1281 26. Feb 01:59 client-cert.pem -rw-r--r-- 1 root root 156 26. Feb 01:59 client.info -rw------- 1 root root 1675 26. Feb 01:58 client-key.pem -rw-r--r-- 1 root root 1216 26. Feb 01:58 server-cert.pem -rw-r--r-- 1 root root 107 26. Feb 01:57 server.info -rw------- 1 root root 1675 26. Feb 01:57 server-key.pem| -----8<-----8<-----SNIP-----8<-----8<----- Did that according to http://qemu-buch.de/d/Netzwerkoptionen/_Netzwerkdienste/_VNC In /etc/libvirt/qemu.conf I have these values: -----8<-----8<-----SNIP-----8<-----8<----- |vnc_listen = "127.0.0.1" vnc_tls = 1 vnc_tls_x509_cert_dir = "/etc/pki/libvirt-vnc" vnc_tls_x509_verify = 1| -----8<-----8<-----SNIP-----8<-----8<----- I have a working ssh tunnel from Vista/Putty/Port 5900 to debian5/openssh/Port5900. Working means, I verified it with vncserver (without tls) and with nc (netcat). On windows side I tried with ssvnc using these values: host: root@127.0.0.1:1 (I used root@ because he wanted a username) protocol: SSL (not SSH or SSL+SSH, because there is already a ssh tunnel) Under [Certs...] I have these settings: MyCert: client-cert.pem ServerCert: server-cert.pem CertsDir: leer CRL file: leer Now I click on [FetchCert] and get these results: -----8<-----8<-----SNIP-----8<-----8<----- An Error occurred in fetching root@127.0.0.1:1 CONNECTED(00000094) --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 139 bytes --- New, (NONE), Cipher is (NONE) Compression: NONE Expansion: NONE --- -----8<-----8<-----SNIP-----8<-----8<----- On sshd side I see that he logs "connected to 127.0.0.1 port 5900" when I run sshd with "-d -d", so the connection is being well done. netstat -nta tells me that the vnc server from libvirt/kvm listens to 127.0.0.1:5900 When I click to [Connect], the following message appears: -----8<-----8<-----SNIP-----8<-----8<----- stunnel 4.26 on Win32 (not configured) - Stunnel server is down due to an error. You need to exit and correct the problem. See OK to see the error log window. -----8<-----8<-----SNIP-----8<-----8<----- and then this log appears in a window: -----8<-----8<-----SNIP-----8<-----8<----- |2009.02.26 02:40:59 LOG7[9080:8196]: RAND_status claims sufficient entropy for the PRNG 2009.02.26 02:40:59 LOG7[9080:8196]: PRNG seeded successfully 2009.02.26 02:40:59 LOG7[9080:8196]: Configuration SSL options: 0x00000FFF 2009.02.26 02:40:59 LOG7[9080:8196]: SSL options set: 0x00000FFF 2009.02.26 02:40:59 LOG7[9080:8196]: Certificate: C:/00-test/keys/client-cert.pem 2009.02.26 02:40:59 LOG7[9080:8196]: Certificate loaded 2009.02.26 02:40:59 LOG7[9080:8196]: Key file: C:/00-test/keys/client-cert.pem 2009.02.26 02:40:59 LOG3[9080:8196]: error stack: 140B3009 : error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib 2009.02.26 02:40:59 LOG3[9080:8196]: SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM routines:PEM_read_bio:no start line 2009.02.26 02:40:59 LOG3[9080:8196]: Server is down| -----8<-----8<-----SNIP-----8<-----8<----- and that's it - nothing more happens. Have you got any hints for me? As soon as I'll get this running, I'll eventually write a howto on that, because it seems that there is none like that. Thanks in advance! Michael

On Thu, Feb 26, 2009 at 12:07:15PM +0100, Michael Kress wrote:
Daniel P. Berrange wrote:
I already made some attempts with ssvnc and Ultr@VNC (both windows clients) but these attemps all failed. I can't get the vnc server (launched by virt-install / kvm) to be displayed via tls. It all runs perfectly without tls.
There are some notes here
[snip]
I have a working ssh tunnel from Vista/Putty/Port 5900 to debian5/openssh/Port5900. Working means, I verified it with vncserver (without tls) and with nc (netcat).
On windows side I tried with ssvnc using these values:
What VNC client are you using on Windows ? Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Daniel P. Berrange wrote:
I have a working ssh tunnel from Vista/Putty/Port 5900 to
debian5/openssh/Port5900. Working means, I verified it with vncserver (without tls) and with nc (netcat).
On windows side I tried with ssvnc using these values:
What VNC client are you using on Windows ?
I have tried these: * http://www.karlrunge.com/x11vnc/ssvnc.html (effect as described) * http://www.uvnc.com/ with MSRC4Plugin.dsm, MSRC4Plugin_NoReg.dsm and MSRC4Plugin-122.dsm (doesn't work either) * realvnc free edition (says: "No matching security types") Regards Michael -- Michael Kress, kress@hal.saar.de http://www.michael-kress.de / http://kress.net P E N G U I N S A R E C O O L

On Thu, Feb 26, 2009 at 12:55:57PM +0100, Michael Kress wrote:
Daniel P. Berrange wrote:
I have a working ssh tunnel from Vista/Putty/Port 5900 to
debian5/openssh/Port5900. Working means, I verified it with vncserver (without tls) and with nc (netcat).
On windows side I tried with ssvnc using these values:
What VNC client are you using on Windows ?
I have tried these:
* http://www.karlrunge.com/x11vnc/ssvnc.html (effect as described)
To quote that page: "SSVNC also supports the VeNCrypt SSL/TLS extension to VNC (Unix and Mac OS X only.) " So you're out of luck with Windows
* http://www.uvnc.com/ with MSRC4Plugin.dsm, MSRC4Plugin_NoReg.dsm and MSRC4Plugin-122.dsm (doesn't work either) * realvnc free edition (says: "No matching security types")
AFAIK, neither of these support VeNCrypt We're working on getting virt-viewer available for Windows as part of the Fedora MinGW work, but not completed yet Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Daniel P. Berrange wrote:
* http://www.karlrunge.com/x11vnc/ssvnc.html (effect as described)
To quote that page:
"SSVNC also supports the VeNCrypt SSL/TLS extension to VNC (Unix and Mac OS X only.) "
So you're out of luck with Windows
Ok, this is no drawback - at least I know that I shouldn't invest further energy in Windows. Then I'll give a try on linux and mail the results later. Although, I tried the VeNCrypt Viewer v0.2.6 under windows (forgot to mention that) and had the following results / message boxes: VNC/Authentication [X509None]: certificate issuer unknown. VNC/Authentication [X509None]: certificate not trusted. VNC/Authentication [X509None]: hostname mismatch. VeNCrypt Viewer : Question: The connection closed unexpectedly. Do you wish to attempt to reconnect to 127.0.0.1:0?
We're working on getting virt-viewer available for Windows as part of the Fedora MinGW work, but not completed yet
Great - looking forward to that! :) Regards Michael -- Michael Kress, kress@hal.saar.de http://www.michael-kress.de / http://kress.net P E N G U I N S A R E C O O L

On Thu, Feb 26, 2009 at 01:29:09PM +0100, Michael Kress wrote:
Daniel P. Berrange wrote:
* http://www.karlrunge.com/x11vnc/ssvnc.html (effect as described)
To quote that page:
"SSVNC also supports the VeNCrypt SSL/TLS extension to VNC (Unix and Mac OS X only.) "
So you're out of luck with Windows
Ok, this is no drawback - at least I know that I shouldn't invest further energy in Windows. Then I'll give a try on linux and mail the results later.
Although, I tried the VeNCrypt Viewer v0.2.6 under windows (forgot to mention that) and had the following results / message boxes: VNC/Authentication [X509None]: certificate issuer unknown. VNC/Authentication [X509None]: certificate not trusted. VNC/Authentication [X509None]: hostname mismatch. VeNCrypt Viewer : Question: The connection closed unexpectedly. Do you wish to attempt to reconnect to 127.0.0.1:0?
This indicates a mismatch between the hostname you told it to connect to, and the hostname in the server certificate. If the host name in the server certificate is foo.example.com, you *must* tell the VNC client to connect to foo.example.com:0 and *not* localhost, or 127.0.0.1 or any other IP address it may have. Also sounds like the client may be missing the CA certificate, since it shouldn't say 'certificate issuer unknown' if you've pointed it to the CA cert file correctly. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Michael Kress napsal(a):
Daniel P. Berrange wrote:
* http://www.karlrunge.com/x11vnc/ssvnc.html (effect as described)
To quote that page:
"SSVNC also supports the VeNCrypt SSL/TLS extension to VNC (Unix and Mac OS X only.) "
So you're out of luck with Windows
Ok, this is no drawback - at least I know that I shouldn't invest further energy in Windows. Then I'll give a try on linux and mail the results later.
You can run stunnel on libvirt host and use SSVNC on Windows. Actually SSVNC does the same, runs the stunnel and starts the VNC viewer. It can even start UltraVNC. I know this is more like a workaround but it works. Radek

Michael Kress wrote:
Then I'll give a try on linux and mail the results later.
So I tried under Linux with ssvnc in the following scenario: ssvnc ---> (port 5900) ssh tunnel established from localhost via ssh ---> sshd on remote host --> (port 5900) libvirt/kvm/vnc The tunnel works and is built up with this command: ssh -i privkey.ppk -L 5900:127.0.0.1:5900 192.168.1.122 Whereas 192.168.1.122 is the machine running libvirt/kvm/vnc. =========================================================================== output of netstat -nta | grep 59 on the client side: tcp 0 0 127.0.0.1:5900 0.0.0.0:* LISTEN that means the ssh tunnel is ready on the client side on the server side, the vnc from libvirt is also ready ... netstat -nta | grep 59 tcp 0 0 127.0.0.1:5900 0.0.0.0:* LISTEN =========================================================================== Everything from now on _IS_ called 'localhost', i.e. there should be no reason for a CN/hostname mismatch (like in the other post). Output of the following command: ./ssvnc -cacert /home/kress/keys/cacert.pem -mycert /home/kress/keys/client-cert.pem -ssl localhost:0 =========================================================================== + ssvnc_cmd -mycert /home/kress/keys/client-cert.pem -verify /home/kress/keys/ca cert.pem localhost:0 -noraiseonbeep Using this stunnel configuration: foreground = yes pid = client = yes debug = 6 options = ALL cert = /home/kress/keys/client-cert.pem CAfile = /home/kress/keys/cacert.pem verify = 2 #[vnc_stunnel] #accept = localhost:5930 connect = localhost:5900 #stunnel-exec Running viewer: vncviewer -noraiseonbeep -encodings copyrect tight zrle zlib hextile exec=stunne l /tmp/ss_vncviewer12268.14574.F14634 exec-cmd: exec stunnel /tmp/ss_vncviewer12268.14574.F14634 2009.02.26 19:09:44 LOG7[14644:3086588128]: Snagged 64 random bytes from /root/.rnd 2009.02.26 19:09:44 LOG7[14644:3086588128]: Wrote 1024 new random bytes to /root/.rnd 2009.02.26 19:09:44 LOG7[14644:3086588128]: RAND_status claims sufficient entropy for the PRNG 2009.02.26 19:09:44 LOG7[14644:3086588128]: PRNG seeded successfully 2009.02.26 19:09:44 LOG7[14644:3086588128]: Configuration SSL options: 0x00000FFF 2009.02.26 19:09:44 LOG7[14644:3086588128]: SSL options set: 0x00000FFF 2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate loaded 2009.02.26 19:09:44 LOG7[14644:3086588128]: Key file: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG3[14644:3086588128]: error stack: 140B3009 : error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib 2009.02.26 19:09:44 LOG3[14644:3086588128]: SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM routines:PEM_read_bio:no start line vncviewer: VNC server closed connection ShmCleanup called VNC Viewer exiting. vncviewer command failed: 0 + set +xv Done. You Can X-out or Ctrl-C this Terminal if you like. Ctrl-\ to pause. sleep 5 =========================================================================== FYI, output of Click-on-button-[Fetch Cert]: =========================================================================== ==== SSL Certificate from localhost:0 ==== MD5 Fingerprint=8B:21:C7:64:D1:E0:DF:97:C3:20:7C:33:55:6E:75:77 depth=0 /O=my organization/CN=localhost verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /O=my organization/CN=localhost verify error:num=27:certificate not trusted verify return:1 depth=0 /O=my organization/CN=localhost verify error:num=21:unable to verify the first certificate verify return:1 CONNECTED(00000003) --- Certificate chain 0 s:/O=my organization/CN=localhost i:/CN=myserver --- Server certificate -----BEGIN CERTIFICATE----- MIIDLjCCAhigAwIBAgIESabNHzALBgkqhkiG9w0BAQUwEzERMA8GA1UEAxMIbXlz ZXJ2ZXIwHhcNMDkwMjI2MTcxMDU1WhcNMTAwMjI2MTcxMDU1WjAuMRgwFgYDVQQK Ew9teSBvcmdhbml6YXRpb24xEjAQBgNVBAMTCWxvY2FsaG9zdDCCAR8wCwYJKoZI hvcNAQEBA4IBDgAwggEJAoIBALxJ4SYt2HpAPBhYDAhtluv/qS+QmeUR0tQCyhsC yBDVip0cLJGtogKRFgZjdOxg8jnKtN3yy5+FLFvLhTJyULeFgr+HJpIDpyL1EvcD /Cj8I1i7nUoRJn8bDFAUD20/DOO6yIFElYnSngYAZK14ZabZnSoBdRZ30NQAohfC 77617WhwHIPy5ofInsmpW7UEZvtYs2AzNQZIumkoujcL0/4Df1PxfmRS21xQzg55 fdgX0sZ4G7heL4ML9AwGXuzdfByRn+vNosVoE87vZw9V+qkcYXB8IhjBi19PaPYF Rfpvg0SmLduqnlNO0xwDPgyLXT8Uj8G5mw/6axq/e1LrTs8CAwEAAaN2MHQwDAYD VR0TAQH/BAIwADATBgNVHSUEDDAKBggrBgEFBQcDATAPBgNVHQ8BAf8EBQMDB6AA MB0GA1UdDgQWBBT6T5yqvjHnut3nkB79COhJ33T0GjAfBgNVHSMEGDAWgBSt2uXI RM736ObtWlNLQz+iQj2sjTALBgkqhkiG9w0BAQUDggEBAF3tXwAz8nVaNAlKTJ3S dFunWyWRorfEdPbDMD1MfVbbmwUMnVOCp2jtyLJgcwwyhi1QWphGHKPivRdgZ1po mgBEvdmHU1/ednAWNIFNYuUAhD3el6CL6/wpoLfaWbhu8cMDIj4Jnd9IPKnu8qnD B2htS8Jt4k2iWXK6/jqZ89Zl8hr5YTGtN5WXTKRUar+JHFbE23oZPLxAcHrtwrkD yvYdxwzMScY+o/q1gDXbNydYDESN407uat6KaG6RhI+nJIfG/eJ0MaVFQulJG+SC Ey0GmL6TlzvO+dMwlt7fgwSuLEQhU89aCaUbC59q0d8TqD/7fN9RqlwQkT0cs5uI oXI= -----END CERTIFICATE----- subject=/O=my organization/CN=localhost issuer=/CN=myserver --- Acceptable client certificate CA names /CN=myserver --- SSL handshake has read 1547 bytes and written 352 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 29E946F1302AE32D2089152C93E3487D0E6ABD08B6DBCC9EEDBB5073EE070D3E Session-ID-ctx: Master-Key: F43DEE3FA449961F5DEC92A751D43BA4E87E53F1EFCC6F246648F022A6C23F3997EF9AB47B173E662A7BBFDD059B68E2 Key-Arg : None Krb5 Principal: None Start Time: 1235672414 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- DONE --- Certificate chain 0 s:/O=my organization/CN=localhost i:/CN=myserver --- Server certificate -----BEGIN CERTIFICATE----- MIIDLjCCAhigAwIBAgIESabNHzALBgkqhkiG9w0BAQUwEzERMA8GA1UEAxMIbXlz ZXJ2ZXIwHhcNMDkwMjI2MTcxMDU1WhcNMTAwMjI2MTcxMDU1WjAuMRgwFgYDVQQK Ew9teSBvcmdhbml6YXRpb24xEjAQBgNVBAMTCWxvY2FsaG9zdDCCAR8wCwYJKoZI hvcNAQEBA4IBDgAwggEJAoIBALxJ4SYt2HpAPBhYDAhtluv/qS+QmeUR0tQCyhsC yBDVip0cLJGtogKRFgZjdOxg8jnKtN3yy5+FLFvLhTJyULeFgr+HJpIDpyL1EvcD /Cj8I1i7nUoRJn8bDFAUD20/DOO6yIFElYnSngYAZK14ZabZnSoBdRZ30NQAohfC 77617WhwHIPy5ofInsmpW7UEZvtYs2AzNQZIumkoujcL0/4Df1PxfmRS21xQzg55 fdgX0sZ4G7heL4ML9AwGXuzdfByRn+vNosVoE87vZw9V+qkcYXB8IhjBi19PaPYF Rfpvg0SmLduqnlNO0xwDPgyLXT8Uj8G5mw/6axq/e1LrTs8CAwEAAaN2MHQwDAYD VR0TAQH/BAIwADATBgNVHSUEDDAKBggrBgEFBQcDATAPBgNVHQ8BAf8EBQMDB6AA MB0GA1UdDgQWBBT6T5yqvjHnut3nkB79COhJ33T0GjAfBgNVHSMEGDAWgBSt2uXI RM736ObtWlNLQz+iQj2sjTALBgkqhkiG9w0BAQUDggEBAF3tXwAz8nVaNAlKTJ3S dFunWyWRorfEdPbDMD1MfVbbmwUMnVOCp2jtyLJgcwwyhi1QWphGHKPivRdgZ1po mgBEvdmHU1/ednAWNIFNYuUAhD3el6CL6/wpoLfaWbhu8cMDIj4Jnd9IPKnu8qnD B2htS8Jt4k2iWXK6/jqZ89Zl8hr5YTGtN5WXTKRUar+JHFbE23oZPLxAcHrtwrkD yvYdxwzMScY+o/q1gDXbNydYDESN407uat6KaG6RhI+nJIfG/eJ0MaVFQulJG+SC Ey0GmL6TlzvO+dMwlt7fgwSuLEQhU89aCaUbC59q0d8TqD/7fN9RqlwQkT0cs5uI oXI= -----END CERTIFICATE----- subject=/O=my organization/CN=localhost issuer=/CN=myserver --- Acceptable client certificate CA names /CN=myserver --- SSL handshake has read 1547 bytes and written 389 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 29E946F1302AE32D2089152C93E3487D0E6ABD08B6DBCC9EEDBB5073EE070D3E Session-ID-ctx: Master-Key: F43DEE3FA449961F5DEC92A751D43BA4E87E53F1EFCC6F246648F022A6C23F3997EF9AB47B173E662A7BBFDD059B68E2 Key-Arg : None Krb5 Principal: None Start Time: 1235672414 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- ---------------------------------- Output of x509 -text -fingerprint: Certificate: Data: Version: 3 (0x2) Serial Number: 1235668255 (0x49a6cd1f) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=myserver Validity Not Before: Feb 26 17:10:55 2009 GMT Not After : Feb 26 17:10:55 2010 GMT Subject: O=my organization, CN=localhost Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:bc:49:e1:26:2d:d8:7a:40:3c:18:58:0c:08:6d: 96:eb:ff:a9:2f:90:99:e5:11:d2:d4:02:ca:1b:02: c8:10:d5:8a:9d:1c:2c:91:ad:a2:02:91:16:06:63: 74:ec:60:f2:39:ca:b4:dd:f2:cb:9f:85:2c:5b:cb: 85:32:72:50:b7:85:82:bf:87:26:92:03:a7:22:f5: 12:f7:03:fc:28:fc:23:58:bb:9d:4a:11:26:7f:1b: 0c:50:14:0f:6d:3f:0c:e3:ba:c8:81:44:95:89:d2: 9e:06:00:64:ad:78:65:a6:d9:9d:2a:01:75:16:77: d0:d4:00:a2:17:c2:ef:be:b5:ed:68:70:1c:83:f2: e6:87:c8:9e:c9:a9:5b:b5:04:66:fb:58:b3:60:33: 35:06:48:ba:69:28:ba:37:0b:d3:fe:03:7f:53:f1: 7e:64:52:db:5c:50:ce:0e:79:7d:d8:17:d2:c6:78: 1b:b8:5e:2f:83:0b:f4:0c:06:5e:ec:dd:7c:1c:91: 9f:eb:cd:a2:c5:68:13:ce:ef:67:0f:55:fa:a9:1c: 61:70:7c:22:18:c1:8b:5f:4f:68:f6:05:45:fa:6f: 83:44:a6:2d:db:aa:9e:53:4e:d3:1c:03:3e:0c:8b: 5d:3f:14:8f:c1:b9:9b:0f:fa:6b:1a:bf:7b:52:eb: 4e:cf Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Subject Key Identifier: FA:4F:9C:AA:BE:31:E7:BA:DD:E7:90:1E:FD:08:E8:49:DF:74:F4:1A X509v3 Authority Key Identifier: keyid:AD:DA:E5:C8:44:CE:F7:E8:E6:ED:5A:53:4B:43:3F:A2:42:3D:AC:8D Signature Algorithm: sha1WithRSAEncryption 5d:ed:5f:00:33:f2:75:5a:34:09:4a:4c:9d:d2:74:5b:a7:5b: 25:91:a2:b7:c4:74:f6:c3:30:3d:4c:7d:56:db:9b:05:0c:9d: 53:82:a7:68:ed:c8:b2:60:73:0c:32:86:2d:50:5a:98:46:1c: a3:e2:bd:17:60:67:5a:68:9a:00:44:bd:d9:87:53:5f:de:76: 70:16:34:81:4d:62:e5:00:84:3d:de:97:a0:8b:eb:fc:29:a0: b7:da:59:b8:6e:f1:c3:03:22:3e:09:9d:df:48:3c:a9:ee:f2: a9:c3:07:68:6d:4b:c2:6d:e2:4d:a2:59:72:ba:fe:3a:99:f3: d6:65:f2:1a:f9:61:31:ad:37:95:97:4c:a4:54:6a:bf:89:1c: 56:c4:db:7a:19:3c:bc:40:70:7a:ed:c2:b9:03:ca:f6:1d:c7: 0c:cc:49:c6:3e:a3:fa:b5:80:35:db:37:27:58:0c:44:8d:e3: 4e:ee:6a:de:8a:68:6e:91:84:8f:a7:24:87:c6:fd:e2:74:31: a5:45:42:e9:49:1b:e4:82:13:2d:06:98:be:93:97:3b:ce:f9: d3:30:96:de:df:83:04:ae:2c:44:21:53:cf:5a:09:a5:1b:0b: 9f:6a:d1:df:13:a8:3f:fb:7c:df:51:aa:5c:10:91:3d:1c:b3: 9b:88:a1:72 MD5 Fingerprint=8B:21:C7:64:D1:E0:DF:97:C3:20:7C:33:55:6E:75:77 -----BEGIN CERTIFICATE----- MIIDLjCCAhigAwIBAgIESabNHzALBgkqhkiG9w0BAQUwEzERMA8GA1UEAxMIbXlz ZXJ2ZXIwHhcNMDkwMjI2MTcxMDU1WhcNMTAwMjI2MTcxMDU1WjAuMRgwFgYDVQQK Ew9teSBvcmdhbml6YXRpb24xEjAQBgNVBAMTCWxvY2FsaG9zdDCCAR8wCwYJKoZI hvcNAQEBA4IBDgAwggEJAoIBALxJ4SYt2HpAPBhYDAhtluv/qS+QmeUR0tQCyhsC yBDVip0cLJGtogKRFgZjdOxg8jnKtN3yy5+FLFvLhTJyULeFgr+HJpIDpyL1EvcD /Cj8I1i7nUoRJn8bDFAUD20/DOO6yIFElYnSngYAZK14ZabZnSoBdRZ30NQAohfC 77617WhwHIPy5ofInsmpW7UEZvtYs2AzNQZIumkoujcL0/4Df1PxfmRS21xQzg55 fdgX0sZ4G7heL4ML9AwGXuzdfByRn+vNosVoE87vZw9V+qkcYXB8IhjBi19PaPYF Rfpvg0SmLduqnlNO0xwDPgyLXT8Uj8G5mw/6axq/e1LrTs8CAwEAAaN2MHQwDAYD VR0TAQH/BAIwADATBgNVHSUEDDAKBggrBgEFBQcDATAPBgNVHQ8BAf8EBQMDB6AA MB0GA1UdDgQWBBT6T5yqvjHnut3nkB79COhJ33T0GjAfBgNVHSMEGDAWgBSt2uXI RM736ObtWlNLQz+iQj2sjTALBgkqhkiG9w0BAQUDggEBAF3tXwAz8nVaNAlKTJ3S dFunWyWRorfEdPbDMD1MfVbbmwUMnVOCp2jtyLJgcwwyhi1QWphGHKPivRdgZ1po mgBEvdmHU1/ednAWNIFNYuUAhD3el6CL6/wpoLfaWbhu8cMDIj4Jnd9IPKnu8qnD B2htS8Jt4k2iWXK6/jqZ89Zl8hr5YTGtN5WXTKRUar+JHFbE23oZPLxAcHrtwrkD yvYdxwzMScY+o/q1gDXbNydYDESN407uat6KaG6RhI+nJIfG/eJ0MaVFQulJG+SC Ey0GmL6TlzvO+dMwlt7fgwSuLEQhU89aCaUbC59q0d8TqD/7fN9RqlwQkT0cs5uI oXI= -----END CERTIFICATE----- =========================================================================== BTW, I scriptisized the build of the above certificates: =========================================================================== #!/bin/sh certtool --generate-privkey > ca-key.pem chmod 0600 ca-key.pem cat >ca.info <<EOD cn = myserver ca cert_signing_key EOD certtool --generate-self-signed \ --load-privkey ca-key.pem \ --template ca.info \ --outfile ca-cert.pem certtool --generate-privkey > server-key.pem chmod 0600 server-key.pem cat >server.info<<EOD organization = my organization cn = localhost tls_www_server encryption_key signing_key EOD certtool --generate-certificate \ --load-ca-certificate ca-cert.pem \ --load-ca-privkey ca-key.pem \ --load-privkey server-key.pem \ --template server.info \ --outfile server-cert.pem certtool --generate-privkey > client-key.pem chmod 0600 client-key.pem cat >client.info<<EOD country = DE state = Saarland locality = Homburg organization = myorganization cn = localhost tls_www_client encryption_key signing_key EOD certtool --generate-certificate \ --load-ca-certificate ca-cert.pem \ --load-ca-privkey ca-key.pem \ --load-privkey client-key.pem \ --template client.info \ --outfile client-cert.pem =========================================================================== So there's still no success. :-( I have no preference about the tool itself, either ssvnc or another tool, I just need a tool that works somehow and still count on your recommendations. :-) I think you agree that I can't go into production without securing it properly. TIA for further hints. Regards Michael -- Michael Kress, kress@hal.saar.de http://www.michael-kress.de / http://kress.net P E N G U I N S A R E C O O L

Michael Kress napsal(a):
Michael Kress wrote:
Then I'll give a try on linux and mail the results later.
2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate loaded 2009.02.26 19:09:44 LOG7[14644:3086588128]: Key file: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG3[14644:3086588128]: error stack: 140B3009 : error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib 2009.02.26 19:09:44 LOG3[14644:3086588128]: SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM routines:PEM_read_bio:no start line vncviewer: VNC server closed connection
Is the private key stored in client-cert.pem with the certificate itself? I've noticed you generate client-key.pem but I am not sure whether you combine these two files somewhere. The lines from log state that the private key can not be found in /home/kress/keys/client-cert.pem Radek

Radek Hladik wrote:
Michael Kress napsal(a):
2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate loaded 2009.02.26 19:09:44 LOG7[14644:3086588128]: Key file: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG3[14644:3086588128]: error stack: 140B3009 : error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib 2009.02.26 19:09:44 LOG3[14644:3086588128]: SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM routines:PEM_read_bio:no start line vncviewer: VNC server closed connection
Is the private key stored in client-cert.pem with the certificate itself? I've noticed you generate client-key.pem but I am not sure whether you combine these two files somewhere. The lines from log state that the private key can not be found in /home/kress/keys/client-cert.pem
These are the contents (will change them anyways, so I can post them): ================================= ca-cert.pem ================================= -----BEGIN CERTIFICATE----- MIIC4DCCAcqgAwIBAgIESabNHzALBgkqhkiG9w0BAQUwEzERMA8GA1UEAxMIbXlz ZXJ2ZXIwHhcNMDkwMjI2MTcxMDU1WhcNMTAwMjI2MTcxMDU1WjATMREwDwYDVQQD EwhteXNlcnZlcjCCAR8wCwYJKoZIhvcNAQEBA4IBDgAwggEJAoIBALnbDviQvkjf MpNVtvFTQMgKbREF/DthdA0/1q+2a0o0C9x68OUbKZSjcMlMOnBTBqlVNQKUzjCQ dOm+gjdGAdkd2knRamI2U45HhCFthpbVqtKOjFlGOF8SYUZWdyk5ZPd10icoZzmr JuQU5548iz0T8NAHI0fulAQOwzWqAcsTenzQgfLZMHoJJzI9L6voyfl9vJ4kryMq Q1krq/gCCKkTJ7GFxaypLgkvv9XbrH0B6B1OdAg+00n/zbiQ3397DJLD46Snuf+m 7jJTuvIUAwNINjqu0oaB/onHiVkwIXsU2uJ3Qa6kDUOZVdamg+4swZKvNYQ77BGv NzNZc55j+m8CAwEAAaNDMEEwDwYDVR0TAQH/BAUwAwEB/zAPBgNVHQ8BAf8EBQMD BwQAMB0GA1UdDgQWBBSt2uXIRM736ObtWlNLQz+iQj2sjTALBgkqhkiG9w0BAQUD ggEBAKiPyK1g0Vt+7fHK8eUzlexPtBpLTv39QVDWuWU+sjlekJ3pDqXTD/a5Q6qk LabR0vx1b2mGMu60aQu6PyQ+RQLHhnEVV3lvho2mHZX9yyHQ+qMBdrHG2LJptAs0 XhfQMjQ6EDfas4n5NoomE6bG7J19xNPBlHdgpW89j71QZRGGxDCyMXVM/XGnpue4 7xdiarXf6VNCQK4R1zE8lTxBDd0WNP/ouf5N9I1FDUY0hv6/iDJnBXATjp7m2yWq P1VdTG5WmVURa3HyB2aEdBrgWheJAfQjLhwqUp2UP3J2q2AFaLvVu4+j6Q80HhXR au3hltqODnruKdcJgYNr3+/Edjg= -----END CERTIFICATE----- ================================= cacert.pem ================================= -----BEGIN CERTIFICATE----- MIIC4DCCAcqgAwIBAgIESabNHzALBgkqhkiG9w0BAQUwEzERMA8GA1UEAxMIbXlz ZXJ2ZXIwHhcNMDkwMjI2MTcxMDU1WhcNMTAwMjI2MTcxMDU1WjATMREwDwYDVQQD EwhteXNlcnZlcjCCAR8wCwYJKoZIhvcNAQEBA4IBDgAwggEJAoIBALnbDviQvkjf MpNVtvFTQMgKbREF/DthdA0/1q+2a0o0C9x68OUbKZSjcMlMOnBTBqlVNQKUzjCQ dOm+gjdGAdkd2knRamI2U45HhCFthpbVqtKOjFlGOF8SYUZWdyk5ZPd10icoZzmr JuQU5548iz0T8NAHI0fulAQOwzWqAcsTenzQgfLZMHoJJzI9L6voyfl9vJ4kryMq Q1krq/gCCKkTJ7GFxaypLgkvv9XbrH0B6B1OdAg+00n/zbiQ3397DJLD46Snuf+m 7jJTuvIUAwNINjqu0oaB/onHiVkwIXsU2uJ3Qa6kDUOZVdamg+4swZKvNYQ77BGv NzNZc55j+m8CAwEAAaNDMEEwDwYDVR0TAQH/BAUwAwEB/zAPBgNVHQ8BAf8EBQMD BwQAMB0GA1UdDgQWBBSt2uXIRM736ObtWlNLQz+iQj2sjTALBgkqhkiG9w0BAQUD ggEBAKiPyK1g0Vt+7fHK8eUzlexPtBpLTv39QVDWuWU+sjlekJ3pDqXTD/a5Q6qk LabR0vx1b2mGMu60aQu6PyQ+RQLHhnEVV3lvho2mHZX9yyHQ+qMBdrHG2LJptAs0 XhfQMjQ6EDfas4n5NoomE6bG7J19xNPBlHdgpW89j71QZRGGxDCyMXVM/XGnpue4 7xdiarXf6VNCQK4R1zE8lTxBDd0WNP/ouf5N9I1FDUY0hv6/iDJnBXATjp7m2yWq P1VdTG5WmVURa3HyB2aEdBrgWheJAfQjLhwqUp2UP3J2q2AFaLvVu4+j6Q80HhXR au3hltqODnruKdcJgYNr3+/Edjg= -----END CERTIFICATE----- ================================= ca-key.pem ================================= -----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAudsO+JC+SN8yk1W28VNAyAptEQX8O2F0DT/Wr7ZrSjQL3Hrw 5RsplKNwyUw6cFMGqVU1ApTOMJB06b6CN0YB2R3aSdFqYjZTjkeEIW2GltWq0o6M WUY4XxJhRlZ3KTlk93XSJyhnOasm5BTnnjyLPRPw0AcjR+6UBA7DNaoByxN6fNCB 8tkwegknMj0vq+jJ+X28niSvIypDWSur+AIIqRMnsYXFrKkuCS+/1dusfQHoHU50 CD7TSf/NuJDff3sMksPjpKe5/6buMlO68hQDA0g2Oq7ShoH+iceJWTAhexTa4ndB rqQNQ5lV1qaD7izBkq81hDvsEa83M1lznmP6bwIDAQABAoIBAADC7X5GNYld5Lqm zL+TXD4VkNnTgPOLVCrjupDwueLNcMj/9fGyWUrDGqiwd8LTDEFwWG3Ax1F6nggB IE5yqnpFvYm04m8xkskP8PIkHTuL942ySM/q0jtNe3mKzCUul4POB0TizP12/otL rKFA1T80UDXB+bqHNzMHDnSvVB+NXJRe093M5JJ5rjx0SfsSzhB1e7sOwlyAOOw+ FsgYTWSaTg9lCMoLp1B24Yb29G25tLwRZVkZINaZSS70R+5fcLBRzxX2JS/FmlwM 21Xt/R+cCVYIW8zM6XM/6CQQZoXzsQudBRzvk03mOJzpXXC1BHI5soJXZlFviYlf bkcLPaECgYEAw8BHAZo1SRDK0jjb8aHftPC8nFbAMUIaRS+Adj78ad+oSIup2WEi eC4VXleYYp0zMsJjJeV466qNpaNTBzA9XDcMI1EtiPn6UaJZBObQcdZtTKM+5pPz 23HTHiVJ7P5JWY7kMnuGnDne8c2AaTtmacVPB4FsDQqD4njZ1S1atM8CgYEA8w8Z PunLHeIXCgAHrjM86eCqEAf/gPfdiHIejb21itreFU3QTmx5fuuaJobcaxKwPHuw RY99Bt67TYPgCjgBFiEVR3UatK00Wibk5ANTuZpZS7sBe0oR80RtIkq+E7v+hF9u IsmUZKrWB2zODUgHgf/Ff35evGJcdbVJIRZxCGECgYA7ji1MRIF/uFcsvFXWXxxz rWaE3jPdCLJ7aCdaUnFzOLO3Vp6XX2EgVUz1Bgt7vT4NbGzD49v1P0+XHGivYDLa 8niD6jfDW+KXoaAZyKuUZtucHHKPrmXb1vaXTlr+eqMQV1QAM+rRbx3wTUiLO6I9 /eS8cNjR4ugbKA+GNyVIqwKBgQDn8pen9xnzeYd87oxly9WsZs5DoC5Ol7sb87N+ lfSB/t2CPRC1VkUXPqSLcZU0xM/T2EFeEFFC1hiuH1QUzF8VDBsvZuxGUSethIJX qWkjrMzcPShrzEKXAMyYtfTwBi4biqoinnVzH6hBy65S9FLd1wRU53ZmlgMf/RE9 dxoE4QKBgQC1pGzpYsyrQfV6ZYRBN9OQoU24Hn4yTvT0wGJGUiVTyAVgoVWWQPec 2e+jkH12jhYq1Aw9Wh7C7sPGPuyxL4Olobgmmx3vsNQvITk468dIahQD6lGEi8qM nQDpx8xPYHtTvrdojB8iHA8YzfA4XvzTZ8Hhn8RhS3PcYH0FYDRwHg== -----END RSA PRIVATE KEY----- ================================= client-cert.pem ================================= -----BEGIN CERTIFICATE----- MIIDXzCCAkmgAwIBAgIESabNHzALBgkqhkiG9w0BAQUwEzERMA8GA1UEAxMIbXlz ZXJ2ZXIwHhcNMDkwMjI2MTcxMDU1WhcNMTAwMjI2MTcxMDU1WjBfMQswCQYDVQQG EwJERTEXMBUGA1UEChMObXlvcmdhbml6YXRpb24xEDAOBgNVBAcTB0hvbWJ1cmcx ETAPBgNVBAgTCFNhYXJsYW5kMRIwEAYDVQQDEwlsb2NhbGhvc3QwggEfMAsGCSqG SIb3DQEBAQOCAQ4AMIIBCQKCAQCawDoza7KFSs6ysAqdRjh6QTTBkkj4VEvD1fgJ B+Vm04YVnxlbkzvcI0UvO6Xt/yr3sAj6Nx6hYezP+hmr2r2fj3W5VMkYXAsJVB3F HMNGfm9XVvKwSEDpz5UEgXKP2rzN6x168S9HeqlLiVj/QDnZfoRBu4SNBOCOcPpz iB391KXylMoIydh+74LkNqXx5g+DqSz3fWrViBv9XJ8ZCHfKSDGAVivHetOTv4R2 Kkb0UA2+Geul1qo4j7VsICSIeidGXU2FQctXDNt/Oeom0vwWvN6cLAts58y8sl8D zw68p/sUHYYT3YpjmZ8xYPzUre9KnBvxCK21H4EOavfls3XXAgMBAAGjdjB0MAwG A1UdEwEB/wQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwDwYDVR0PAQH/BAUDAweg ADAdBgNVHQ4EFgQUormnYZdAF9y6nJGOixTZbCSIFrQwHwYDVR0jBBgwFoAUrdrl yETO9+jm7VpTS0M/okI9rI0wCwYJKoZIhvcNAQEFA4IBAQArsy5kFv5fz7YBllgZ 4MIg3Fi4czGWR/V5GO2462vMa/2f8V9t9yEgLFeXDyq8UYcjzmcY3N/p6kyzNy9g ultf97jW/+WB11yaCHTj0RQ2talZxkvMc2lMpSqvsRdx5MA0Q6Xu8DQo9Ie8OHi3 jNOCRIvjy8f3+FJixcgz7qyIvvqrrHNc+E4eHXGYMtKPAAqc+IGUEUepkbgrEBKP Q/qs8xg0T1vCAIZvto6yo7urRfC5n/qNkHiGd2bGbXv719qaYM2wbMEeDexrLRPW f0Lkj2hLD7hTRkjAoqh/wCKYjTyYLZJtX7V2m0BJ6UxR5AIvbpratMyYuXL+zOcr HhYM -----END CERTIFICATE----- ================================= client-key.pem ================================= -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAmsA6M2uyhUrOsrAKnUY4ekE0wZJI+FRLw9X4CQflZtOGFZ8Z W5M73CNFLzul7f8q97AI+jceoWHsz/oZq9q9n491uVTJGFwLCVQdxRzDRn5vV1by sEhA6c+VBIFyj9q8zesdevEvR3qpS4lY/0A52X6EQbuEjQTgjnD6c4gd/dSl8pTK CMnYfu+C5Dal8eYPg6ks931q1Ygb/VyfGQh3ykgxgFYrx3rTk7+EdipG9FANvhnr pdaqOI+1bCAkiHonRl1NhUHLVwzbfznqJtL8FrzenCwLbOfMvLJfA88OvKf7FB2G E92KY5mfMWD81K3vSpwb8QittR+BDmr35bN11wIDAQABAoIBAAmdeABJ6MWvaDhi B8bN3iR6eLSuSipj0nFQkiC9hNtmuSYOxJyUAVwkNOBCbITlHd5V6bjiQ9zzIKur dnzfEnkfiMkDI5uH3Iev2kmtB9URdgmPNXUOiDn+09t7z4pwpNqGiUZiRfXDAVHY LtdtPirtWXpcFFhOvUUcb/NNuc9Tll29pTnsjEh35/mQnThFQfug/iaPxYm6f46P hsnpzsCMIpa6rO2HqMMN30D4c9fnDe97gzX4LqL6EbX4MszTOF/4QKEiRl8jOvNF dSTNyF/guzbpttbHu5Qrfb7w0nhbaJTFoji7+W+T7dRb9rCYfuGBMeYkIWm1Ts2h EbHvXAECgYEAwapRygjaOmD5gyP8saGgNKjHd+3F0ZX6Zrm8Ynhu4y4WjxzIf3ku Jy/bE0gJqxHNZ0AAAa9TPtx01uZ7AZO1oa67GYVxtoL5HyqWzIVnbN2EC+fDvBeO Y+fuwAupp1EbxlnzqZzTsV+Aa4uJN5wUDvyDMZUUwUgHS2dB5KirshcCgYEAzI9t kF9iZvr+hXE6B990/YCqxiqKE1675fvDG1eil3rRX9He66oM6BH/dMYJK7SPXCX+ leCsXxcoJ3JpvYxHds5qVp2OOfUrvvCGa/K2rQtiX41e5S41jU0G5TqgCMq87s5k xO3Y7Oka36M3I30Nlj8BEB84WjRXjHpn/Gq7ckECgYEAv+/FT66mWeVyZH5uGr5M wOPljP6iZ610lgrOoekqPQ2YXg3wyCWZkEzlmp5ytpDWOdY8K29P2aU0Ryf2EQIL qUo7NHgE0xXLQRA8lEZC0qpYDFSOsQPHo0xiWwM0CRdhp5vO2fML+2bjJ7MLM4oE dzXb8HAIOebhE+IqdCyWvdECgYAwoGvAJRyENGgqmobb9j+eP2bZIqWeAygRfK6d olBxR+3bpE0kolDdHeInBSiK7ioiEpoZUMZI+H1AG0+NknougNUAcAWuO1zBz/V0 VccdDZa99iI3wqtSQpxAA5alYGRXNFL6CTxG3QbZYLgrxH9lVubOyU0hDE4/g52S gGC8wQKBgGAl5uTTzzpZ8N3n+qoF6Q01DsnqlJ6dnoVFLBse4PXBoAw0rxHBhjOW 3sGI/7gpuA7GhRshHQy7JRJU8qGwr3fAUjRUt9jMDIriUgqJXWb+DjnTzkDDgGjB BZQiHWmFDI5dZeufbdfnei0VUcjs3ajM131rq3+vnsz1LXiQK56U -----END RSA PRIVATE KEY----- ================================= server-cert.pem ================================= -----BEGIN CERTIFICATE----- MIIDLjCCAhigAwIBAgIESabNHzALBgkqhkiG9w0BAQUwEzERMA8GA1UEAxMIbXlz ZXJ2ZXIwHhcNMDkwMjI2MTcxMDU1WhcNMTAwMjI2MTcxMDU1WjAuMRgwFgYDVQQK Ew9teSBvcmdhbml6YXRpb24xEjAQBgNVBAMTCWxvY2FsaG9zdDCCAR8wCwYJKoZI hvcNAQEBA4IBDgAwggEJAoIBALxJ4SYt2HpAPBhYDAhtluv/qS+QmeUR0tQCyhsC yBDVip0cLJGtogKRFgZjdOxg8jnKtN3yy5+FLFvLhTJyULeFgr+HJpIDpyL1EvcD /Cj8I1i7nUoRJn8bDFAUD20/DOO6yIFElYnSngYAZK14ZabZnSoBdRZ30NQAohfC 77617WhwHIPy5ofInsmpW7UEZvtYs2AzNQZIumkoujcL0/4Df1PxfmRS21xQzg55 fdgX0sZ4G7heL4ML9AwGXuzdfByRn+vNosVoE87vZw9V+qkcYXB8IhjBi19PaPYF Rfpvg0SmLduqnlNO0xwDPgyLXT8Uj8G5mw/6axq/e1LrTs8CAwEAAaN2MHQwDAYD VR0TAQH/BAIwADATBgNVHSUEDDAKBggrBgEFBQcDATAPBgNVHQ8BAf8EBQMDB6AA MB0GA1UdDgQWBBT6T5yqvjHnut3nkB79COhJ33T0GjAfBgNVHSMEGDAWgBSt2uXI RM736ObtWlNLQz+iQj2sjTALBgkqhkiG9w0BAQUDggEBAF3tXwAz8nVaNAlKTJ3S dFunWyWRorfEdPbDMD1MfVbbmwUMnVOCp2jtyLJgcwwyhi1QWphGHKPivRdgZ1po mgBEvdmHU1/ednAWNIFNYuUAhD3el6CL6/wpoLfaWbhu8cMDIj4Jnd9IPKnu8qnD B2htS8Jt4k2iWXK6/jqZ89Zl8hr5YTGtN5WXTKRUar+JHFbE23oZPLxAcHrtwrkD yvYdxwzMScY+o/q1gDXbNydYDESN407uat6KaG6RhI+nJIfG/eJ0MaVFQulJG+SC Ey0GmL6TlzvO+dMwlt7fgwSuLEQhU89aCaUbC59q0d8TqD/7fN9RqlwQkT0cs5uI oXI= -----END CERTIFICATE----- ================================= server-key.pem ================================= -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAvEnhJi3YekA8GFgMCG2W6/+pL5CZ5RHS1ALKGwLIENWKnRws ka2iApEWBmN07GDyOcq03fLLn4UsW8uFMnJQt4WCv4cmkgOnIvUS9wP8KPwjWLud ShEmfxsMUBQPbT8M47rIgUSVidKeBgBkrXhlptmdKgF1FnfQ1ACiF8LvvrXtaHAc g/Lmh8ieyalbtQRm+1izYDM1Bki6aSi6NwvT/gN/U/F+ZFLbXFDODnl92BfSxngb uF4vgwv0DAZe7N18HJGf682ixWgTzu9nD1X6qRxhcHwiGMGLX09o9gVF+m+DRKYt 26qeU07THAM+DItdPxSPwbmbD/prGr97UutOzwIDAQABAoIBAChZ+Otytcr1Syu4 atO/kLGA9+QerCyAVltjQabqQLAC45Lp/880k9zS9RJnbB5gZGjoPTy3lNXZ93iw tBnsj8nUzgF32FdAeygtt2PCsd6isnyIsJu38zUYOdpLgkbaVUvUsrWpWhbQUVdd 7DWU8MwCJQFkkJBBGzrj69kFyNVoz3devgKols/bjYnFWJhXGG5h+JGlE2P2TKzC yGf/6b/3v6e/Uu9Qx7t8anpxsWYDfvaslfGi5lbpJs58+1YdZ+ixAev7trxCMoiq hpt8QIkm9yaqhlHrCuN9e/PwDFC6eKU2pSJYC2naQgMyyEGTYiM8HmSivWTzo/pf 0TPo+OECgYEAz1g3d+JdY6h/6YkPQGfwc7hJmeEsB0YM1VygtnMXVNwv+EXymvvQ AecMl4fivDHa47G5wu7iMO5bd9fArCS22Ak6it+k/ZOw13fSiaQP0r2WYATCa9i2 atqEywYa+Ikxu8Z3XDj0UzSIrUfOwKmMSyYFp2B7W8owFqGaVKLsvp8CgYEA6Hjq ARu7Nu4KlS9XztNmNqOQdVmF6UoEulLOiEyBwuvGFTLxQp13VDsshLRV+uf3iyzP wry/FsWMIJCUCrCD2qCoFzLOkmu3OKSFs85p+MunPw2t61HKQpyphtFGgklv6k/9 dBgcGKtdp3OyNlSx1FCcHrzVANBaMq4LQhHQ8dECgYAqmA21A/x5V4kHWY+XhIKh 0w7TnK0lxV8niYK+WEBHv3/fOcdPzUD60xMEIfcTAA7eTYlCoT44HQ8PPHQpKNWi 5apwEuda7Dcc3FGU0u4pNacpjHDAJOG8a61x44ww2EYuM+QbPtv6J8WYCzNO4sWe Pm5U5v4QaiWc0I/aqSmHMwKBgAmqhWhYY9dr3GrJligWaCibcnU+rK+/kSTCLq5C KB8XuJvHC3sOmxiYgUhfSzfsj0FtMpJRUMy8mA/+kvlCz6i2h2a3iRlTe0HSrXCF g6iBp0ma4wFm3Dca1n2xk/H05b9jZhF+syRfc7xzthRGP0Kpu2QXy++FukpjLDqq DPsRAoGBAImoCRO1G3S6FGpTeLxBF3xPOs3sItY72+xNqmWUZMXo4cm23vJl0L11 mOvR9heJnyWvMHS4PPHPaKL+CKAIGgZobvzrxOGmq/C8ujNgqS1QbNnQgKhpI9Cs ax5pKXBqh3XZ2VUjJZTr/BqBo0YZTN0lC21wIrc7krHxcNm6NnZ8 -----END RSA PRIVATE KEY----- Regards Michael -- Michael Kress, kress@hal.saar.de http://www.michael-kress.de / http://kress.net P E N G U I N S A R E C O O L

Michael Kress napsal(a):
Radek Hladik wrote:
Michael Kress napsal(a):
2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate loaded 2009.02.26 19:09:44 LOG7[14644:3086588128]: Key file: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG3[14644:3086588128]: error stack: 140B3009 : error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib 2009.02.26 19:09:44 LOG3[14644:3086588128]: SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM routines:PEM_read_bio:no start line vncviewer: VNC server closed connection Is the private key stored in client-cert.pem with the certificate itself? I've noticed you generate client-key.pem but I am not sure whether you combine these two files somewhere. The lines from log state that the private key can not be found in /home/kress/keys/client-cert.pem
These are the contents (will change them anyways, so I can post them): client-cert.pem ================================= -----BEGIN CERTIFICATE----- MIIDXzCCAkmgAwIBAgIESabNHzALBgkqhkiG9w0BAQUwEzERMA8GA1UEAxMIbXlz ZXJ2ZXIwHhcNMDkwMjI2MTcxMDU1WhcNMTAwMjI2MTcxMDU1WjBfMQswCQYDVQQG HhYM -----END CERTIFICATE----- ================================= client-key.pem ================================= -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAmsA6M2uyhUrOsrAKnUY4ekE0wZJI+FRLw9X4CQflZtOGFZ8Z W5M73CNFLzul7f8q97AI+jceoWHsz/oZq9q9n491uVTJGFwLCVQdxRzDRn5vV1by sEhA6c+VBIFyj9q8zesdevEvR3qpS4lY/0A52X6EQbuEjQTgjnD6c4gd/dSl8pTK -----END RSA PRIVATE KEY-----
Stunnel can not find private key. It tries to locate it in client-cert.pem (I do not know why). Either change this in configuration or appen client-key.pem to client-cert.pem. The PEM file can contain both certificate and private key and stunnel will handle it. Radek

IT WORKS! Radek Hladik wrote:
Michael Kress napsal(a):
2009.02.26 19:09:44 LOG3[14644:3086588128]: error stack: 140B3009 : error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib 2009.02.26 19:09:44 LOG3[14644:3086588128]: SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM routines:PEM_read_bio:no start line vncviewer: VNC server closed connection
the above error is gone now.
Stunnel can not find private key. It tries to locate it in client-cert.pem (I do not know why). Either change this in configuration or appen client-key.pem to client-cert.pem. The PEM file can contain both certificate and private key and stunnel will handle it.
I did this now, i.e. I merged the client certificate and the private key into one file called client-cert.pem, first the cert, then the key. What I still had to do: Check the (advanced) option "Server uses VeNCrypt SSL encryption", because without it I got the following error: "SSL_Connect: 1204F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number" It works by executing these steps : 1) ./ssvnc -cacert cacert.pem -mycert client-cert.pem -ssl localhost:0 2) See the session fail 3) Check "Server uses VeNCrypt SSL encryption" 4) Reconnect As soon as I stay here, it's ok, but when I close ssvnc, the above setting won't get saved. My questions: 1) Isn't there a more comfortable end user compatible method to connect to the beast? (Because with this method, users obviously are urged to have Linux on the client side. Or would the purchase of real vnc enterprise edition would be the solution there?) 2) I simulated an interested user owning a certificate and walked through the different screens of the host (before, I created a few). I could easily access them by just chosing to connect to "localhost:0" "localhost:1" ... (given the requirement to have an ssh tunnel which the client machine easily can build) Is it possible to let him only view what he's supposed to? How? 3) Is there a way to stick one certificate to one virtual machine? e.g. stick client-cert-user001.pem to /etc/libvirt-bin/qemu/user001-vm01.xml (trying to find a solution to question 2) with this question). Thanks very much for your help so far, I really appreciate it! Kind Regards Michael -- Michael Kress, kress@hal.saar.de http://www.michael-kress.de / http://kress.net P E N G U I N S A R E C O O L

Michael Kress napsal(a):
IT WORKS!
Radek Hladik wrote:
Michael Kress napsal(a):
2009.02.26 19:09:44 LOG3[14644:3086588128 <http://www.snapanumber.com/>]: error stack: 140B3009 : error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib 2009.02.26 19:09:44 LOG3[14644:3086588128 <http://www.snapanumber.com/>]: SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM routines:PEM_read_bio:no start line vncviewer: VNC server closed connection
the above error is gone now.
Stunnel can not find private key. It tries to locate it in client-cert.pem (I do not know why). Either change this in configuration or appen client-key.pem to client-cert.pem. The PEM file can contain both certificate and private key and stunnel will handle it.
I did this now, i.e. I merged the client certificate and the private key into one file called client-cert.pem, first the cert, then the key.
What I still had to do: Check the (advanced) option "Server uses VeNCrypt SSL encryption", because without it I got the following error: "SSL_Connect: 1204F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number"
It works by executing these steps : 1) ./ssvnc -cacert cacert.pem -mycert client-cert.pem -ssl localhost:0 2) See the session fail 3) Check "Server uses VeNCrypt SSL encryption" 4) Reconnect
As soon as I stay here, it's ok, but when I close ssvnc, the above setting won't get saved.
My questions: 1) Isn't there a more comfortable end user compatible method to connect to the beast? (Because with this method, users obviously are urged to have Linux on the client side. Or would the purchase of real vnc enterprise edition would be the solution there?) 2) I simulated an interested user owning a certificate and walked through the different screens of the host (before, I created a few). I could easily access them by just chosing to connect to "localhost:0" "localhost:1" ... (given the requirement to have an ssh tunnel which the client machine easily can build) Is it possible to let him only view what he's supposed to? How? 3) Is there a way to stick one certificate to one virtual machine? e.g. stick client-cert-user001.pem to /etc/libvirt-bin/qemu/user001-vm01.xml (trying to find a solution to question 2) with this question).
Thanks very much for your help so far, I really appreciate it! Kind Regards Michael
O.K. I think we are mixing a few things here altogether. The scenario I mentioned involves ssvnc as a client (linux or windows) connecting via SSL/TLS to a stunnel on the beast and this stunnel connecting to localhost-only-listening VNC server without encryption itself. It looks like ssvnc can store a profiles and run with such a profile from a script so it should be easy to provide script that runs it (although I haven't tested it yet). I did test this scenario and it works and on the client side (windows) it was rather user friendly. The drawback of this is an identification of the connecting client, you may end up with creating CA for every VM or with some certificate common name filtering. Stunnel can verify client's certificate against given CA certificate so it is definetly doable. And you can set VNC password, which should be sufficient as the valid certificate is needed for the brute force attack on the password. The other option is to use SSH for tunneling and connecting to the localhost-only-listening VNC server without encryption itself. Its almost the same as in the previous case only you do not use X509 certificates but SSH keys. And you do not limit your users by CA issuing the certificate but the user and key they are using. You can specify allowed port-forwards (ssh tunnels) in authorized_keys file on the server. On the other hand you need to create user for such logins. If you would like to have the VeNCrypt function, I think you need ssvnc running on linux. However I do not know about the commercial VNC clients. And I think that the two previous scenarios are more flexible. The stunnel config used is: client = no cert = stunnel.pem [vnc] accept = 5901 connect = 5905 and I've made the stunnel.pem with (on Fedora 10) #cd /etc/pki/tls/certs #make stunnel.pem The VM is configured to listen on 5905 bound to localhost without any encryption. You can disable any incoming connections in firewall just to be sure... On the windows client I run ssvnc, using SSL/TLS connecting to port 5901. Prior a connection I've fetched the certificate and stored it as trusted. Radek

On Thu, Feb 26, 2009 at 10:47:37PM +0100, Michael Kress wrote:
My questions: 1) Isn't there a more comfortable end user compatible method to connect to the beast? (Because with this method, users obviously are urged to have Linux on the client side. Or would the purchase of real vnc enterprise edition would be the solution there?)
This is an ongoing area of development. The VeNCrypt extension provides two core capabilities - Data encryption of the session (only server & CA certs required) - Crude authentication (if using client clients too) For Fedora 11, I have been working on integrating SASL as an additional authenication mechanism. This provides a pluggable system for auth methods, which includes such things as - Username/password auth against PAM, LDAP, SQL database - One time passwords - GSSAPI Kerberos single sign on https://fedoraproject.org/wiki/Features/VirtVNCAuth Most of the auth methods require that you already have a secure data channel, so you'd have to layer them over the VeNCrypt extension. The last GSSAPI though is particularly interesting, because GSSAPI also provides data encryption, avoiding any need for VeNCRypt. So you will have a wide variety of options for accessing VNC - VNC on localhost, access remotely over SSH, authenticate VNC with any SASL auth method - VNC on public IP addr, using TLS for encryption, and any SASL auth method - VNC on public IP addr, using GSSAPI SASL auth method for auth and encryption
2) I simulated an interested user owning a certificate and walked through the different screens of the host (before, I created a few). I could easily access them by just chosing to connect to "localhost:0" "localhost:1" ... (given the requirement to have an ssh tunnel which the client machine easily can build) Is it possible to let him only view what he's supposed to? How?
In libvirt we do not yet any a way to setup per-VM access control lists. This is the next item on the TODO list....
3) Is there a way to stick one certificate to one virtual machine? e.g. stick client-cert-user001.pem to /etc/libvirt-bin/qemu/user001-vm01.xml (trying to find a solution to question 2) with this question).
You wouldn't really want todo this. All VMs on a host should typically use the same certificate. To get per-user access control, we need libvirt to get some kind of per-VM allow/deny list. You can see more about what i'm experimenting with here http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg01426.html Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Daniel P. Berrange wrote:
You can see more about what i'm experimenting with here
http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg01426.html
Hello Daniel, Hello Radek, thanks so much for your great help - you've teached me a lot and you have given me a good orientation. What I will follow now is this way: specify allowed port-forwards (ssh tunnels) in the authorized_keys file on the server, as proposed by Radek. Allowed port forwards should be secure enough. Moreover I will go back to non-encrypted vnc which will be listening on 127.0.0.1. "Non-encrypted" because it will work with standard clients (realvnc+putty). Building up a tunnel is not that difficult, it even can be clicked and written together on one msdos .bat file for the convenience of the (end) user. Anyways, I will follow the development of libvirt and the surrounding products, it seems thrilling to me! :-) Kind regards & thanks again Michael -- Michael Kress, kress@hal.saar.de http://www.michael-kress.de / http://kress.net P E N G U I N S A R E C O O L
participants (4)
-
Daniel P. Berrange
-
Michael Kress
-
Radek Hladik
-
Radek Hladik