signed SSL certificates

dietmar · May 28, 2013

You tried to restart the 'pveproxy' service?

# service pveproxy restart

anthonysomerset · May 28, 2013

yes i did

FastLaneJB · May 28, 2013

anthonysomerset said:
i updated the certs to my purchased ssl, while the interface now works with no self-signed errors, the java applet doesnt work

also tried the instructions at http://pve.proxmox.com/wiki/HTTPSCertificateConfiguration for the /etc/pve certs not just /etc/pve/local

i'm getting the following error when trying to load the console java applet after both attempts:

Code:

Error: TLS handshake failed javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: cert path too long

This is the same problem I get. I'm guessing it's because I'd loaded the Intermediate Certificate into the .pem file and while that works for PVEProxy, Java doesn't like it. I had to give up and go back to the self signed certificates for now.

tom · May 28, 2013

we just updated the wiki for 3.0, works here.

see http://pve.proxmox.com/wiki/HTTPSCertificateConfiguration

anthonysomerset · May 28, 2013

tom said:
we just updated the wiki for 3.0, works here.

see http://pve.proxmox.com/wiki/HTTPSCertificateConfiguration

i can confirm this works for me and the JAVA applet works, however when i check the SSL at http://www.sslshopper.com/ssl-checker.html it still complains about a broken chain because no intermediate crt provided for the webserver

mir · May 28, 2013

It does not work here. See screendump.

Java errors:

Code:

Initializing...
Connecting to esx1.datanom.net, port 5900...
Connected to server
RFB server supports protocol version 3.8
Using RFB protocol version 3.8
VeNCrypt chooser
X509Plain
Generating TLS context
Doing TLS handshake
Error: TLS handshake failed javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: certificate does not match
java.lang.Exception: TLS handshake failed javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: certificate does not match
    at com.tigervnc.vncviewer.TLSTunnelBase.setup(TLSTunnelBase.java:73)
    at com.tigervnc.vncviewer.RfbProto.authenticateX509(RfbProto.java:416)
    at com.tigervnc.vncviewer.VncViewer.doAuthentification(VncViewer.java:445)
    at com.tigervnc.vncviewer.VncViewer.doAuthentification(VncViewer.java:406)
    at com.tigervnc.vncviewer.VncViewer.connectAndAuthenticate(VncViewer.java:385)
    at com.tigervnc.vncviewer.VncViewer.run(VncViewer.java:202)
    at java.lang.Thread.run(Unknown Source)
RFB socket closed

I think tigervnc has problems with intermediate certificates.

mir · May 28, 2013

Just a longshot. Is tigervnc making a literal comparison of the certificates disregarding the concept of *.foo.bar. In other words does tigervnc not understand star certificates?

mir · May 28, 2013

It seems to be related to this commit:
http://pve.proxmox.com/pipermail/pve-devel/2011-January/000590.html

anthonysomerset · May 28, 2013

mir said:
Just a longshot. Is tigervnc making a literal comparison of the certificates disregarding the concept of *.foo.bar. In other words does tigervnc not understand star certificates?

interesting thoughts there however i used the wildcard SSL setup with the "old" apache setup and never had issues with the java applet its just since moving to the PVEProxy application, actually very tempted to just reinstall apache or nginx and try and just reverse proxy port 443 through to port 8006

jpscharf · May 29, 2013

I following the directions for setting up nginx as a proxy (http://forum.proxmox.com/threads/7983-nginx-proxy-in-front-of-PVE-2-0), ignoring the parts regarding apache. I added proxy_read_timeout; proxy_connect_timeout 120; after location to limit 502 gateway timeouts, and added my combined crt (http://www.westphahl.net/blog/2012/01/03/setting-up-https-with-nginx-and-startssl/) and unencrypted key. I tested the web interface, Java VNC and API and they all seem to work. Also, you get the benefit of not having to specify the port.

dietmar · May 29, 2013

mir said:
It seems to be related to this commit:
http://pve.proxmox.com/pipermail/pve-devel/2011-January/000590.html

Maybe you forgot to restart 'pveproxy' and 'pvedaemon'?

anthonysomerset · May 29, 2013

dietmar said:
Maybe you forgot to restart 'pveproxy' and 'pvedaemon'?

no i followed your isntructions to the letter - i can either have the Java Applet working but the security chain broken through a lack of an intermediate cert in the PEM file or i can have the security chain working but the java applet not working with a cert too long error as described above

mir · May 29, 2013

dietmar said:
Maybe you forgot to restart 'pveproxy' and 'pvedaemon'?

No, I did not.

mir · May 29, 2013

In your case the probleming is related to the patch mentioned above. Specifically this part:

Code:

 +	    if (certs == null || certs.length > 1) {
 +	      throw new CertificateException("cert path too long");
 +	    }

The above means that if there are returned more than one cert it bails with an error. Eg. chained certs are not allowed.

dietmar · May 29, 2013

mir said:
The above means that if there are returned more than one cert it bails with an error. Eg. chained certs are not allowed.

But that code is from 2011 - so the current code in 3.0 should behave exactly the same as in 2.X

mir · May 29, 2013

dietmar said:
Maybe you forgot to restart 'pveproxy' and 'pvedaemon'?

Now, this is weird. I have been able to make it work but working in a wrong way.

Before:
Following the instructions for creating a chained certificate when the server, like nginx, does not have an option to load a chained cert file like apache.
cat my.pem subclass2.pem subclass1.pem ca.pem > unified.pem 'input too long'
cat subclass2.pem ca.pem > unified.pem 'certificates does not match'
cat subclass1.pem ca.pem > unified.pem 'certificates does not match'
cat my.pem subclass2.pem ca.pem > unified.pem 'certificates does not match'
cat my.pem subclass1.pem ca.pem > unified.pem 'certificates does not match'

after:
cat my.pem ca.pem > ca-unified.pem this works

Conclusion:
The patch mentioned above is not able to handle all legitimate situations and therefore it is not complete.

mir · May 29, 2013

dietmar said:
But that code is from 2011 - so the current code in 3.0 should behave exactly the same as in 2.X

Yes, and I did also mention the same in 2012 so this bug has been sitting around in 2.x also.

Reported back in 2011: http://forum.proxmox.com/archive/index.php/t-7316.html
My report in 2012: http://forum.proxmox.com/archive/index.php/t-12180.html

dietmar · May 29, 2013

mir said:
Following the instructions for creating a chained certificate when the server, like nginx, does not have an option to load a chained cert file like apache.

What instructions do you talk about exactly?

dietmar · May 29, 2013

mir said:
The patch mentioned above is not able to handle all legitimate situations and therefore it is not complete.

The idea is that /etc/pve/pve-root-ca.pem is the CA (direct issuer) for all node certs. I am not sure why you want/need additional chain.

anthonysomerset · May 29, 2013

dietmar said:
The idea is that /etc/pve/pve-root-ca.pem is the CA (direct issuer) for all node certs. I am not sure why you want/need additional chain.

the problem seems to be that pveproxy is not using this for https connections and thus the security trust chain is broken when checking the http interface with a tool like: http://www.sslshopper.com/ssl-checker.html as theres no intermediate certs presented

signed SSL certificates

Proxmox Staff Member

Member

Well-Known Member

Proxmox Staff Member

Member

Famous Member

Famous Member

Famous Member

Member

New Member

Proxmox Staff Member

Member

Famous Member

Famous Member

Proxmox Staff Member

Famous Member

Famous Member

Proxmox Staff Member

Proxmox Staff Member

Member