Trying Out Let's Encrypt

If you’re like me, you probably never bothered setting up a security certificate on your personal/hobby projects since there was a cost to get the certificate and some pain with actually acquiring/installing the certificate.
If you haven’t heard of Let’s Encrypt, it’s a publicly available, free, certificate authority that you can use to generate SSL/TLS certificates for any website. Now that Let’s Encrypt is available, I thought I’d give it a spin since it looked easy enough and the price was right.

Installation with Nginx

I expected the process to be somewhat painful to get signed up, get the certificate issued to my server, and get it installed. It turns out, it’s really not painful at all thanks to this nifty tutorial from Digital Ocean.
All you really have to do is install some packages with your package manager, run a simple command line command, follow the prompts, and then configure your preferred web server to use the certificate. It’s worth noting that nothing in that tutorial is specific to Digital Ocean. I prefer Linode and run everything there, but the instructions are very generic, so they should work just fine with any host.
Nginx is my default choice for a web server/proxy. Apache support is baked into Let’s Encrypt, but I’m happy to report that Nginx works just fine as well. The only real difference (as I understand it) is that you’ll need to manually or programmatically handle the renewal of your Let’s Encrypt certificates. I believe you get that taken care of “out of the box” if you’re using Apache, but that tutorial link above has a nice solution for Nginx.
The actual certificate generation & download amounts to this (see tutorial for details):
sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
sudo service nginx stop
cd /opt/letsencrypt
./letsencrypt-auto certonly --standalone
You probably noticed there was an nginx stop command in there. That’s needed for this particular install method because Let’s Encrypt temporarily uses port 80 to authenticate your server before issuing the certificate. There are other ways of doing it, but this is a super easy way to get that first certificate. In the tutorial, they explain how to automate certificate renewal and that process does not require Nginx to stop, so this is a one time per root domain kind of deal.

Gotchas

For my use case (personal & hobby sites), Let’s Encrypt works perfectly. While I was researching it, I did see a few situations where it may be less than optimal, so I’ll point them out in case they are important to you.

No Wildcard Support

You can include any number of domains in your certificate, but you must explicitly list out each one. If I wanted to get a certificate for project1.adambyram.com, project2.adambyram.com, and project3.adambyram.com, all in one certificate, I definitely could.
What isn’t allowed though is getting a certificate that covers all subdomains (*.adambyram.com). This is only an issue in cases where you have a SaaS application that generates a dynamic subdomain for each user/account.

Certificate Issuance Throttling

You may be thinking you could work around the lack of wildcard support by automating the process of getting a new certificate when you need it. The catch is that you’ll be throttled to 5 certificates per top level domain per week. I’m sure this limit is subject to change, so double check this restriction before you give up. This wouldn’t be as bad if it didn’t apply to the top level domain, but unless/until that changes, this makes using Let’s Encrypt on a service that uses dynamic subdomains a no-go.

Required “A” DNS Record

In order to verify your domain, Let’s Encrypt will check your DNS entries and verify that the server that is attempting to generate the certificate is the same server matching the domain’s A DNS record. That means you’ll have to run the certificate generation script from your server. It’s probably not a huge deal for most small scale sites, but for larger sites or PaaS-hosted sites, it may be an issue.
There are alternate ways to get the certificates, including using a CSR to do it, so you can still use Let’s Encrypt in these cases, but the tutorial I linked to won’t be as helpful.

90 Day Certificate Expiration

Not necessarily a gotcha, but something to be aware of. All Let’s Encrypt certificates expire 90 days after issue, so you’ll need to plan for that (you can renew it programmatically). You can regenerate the certificates anytime you want, so I decided to follow the tutorial’s advice and generate new ones when the existing certificate was 30 days or less away from expiration. Obviously, the more domains you secure, the more overhead this adds, but at least it’s relatively easy to automate.

Final Thoughts

In less than 5 minutes, I had my non-HTTPS site upgraded with a brand new SSL/TLS certificate and all traffic rerouted through the secure channel. I’m really impressed it wasn’t more involved.
The security certificate seems to be trusted just fine by all of the devices & browsers I’ve tried. The fact that the certificates have to be renewed at least every 90 days is a little bit of an annoyance, but it’s easy enough to automate that I don’t really see it being an issue. Overall, Let’s Encrypt is really an awesome solution and I plan to roll it out to all of my personal/hobby sites going forward.
If you’re curious what the certificate looks like in your browser, this blog has one of my Let’s Encrypt certificates, so feel free to check that out.

