# On Improving Certificate Strength

This semester, I’m taking EECS 388: Introduction to Computer Security.

During one of the latest lectures, we were introduced to SSL Labs’ SSL Server Test. While my site received an A rating, my professor’s received an A+.

Looking at the breakdown in score, I learned that I was lacking in all areas that SSL Labs grades for: certificates, protocol support, key exchange, and cipher strength. I found the first category especially curious, given that I was paying for a “premium” TLS certificate. Indeed, my website had a certificate from Comodo. It cost \$20 a year.

As a result of seeing that my professor had a TLS certificate from Let’s Encrypt (and also being a poor college student) I ditched my Comodo certificate for the free one. Although the change in the duration of the certificate is -50%, the change in the cost is -∞%. Not bad!

Of course, I was still hellbent on improving my site’s rating. We learned in class about HSTS: a mechanism that informs browsers to only load a website over HTTPS, and not HTTP.

To be included on Google Chrome’s preload list, I went to this site. My website wasn’t eligible because:

1. I didn’t redirect all HTTP traffic to HTTPS.
2. I didn’t actually provide an HSTS header.

Now, I had tried to remedy the first problem in the past through adding a .htaccess file with the following contents:

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}


The problem that I continuously ran into was peculiar. Jekyll, the static-site generator that my website is created by, added the standard front matter to the .htaccess file. This rendered the file useless for forcing HTTPS connections. Given that front matter was being injected into the file each time the site was built, I figured there was no clear way around this. (In retrospect, of course, there was.)

By manually modifying the .htaccess after an initial build of the site, I was able to prevent front matter injection from happening in the first place. It feels silly that the problem plagued me for this long, but we all look stupid from time to time.

Thus, the first problem was fixed. The second problem was resolved shortly after the first by adding one more line to my .htaccess:

Header set Strict-Transport-Security "max-age=31415926; includeSubDomains; preload" env=HTTPS


With these two problems finally worked out, I was eligible to be on Chrome’s preload list. I should be officially on it within a couple of weeks.

The immediate results of all these changes, you might ask? My website now has a rating of A+. While I still have improvements to make in the areas of protocol support, key exchange, and cipher strength, I can rest assured knowing that my certificate is strong.

I’m quite thankful that my hosting service, DreamHost, provides such a simple interface for installing the certificate on my website. I’m also thankful that my professor, J. Alex Halderman, helps to make Let’s Encrypt available to the masses through his work with the Internet Security Research Group (ISRG).