A new development, as I was building a response to your email, I just happened to copy a crt/pem generated by the BE server (sitting on NFS) to the local path on the FE server, and it worked, though when that same file sits on the NFS (r/o mount) it doesn't. However, when everything (including the default key) was sitting on the NFS, it was still being served back to the client, so the assumption is that haproxy can properly read that mount, as long as the key being accessed is the default key.
To test this theory, I moved the default key out to the NFS mount, and adjusted the haproxy config to use that as the default key. It worked properly. However, any of the keys contained in the folder, that aren't explicitly defined (such as the default) don't seem to be recognized during standard operation. In further tests, I adjusted the bind line to the following (explicitly defining a second key) bind <ip>:443 ssl crt <nfs>/default.pem crt <nfs>/site2.pem crt <local> crt <nfs> strict-sni Accessing site2 with the above bind line worked correctly. Removing the 'site2.pem' from the bind line, leaving the <nfs> and <local> folders defined to be processed resulted in site2 dropping offline (due to the strict-sni). Copying the site2.pem back to the local folder, leaving it out of haproxy.cfg (and restarting the daemon) restored site2 to service. The NFS folder tree (from root on down to the certs.d folder) is 'chmod' 755, and all of the key files within are 644 (the same permissions are assigned to the local folder tree). I've even tried resetting the NFS share to be R/W, to no avail. I'm not sure how to get enough debug data out of haproxy to determine what it's doing during init to determine if it's finding the key files on the NFS to pull in to it's running config, or anything else that could prove useful in further troubleshooting this. Any suggestions is greatly appreciated. Thank you. On Tue, Jun 10, 2014 at 7:19 PM, Lukas Tribus <[email protected]> wrote: > Hi Jason, > > > > I believe I've figured out the error of my ways. > > I recently changed where I'm generating SSL keys, in order to push keys > to a > > R/O mount for the FE server, letting a back-end server handle the > security > > aspects. > > > > The openssl on the backend/generator system is 1.0.1-4ubuntu5.14, the > > openssl on the frontend/haproxy system is 1.0.1e-2+deb7u10 > > > > While they are both 1.0.1 branch versions (which would make me assume > > they're compatible), apparently they are not. > > Its not that. You can generate and sign certificates even with non-openssl > tools, and still use them. > > > > > I regenerated the keys on the frontend system, and all of the SNI > > functionality is once again working. > > I suspect CN/UCC/SAN values are corrupted or wrong when coming from one > the "backend/generator" system then. > > Triple check how you generate them and validate them again [1]. > > > HAproxy/Openssl does no magic here, either the certificate contains > the proper values and SNI will work, or not. > > > > Regards, > > Lukas > > > [1] > http://www.cyberciti.biz/faq/test-ssl-certificates-diagnosis-ssl-certificate/ >