Trying Out Let’s Encrypt

If you’re like me, you probably never bothered setting up a security certificate on your personal/hobby projects since there was a cost to get the certificate and some pain with actually acquiring/installing the certificate.

If you haven’t heard of Let’s Encrypt, it’s a publicly available, free, certificate authority that you can use to generate SSL/TLS certificates for any website. Now that Let’s Encrypt is available, I thought I’d give it a spin since it looked easy enough and the price was right.

Installation with Nginx

I expected the process to be somewhat painful to get signed up, get the certificate issued to my server, and get it installed. It turns out, it’s really not painful at all thanks to this nifty tutorial from Digital Ocean.

All you really have to do is install some packages with your package manager, run a simple command line command, follow the prompts, and then configure your preferred web server to use the certificate. It’s worth noting that nothing in that tutorial is specific to Digital Ocean. I prefer Linode and run everything there, but the instructions are very generic, so they should work just fine with any host.

Nginx is my default choice for a web server/proxy. Apache support is baked into Let’s Encrypt, but I’m happy to report that Nginx works just fine as well. The only real difference (as I understand it) is that you’ll need to manually or programmatically handle the renewal of your Let’s Encrypt certificates. I believe you get that taken care of “out of the box” if you’re using Apache, but that tutorial link above has a nice solution for Nginx.

The actual certificate generation & download amounts to this (see tutorial for details):
sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
sudo service nginx stop
cd /opt/letsencrypt
./letsencrypt-auto certonly --standalone

You probably noticed there was an nginx stop command in there. That’s needed for this particular install method because Let’s Encrypt temporarily uses port 80 to authenticate your server before issuing the certificate. There are other ways of doing it, but this is a super easy way to get that first certificate. In the tutorial, they explain how to automate certificate renewal and that process does not require Nginx to stop, so this is a one time per root domain kind of deal.

Gotchas

For my use case (personal & hobby sites), Let’s Encrypt works perfectly. While I was researching it, I did see a few situations where it may be less than optimal, so I’ll point them out in case they are important to you.

No Wildcard Support

You can include any number of domains in your certificate, but you must explicitly list out each one. If I wanted to get a certificate for project1.adambyram.com, project2.adambyram.com, and project3.adambyram.com, all in one certificate, I definitely could.

What isn’t allowed though is getting a certificate that covers all subdomains (*.adambyram.com). This is only an issue in cases where you have a SaaS application that generates a dynamic subdomain for each user/account.

Certificate Issuance Throttling

You may be thinking you could work around the lack of wildcard support by automating the process of getting a new certificate when you need it. The catch is that you’ll be throttled to 5 certificates per top level domain per week. I’m sure this limit is subject to change, so double check this restriction before you give up. This wouldn’t be as bad if it didn’t apply to the top level domain, but unless/until that changes, this makes using Let’s Encrypt on a service that uses dynamic subdomains a no-go.

Required “A” DNS Record

In order to verify your domain, Let’s Encrypt will check your DNS entries and verify that the server that is attempting to generate the certificate is the same server matching the domain’s A DNS record. That means you’ll have to run the certificate generation script from your server. It’s probably not a huge deal for most small scale sites, but for larger sites or PaaS-hosted sites, it may be an issue.

There are alternate ways to get the certificates, including using a CSR to do it, so you can still use Let’s Encrypt in these cases, but the tutorial I linked to won’t be as helpful.

90 Day Certificate Expiration

Not necessarily a gotcha, but something to be aware of. All Let’s Encrypt certificates expire 90 days after issue, so you’ll need to plan for that (you can renew it programmatically). You can regenerate the certificates anytime you want, so I decided to follow the tutorial’s advice and generate new ones when the existing certificate was 30 days or less away from expiration. Obviously, the more domains you secure, the more overhead this adds, but at least it’s relatively easy to automate.

Final Thoughts

In less than 5 minutes, I had my non-HTTPS site upgraded with a brand new SSL/TLS certificate and all traffic rerouted through the secure channel. I’m really impressed it wasn’t more involved.

