TheCloudlessSky's questions

I requested a reissue of a GeoTrust certificate in light of the Heartbleed bug. We're using HAProxy 1.5-dev22 with OpenSSL enabled. I've updated OpenSSL on all affected instances.

The PEM that HAProxy requires is a concatenated version of the certificate, the intermediate certificates and the private key:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----

I can validate this PEM with OpenSSL:

$ openssl verify -CAfile my_app.pem my_app.pem
my_app.pem: OK

And then configure HAProxy:

...snip...

bind *:443 ssl crt /etc/ssl/certs/my_app.pem ca-file /etc/ssl/certs/my_app.pem

...snip...

And then start HAProxy

$ sudo service haproxy start
 * Starting haproxy haproxy
[ALERT] 098/142005 (13287) : parsing [/etc/haproxy/haproxy.cfg:16] : 'bind *:443' : inconsistencies between private key and certificate loaded from PEM file '/etc/ssl/certs/my_app.pem'.
[ALERT] 098/142005 (13287) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
[ALERT] 098/142005 (13287) : Proxy 'secure': no SSL certificate specified for bind '*:443' at [/etc/haproxy/haproxy.cfg:16] (use 'crt').
[ALERT] 098/142005 (13287) : Fatal errors found in configuration.
   ...fail!

I've done the reissue twice now and both times OpenSSL can validate the PEM. However, HAProxy can't seem to read this PEM. I've also recompiled HAProxy with the latest source but the issues still persists.

If I revert to the previous PEM, HAProxy starts without errors.

Disregarding HAProxy for a second, according to this site, I can validate if a certificate/private key match:

(openssl x509 -noout -modulus -in my_app.crt | openssl md5 ; openssl rsa -noout -modulus -in my_app.key | openssl md5) | uniq

And when I run it after downloading the CRT from GeoTrust, the output is two separate values. According to that site, if they matched only one hash would be returned.

We're setting up HAProxy to balance our application (ASP.NET MVC 3 running on IIS). We want our process to be without scheduled maintenance for deployment. I'm trying to figure out the correct way to do a "see-saw" approach to only serve one version of the application to new requests at a single time. Here's what I've come up with so far:

1. Remove the first half of the servers from HAProxy by reloading the config:

   $ sed -i 's/web01.*/& disabled/' /etc/haproxy/haproxy.cfg
   $ sed -i 's/web02.*/& disabled/' /etc/haproxy/haproxy.cfg
   $ /etc/init.d/haproxy reload
   

2. Update the application on each down instance and poke them with curl to warm them.

3. Bring back the first half and remove the second half:

   $ sed -i 's/\(web01.*\) disabled$/\1/' /etc/haproxy/haproxy.cfg
   $ sed -i 's/\(web02.*\) disabled$/\1/' /etc/haproxy/haproxy.cfg
   $ sed -i 's/web03.*/& disabled/' /etc/haproxy/haproxy.cfg
   $ sed -i 's/web04.*/& disabled/' /etc/haproxy/haproxy.cfg
   $ /etc/init.d/haproxy reload
   

4. Repeat step 2 for the second half.

5. Bring back the second half:

   $ sed -i 's/\(web03.*\) disabled$/\1/' /etc/haproxy/haproxy.cfg
   $ sed -i 's/\(web04.*\) disabled$/\1/' /etc/haproxy/haproxy.cfg
   $ /etc/init.d/haproxy reload
   

With the approach described above, the existing requests would gracefully continue using V1 of the app and then V2 for any subsequent requests. I'm OK with this because it'd significantly reduce the chance of serving the two different versions.

However, using sed to replace the config seems like a hack. Here are my other alternatives I've thought of using:

1. Use the UNIX socket to do this same "see-saw" approach. However, because the UNIX socket can only work with one server at a time and the deployment could take a few seconds per-server, it could lead to HTML at V2 but JavaScript for V1. If anything, it's much easier to write backwards compatible code than forwards compatible. So using this approach seems like it might not work.

2. Use rolling deployments across the servers with either UNIX sockets or the health check. During my research, I've come across this approach as being most popular. However, this leads to the same problems as the UNIX sockets - having to write forward compatible code.

Maybe I'm completely over complicating this or missing something obvious...

I have 1 external IP for my network and a FQDN (ex: mycompany.com). Currently to connect to multiple computers on my network I change the RDP port via registry.

For example to connect to one server, I have mycompnay.com:3390 and use my router to forward the port to the right host.

Ideally I'd like to be able to type servername.mycompany.com and route to the appropriate machine.

I have a "central server" using Server 2008 R2 if it helps. Is it possible to easily do what I'm trying to achieve?