Kirsle.net logo Kirsle.net

OpenSSL for Kirsle.net!

April 18, 2014 by Noah

A while after the Heartbleed SSL vulnerability made headlines, Wired.com ran an article titled "It's Time to Encrypt the Entire Internet" urging everyone to deploy SSL/TLS encryption on their sites.

SSL certificates tend to be pretty expensive, though, which is one reason I hadn't looked into it that closely in the past. In a Reddit comment thread about that Wired article some people mentioned Namecheap as a good option for simple SSL certs. So, I got a simple domain-level certificate for $9 for Kirsle.net. :) So all kirsle.net URLs are now running over https! This blog post is about the experience of setting up SSL and wrestling with various applications in the process.

Generating the Certificate

The simplest guide I found that I followed to make a certificate was Generate CSR - Apache OpenSSL. One command creates a passphrase-protected key file, the next one generates the signing request:

openssl genrsa –des3 –out kirsle.key 2048​
openssl req -new -key kirsle.key -out kirsle.csr

You apparently need a 2048-bit RSA key these days before a Certificate Authority will consider your signing request. I pasted in my CSR file and filled out some forms, got an e-mail verification sent to the address on my WHOIS record for my domain, and before I knew it I was e-mailed a zip file containing my certificate and the Comodo CA certificates.

Certificate Chain File

Various apps will need your Certificate Authority's chain to be in a single file. You can create this file by catting the certificates into one file in "reverse" order, with your site's certificate on top, and the root certificate on bottom. Comodo gave me these files (and this is also the order for the chain file):

  • Kirsle.net certificate: www_kirsle_net.crt
  • Intermediate CA certificate: COMODORSADomainValidationSecureServerCA.crt
  • Intermediate CA certificate: COMODORSAAddTrustCA.crt
  • Root CA certificate: AddTrustExternalCARoot.crt

So I generated the chain as follows:

cat www_kirsle_net.crt COMODORSADomainValidationSecureServerCA.crt \
    COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > cacert.pem

Apache2 mod_ssl

I'm running a Debian server, so I just symlinked the ssl.load and ssl.conf files from my /etc/apache2/mods-available into my mods-enabled, and then edited the ssl.conf. All I changed in it was to uncomment the SSLHonorCipherOrder on line.

I removed the sites-enabled/default-ssl and then edited my Kirsle.net config file to add a <VirtualHost *:443> version. I had to look at the default-ssl file to get an idea which options were needed (if I missed any, Apache would fail to start!)

Relevant SSL options for my VirtualHost:

    # SSL
    SSLEngine on
    SSLCertificateChainFile /etc/ssl/crt/cacert.pem
    SSLCertificateFile /etc/ssl/crt/www_kirsle_net.crt
    SSLCertificateKeyFile /etc/ssl/crt/kirsle.key
    SSLOptions +StdEnvVars
    BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

Note: if you leave out the chain file, web browsers will still behave fine (because they're smart enough to download the intermediary certificates themselves), but other things will break. For example, the Python requests module will throw an SSL exception if the server doesn't give it the intermediary certificates!

After making sure https://www.kirsle.net/ was working, I made an update to my Rophako CMS to support SSL sites better and then made the switch-over. Any requests going to my HTTP Kirsle.net are redirected to the SSL version and given a Strict Transport Security header.

As a fun side note, Apache supports Perfect Forward Secrecy by default (using the default SSLCipherSuite option of HIGH:MEDIUM:!aNULL:!MD5).

Starting or restarting Apache requires you to enter the SSL key's passphrase at the command line. For simple config updates, service apache2 graceful will reload them without needing a full restart, so you don't need to enter the passphrase then.

Dovecot IMAP

I use Dovecot for my IMAP mail server on Kirsle.net, and I wanted it to use my shiny new SSL certificate. Before this, I was using a self-signed certificate, and apparently Thunderbird doesn't even warn you if that self-signed certificate changes at any point. After the Heartbleed vulnerability was fixed, I re-generated new self-signed certs and was shocked that Thunderbird happily accepted the new certificate without even telling me. It would've been extremely easy to Man-in-the-Middle my e-mail server. (I had since then installed an extension in Thunderbird to police SSL certificates for me as a workaround).

So, configuration is pretty simple, just edit /etc/dovecot/conf.d/10-ssl.conf and enter in the new paths to your chain file and private key. Note that if you use just your domain's certificate, clients like Thunderbird that support SSL properly will complain about the certificate being insecure, and unlike web browsers, Thunderbird doesn't bother downloading the intermediary certificates itself.

One catch with Dovecot is that if your private key file is encrypted with a passphrase like mine is, doing service dovecot restart won't work. Dovecot will start in a way where it won't support TLS but will otherwise appear to function normally.

To start Dovecot with a passphrase, you need to run dovecot -p (as root) to start the service. It will prompt for your passphrase at the command line and then start up. The service can be stopped normally using service dovecot stop.

Postfix SMTP Server

This one I'm a bit upset about. Postfix has absolutely NO support for using a passphrase protected TLS key file! Even their official documentation states that the key file must not be encrypted.

That is so full of wtf. Postfix is a widely deployed SMTP server for Linux, and it has to use insecure, unprotected TLS key files. So, I'm still using a self-signed certificate for Postfix (and my Thunderbird add-on will tell me if this certificate ever changes, so don't get any ideas!). I don't send outgoing mail very often, anyway, and if I care enough I'll PGP encrypt. But, I'll be looking into an alternative SMTP server sometime soon.

Tags:

Comments

There are 4 comments on this page. Add yours.

Avatar image
David Ward posted on April 28, 2014 @ 08:20 UTC

A note to anyone reading this, concatenating the chain files in reverse order like stated here works work with Amazon ELB (Elastic Load Balancers)

Don't include your public cert (www_kirsle_net.crt in the example above) as there is a separate field for that when adding a cert to an ELB.

Avatar image
cduvhen posted on August 6, 2014 @ 12:37 UTC

Very good things. Hot news for all.

Avatar image
Anonymous posted on December 28, 2014 @ 19:07 UTC

You may take a look at the Qualys SSL test. It may be better to disable RC4. Also you may remove the Root CA certificate from the chain to avoid "contains anchor" warnings.

Avatar image
Noah (@kirsle) posted on January 6, 2015 @ 22:11 UTC

Thanks for the tip. The RC4 deprecation thing must be recent; I was wrestling with the SSL test a while back when I found somebody's Apache config on GitHub where they listed out a ton of cipher suites and SSL Labs was giving my site an F, and long story short the default configuration on Debian got an A+ so I shouldn't have touched it. ;)

Removed the RC4 support. And thanks for the tip on the "contains anchor" warning; I didn't know what that was about or how to fix it.

Add a Comment

Used for your Gravatar and optional thread subscription. Privacy policy.
You may format your message using GitHub Flavored Markdown syntax.