The security certificate seems to be trusted just fine by all of the devices & browsers I’ve tried. The fact that the certificates have to be renewed at least every 90 days is a little bit of an annoyance, but it’s easy enough to automate that I don’t really see it being an issue. Overall, Let’s Encrypt is really an awesome solution and I plan to roll it out to all of my personal/hobby sites going forward.

If you’re curious what the certificate looks like in your browser, this blog has one of my Let’s Encrypt certificates, so feel free to check that out.

Building a Better Budgee #1 – The Beginning

Budgee was a simple personal finance application I wrote for the first iPhone. It went live in October 2008. It was one of the first 10,000 apps1 in the Apple App Store.

Budgee v1.0

Budgee v1.0 App Icon & Slogan

The premise was simple. First, you defined a list of budget categories. Then, you set a target budget amount for those categories. After that, you entered your actual expenses as they happened.

As you depleted the money in a category, it let you know how much you had left in your budget. It also supported exporting transactions2, used regional currency formats, and many simultaneous budgets.

Budgee v1.0's Main Screen

Budgee v1.0’s Main Screen

Scratching an Itch

Budgee was an app I wanted since I bought my first iPhone. When I saw the WWDC keynote announcing the “real” app store3, I knew I had to build it.

I bought my first Mac, a black MacBook, and got to work. It took a while to build. Objective-C was surprisingly different from any language I had used before. After a few months, I finished the app, submitted it to the App Store, and away things went.

Budgee was a big success to me. It didn’t make a ton of money, but it did more than pay for my MacBook. On top of that, it was a great experience building & supporting my app. It was fantastic to get emails from people who loved the app.

After 11 updates over 2 years, app usage trailed off as the app store grew. The amount of money I made from the app wasn’t enough to justify the effort to keep maintaining it. It cost $1.99 and it was just a one time charge.

If it sold a ton, the story would be different, but in the end, it only sold around 1500 copies. The app needed more time for development & support than I had.

In July 2010, the last update went live in the store. Even though it didn’t look modern anymore, the app was still used, so I wanted to leave the app as long as I could. It reached a point that iOS had advanced so far, that the app simply didn’t work on new devices.

The effort required to update it was monumental, so I pulled the app from the store in September 2013.

A New Beginning

In the years since, I’ve learned a lot. I know more about software development, personal finance, and business. I’ve also started a family. All these things brought new thoughts & perspectives that didn’t exist for me back in the early days.

I’ve also tried nearly every budgeting/personal finance tool out there. The problem is, none of them help me manage my money the way I want it managed. There are plenty of great apps4 that may or may not work for you, but at the end of the day, they just don’t work for me.

Building a new, more modern Budgee has been on my mind since 2010. I’ve had so many things going on in my personal and professional life that it just didn’t happen. I finally have enough time, resources, perspective, and desire. It’s time to begin the process of building the Budgee system I’ve always wanted.

My plan is to create a series of blog posts documenting my progress as I go. I enjoy reading dev blogs of programmers I admire. I thought this will be a nice way to give back while also creating some level of accountability. Even if no one else ever reads this, I know I’ll enjoy looking back on it one day.

It’s going to take some time, but this will be worth it!

UPDATE: 1/31/2016

Not too long after I posted this, I discovered that the app I’ve been using for the last several years (YNAB) was going to be updated with a web based version and lots of new features. The new version of YNAB launched about a month ago and it includes nearly all the features I wanted for a new version of Budgee. One of the features the desktop YNAB didn’t have that I really wanted was the ability to schedule transactions and then see those future transaction totals for a given category while budgeting for a given month. The schedule transactions do show in the budget view in the new YNAB and everything else works very similarly to what I envisioned for Budgee.

Due to this, I have decided not to continue Budgee development at this time. If it turns out that YNAB won’t work for me longer term, I’ll revisit this decision. So far, the new YNAB seems like a winner.

  1. For reference, there are now about 1.5 million apps in the App Store. ↩
  2. It used a very crude built-in HTTP server that generated a CSV file for download. Apple supports much better approaches these days. ↩
  3. The original plan was for everyone to simply build web apps that can install an icon on the device’s home screen and the only native apps you’d have on the phone were from Apple. ↩
  4. You Need A Budget (YNAB) and EveryDollar are two in particular that are excellent choices. YNAB is as I’ve found to my “perfect” app, but it’s still missing a lot. ↩