Post-Heartbleed: Securing Nginx with Free SSL (StartSSL) and SPDY on CentOS 6

It has been exactly two days since the internet melted. If you are a sysadmin, you haven't slept since April 7th. The Heartbleed bug (CVE-2014-0160) exposed the memory of nearly every web server running OpenSSL 1.0.1, leaking private keys, session cookies, and passwords.

If you are still running shared hosting, you are in trouble. In a shared environment, a neighbor's compromised process could theoretically scrape your memory space. This is why at CoolVDS, we strictly use KVM (Kernel-based Virtual Machine) virtualization. Hardware isolation isn't just a buzzword; this week, it was the difference between a secure contained breach and a total catastrophe.

Today, we aren't just patching. We are rebuilding trust. We are going to set up a secure, high-performance web stack using Nginx, obtain a Free SSL certificate from StartSSL (because security shouldn't cost $100/year), and enable Google's SPDY protocol to mitigate the latency overhead of encryption.

Step 1: The Heartbleed Patch (CentOS 6.5)

Before you even think about certificates, you must ensure your OpenSSL library is patched. If you are on a CoolVDS instance, our repositories are already mirroring the latest updates, but you need to trigger them.

Check your version:

If you see built: Mar 17 2014 or earlier with version 1.0.1e, you are vulnerable unless your distro backported the fix. RedHat/CentOS patched openssl-1.0.1e-16.el6_5.7.

Execute the update immediately:

# Update the system
yum update openssl -y

# Verify the changelog to ensure the CVE is patched
rpm -q --changelog openssl | head -n 5

# RESTART SERVICES (Crucial! Libraries remain in memory)
service nginx restart
service php-fpm restart

Pro Tip: Simply updating the package does not clear the vulnerability from RAM. You must restart any daemon linked to libssl. When in doubt, reboot the whole VPS. It takes 20 seconds on our NVMe storage arrays.

Step 2: Free SSL Certificates with StartSSL

Paying Verisign or Thawte huge sums for a simple domain validation certificate is becoming obsolete. While we wait for automated solutions to mature, StartSSL is currently the viable option for free Class 1 certificates supported by major browsers.

Note: The interface is archaic, but the crypto is sound.

Generate your Private Key and CSR

Do not let the certificate authority generate your private key. Generate it on your CoolVDS server to ensure it never leaves your control.

# Create a directory for assets
mkdir -p /etc/nginx/ssl
cd /etc/nginx/ssl

# Generate a 2048-bit RSA key (AES256 encrypted)
openssl genrsa -aes256 -out domain.key 2048

# Generate the Certificate Signing Request (CSR)
# Norway (NO) is the country code. Be accurate with the FQDN.
openssl req -new -key domain.key -out domain.csr

Copy the content of domain.csr and paste it into the StartSSL control panel. Once validated, download your .crt file and the intermediate CA bundle.

Chain Your Certificates

Nginx requires the site certificate and the intermediate chain in a single file.

Step 3: Nginx Configuration with SPDY and HSTS

SSL adds a handshake overhead. To counter this, we will use SPDY 3.1. This is a protocol developed by Google that multiplexes streams over a single TCP connection. It is the precursor to the upcoming HTTP/2 standard.

We will also implement HSTS (HTTP Strict Transport Security). This tells browsers like Chrome and Firefox to never try to connect to your site via HTTP again.

Edit your Nginx virtual host:

server {
    listen 443 ssl spdy;
    server_name example.no;

    ssl_certificate      /etc/nginx/ssl/domain_bundle.crt;
    ssl_certificate_key  /etc/nginx/ssl/domain.key;

    # Modern Cipher Suite (2014 High Security)
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Drop SSLv3 due to recent weaknesses
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    
    ssl_prefer_server_ciphers on;
    
    # Optimization
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    # HSTS (Strict-Transport-Security)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        root /var/www/html;
        index index.html index.php;
    }
}

Step 4: The Norwegian Context - Latency & Law

Why go through this trouble? Two reasons: Datatilsynet and Latency.

With the recent revelations about mass surveillance, Norwegian businesses are under immense pressure to secure data transit. Running plain HTTP for login forms is no longer negligence; it's a liability. By using CoolVDS, your data resides in Oslo, governed by Norwegian law, not in a data center in Virginia subject to the Patriot Act.

Furthermore, SSL negotiation requires round trips. If your server is in Germany or the US, but your customers are in Trondheim, the handshake will feel sluggish. Hosting on CoolVDS ensures that the TCP handshake happens in <10ms for local users, making the SSL overhead negligible.

Conclusion

The events of this week have changed the landscape. SSL is no longer optional, and "I can't afford a cert" is no longer an excuse when StartSSL exists. However, a certificate is only as secure as the server it lives on.

Don't risk your private keys on oversold shared hosting where memory leaks are a neighborly threat. Take control of your stack.

Deploy a secured, Heartbleed-patched CentOS 6 instance on CoolVDS today. Your users' privacy depends on it.