Dear 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?
On Fri, Oct 21, 2016 at 8:30 PM, DRC <[email protected]>
wrote:
> Try using one of the scripts here:
>
> https://gist.github.com/dcommander/fc608434735026dd8215
>
> to generate a self-signed certificate. 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.
>
> Once generated, start the server with:
>
> /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.)
>
>
> On 10/21/16 7:07 PM, QT wrote:
> > Dear 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
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> TurboVNC-Users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/turbovnc-users
>
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
TurboVNC-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/turbovnc-users
