Upon further reflection, the "X.509 hostname verification failed"
warning was due to user error on my part. It's been well over a year
since I looked at this, so I forgot a couple of things (as we say in
Texas, "I've slept since then.") I apologize for my confusion.
(1) If you use gencert.cn, then you should not get a hostname
verification warning, as long as you generated the certificate on the
same machine on which you are running the TurboVNC server. gencert.cn
generates a certificate for only the host on which the script is executed.
(2) gencert.san is used to generate a certificate that can be used on
multiple servers. The allowed hostnames are embedded in the
certificate. More specifically, look at the "[alt_names]" section in
openssl.cnf (which is provided in the same Gist as the script.) In my
example, I configured the certificate such that it can be used on
multiple TurboVNC servers ("bullwinkle", "boris", and "sherman") on my
local network, in addition to the machine on which the certificate was
generated.
In both cases, if you attempt to use the certificate on a server other
than one of the ones specified in the certificate, then you get the
"X.509 hostname verification failed" warning. Note also that you can
connect to the server using its IP address rather than its hostname, as
long as one of the hostnames in the certificate resolves to that IP
address. This works the same as if you were using the certificate to
secure a web site. If, for instance, your web site can be reached at
"www.myfancysite.com" or "myfancysite.com", then its SSL certificate
will similarly need a SubjectAltName field that allows for both of those
aliases. The "X.509 hostname verification failed" dialog in TurboVNC is
similar to a certificate error that you might get in a browser ("The
security certificate presented by this website was issued for a
different website's address" or something similar:
Loading Image...
).
Note also that, once you run gencert.cn or gencert.san, you can copy:
server.key to ~/.vnc/x509_private.pem on the server
server.crt to ~/.vnc/x509_cert.pem on the server
ca_server.crt to {home directory}/.vnc/x509_ca.pem on the client
to avoid having to specify -x509key and -x509cert when launching the
server and to avoid having to specify the CA cert in the viewer.
Post by QTDear DRC,
I used this blog to help myself in creating the certificates.
https://jamielinux.com/docs/openssl-certificate-authority/introduction.html
Essentially, I created a root certificate that is self-signed, then
create an "intermediate" certificate, signed by the root certificate, to
sign the certificate to be used by the VNC server. Thus the certificate
for VNC server should not be seen as "self-signed." At least that is
how I understand it. The question is now the difference between a user
certificate and a server certificate. Should the VNC server use a
server certificate and the client use a user certificate?
The "X.509 hostname verification failed." is due to what exactly? Does
the Subject Alternative Names need to match the hostname? Does the CRL
need to be hosted somewhere or providing it the CRL file (as done in the
viewer option) is good?
Could you shed a bit more light in the working of this.
Best,
Quyen
P.S. Maybe I should test with a certifcate from say Lets-Encrypt or CACert?
https://gist.github.com/dcommander/fc608434735026dd8215
<https://gist.github.com/dcommander/fc608434735026dd8215>
to generate a self-signed certificate. gencert.cn
<http://gencert.cn> generates a "regular"
certificate, and gencert.san generates a certificate with the "Subject
Alternative Names" extension. Both should work with TurboVNC 2.1.
/opt/TurboVNC/bin/vncserver -x509cert {path_to}/server.crt -x509key
{path_to}/server.key -SecurityTypes x509none
(server.crt and server.key are generated by the aforementioned scripts.)
Then, on your client, start the viewer (start the Java TurboVNC Viewer
if you are using a Windows client), click "Options", then under the
"Security" tab, next to "CA cert", click "Load" and select the
ca_server.crt file that was generated by the aforementioned scripts.
Click "OK" and proceed with the connection. Note that you will probably
get a warning "X.509 hostname verification failed." That is expected,
but you can click "Yes", and it should still authenticate successfully
(it's been a while since I looked at this feature, but I think the
warning is because of the self-signed certificate. I don't think that
warning is generated with a "real" certificate. I was able to, for
instance, use my existing code signing certificate from Thawte as an
X.509 certificate in TurboVNC.)
Post by QTDear DRC,
I'm using Turbovnc server 2.1 (build 20160920). The connection is
already tunnel through ssh but just trying out the x509 certificate
authentication. I'm not very verse with this authentication method
yet. I'm getting a hostname verification failure but can still connect
if I press yes at the prompt. What could I be doing wrong?
Best,
Quyen
