The Brain Dump

Analytics

Thursday, November 24, 2016

Let's Encrypt provides free SSL certificates, which is awesome, and a free tool to automatically verify domain ownership and install the certificate, which is also awesome. Unfortunately I was finding the process to be much less awesome whenever I needed to manually verify my domain ownership. After trying a couple different tools, I found what seems to be the simplest cross-platform way to get a manually verified Let's Encrypt SSL certificate issued.

This post will walk you through the steps that I used to get my cert for AWS API Gateway, but the same steps should apply for any situation where you need to get a cert using DNS verification instead of HTTP verification (e.g. for an internal tool or appliance that isn't exposed to the internet).

You will be prompted to add a specific TXT record to your domain's DNS entries to verify ownership. After that, your certificate will be generated and downloaded to the folder where you executed the commands.

Full Version

First I tried Certbot, which is considered to be the official Let's Encrypt client, but unfortunately it doesn't run on Windows, it requires a lot of dependencies on Linux, and it displayed a big "WARNING: THIS IS NOT COMPATIBLE AND MIGHT BREAK THINGS" message when I tried to run it on my Amazon Linux EC2 instance. So back to the drawing board.

Fortunately Let's Encrypt allows you use any of a list of available ACME compatible clients, but most of the clients that I looked at failed at least one of the following tests:

Created by a developer/company that I trust

Considered production ready by the developer

Works on Windows or Amazon Linux (ideally both)

Has as few dependencies as possible

Supports DNS based verification

Google's acme client provides a simple, cross-platform statically-linked binary that has no dependencies. It is written in Go, but Google provides pre-built, platform specific executables so that you don't need to have Go installed. It meets all of my criteria.

Binary releases are available for Windows, Linux (x86 & ARM), and MacOS. A SHA1 checksum file is available on the page as well so you can double check the signature to make sure that your binary was not corrupted. You can put the binary in the folder where you want to generate your certificate for simplicity sake or add it to your PATH.

Step 2: Register an account with Let's Encrypt

The next step is to register an account with Let's Encrypt from the command line. This will create a Let's encrypt account key (not to be confused with your certificate's private key) and a config file in the default config directory (~/.config/acme or the Windows equivalent). You can read about what each option does by typing "acme help reg". Your email address will not be verified, so be sure to double check it. It is where your expiration notices will be sent. Also be mindful not to accidentally omit the mailto:.

acme reg -gen -accept mailto:username@domain.com

Step 3: Generate a private key for your certificate

While acme itself has no dependencies, the process still has one indirectdependency. Though Google's acme client can generate a private key for you, currently they automatically use the ECDSA signature algorithm and there is no option to specify otherwise (I opened an issue). At present AWS API Gateway only supports 2048 bit RSA certs so I had to use openssl to generate my private key. The good news is that openssl is installed by default on most Linux boxes including AWS EC2 instances. Note that you don't need to generate a CSR (Certificate Signing Request), just a private key. Make sure that you put the generated key in to your working folder.

One of the more important conditions for me was that I could verify my domain ownership using DNS instead of HTTP. AWS API Gateway requires an SSL certificate in order for you to set up a custom domain (chicken and egg problem). Alternatively I could have hosted a verification file on S3 and pointed my DNS at S3 for verification before pointing it back at API Gateway, but it is much easier for me to just set a TXT record once and be done with it. The "acme cert" command below issues a request for a new certificate based on the private key that you just created, using DNS verification.

acme cert -k api.mydomain.com.key -dns=true api.mydomain.com

After running the command you will be prompted with the instructions e.g. Add a TXT record for _acme-challenge.api.domain.com with the value "somelongrandomstring" and press enter after it has propagated.

You can usually add the DNS TXT record via the web console of the service provider that manages DNS for your domain. After you have made the change you can use this free DNS lookup tool from Google to see if your update has started propagating. Once that is confirmed, hit Enter and a PEM certificate named api.mydomain.com.crt should be created right there in the directory beside the private key. Note that the acme client will automatically bundle your certificate and the Let's Encrypt Intermediate certificate into the same file. Your certificate is the first one in the file.

The acme client will also return a URL where you can download the certificate, but you can just ignore that if you like. FYI the downloadable version is a binary DER encoded cert.

Free DNS hosting

If your current DNS host doesn't allow you to set TXT records then it is probably time to switch. Cloudflare is actually an awesome free option that most people don't even consider. If you set up your domain under their free plan, but configure it not to route requests through their network, they are basically just a free, reliable DNS hosting service with a great interface.

Try not to lose your account key

One last thing to note, once you have completed the verification process for a given sub-domain you don't need to go through it again to issue a new certificate as long as you are still using the same Let's Encrypt account key (not to be confused with your certificate's private key). So make sure you keep your account.key and config file safe. They are in the config directory (~/.config/acme).

Renewing your certificate

The process to "renew" your certificate is really just to issue a new cert with a later expiration date. If you are using the same account key as before then there is no verification step. You can just run the command below in the directory that contains your certificate's private key

Monday, October 15, 2012

The Android 4.1.2 Jelly Bean update is gradually rolling out OTA (over the air), but if you are impatient you can update manually. I had previously unlocked my boot loader and installed su (superuser), but I otherwise like to keep things as stock possible (no custom ROMs, no kernel hacks, no custom recovery manager). If you have a similar setup then this upgrade is very simple; it can actually be completed without connecting the phone to a computer, so it really is OTA.

P.S. Over time, the OTA files for other stock builds will become available (but only for Google supported Nexus devices). You can monitor this forum post at xda-developers if you have a non-yakju ROM. I am personally waiting for the takju file myself so I will update this post when it made available.

Update: The takju file is now available, the instructions are the same, just substitute this link takju-JZO54K-from-JRO03C for the OTA file and this file name: 06fa1976791d.signed-takju-JZO54K-from-JRO03C.06fa1976.zip where relevant.

Steps:

Download theyakju4.1.2 (JZO54K) from 4.1.1 (JRO03C) OTA update file directly to your phone (you are downloading directly from Google, not from this blog). The file is about 15MB so you may want to do the download over wifi.

If you have anything important that isn't stored in the cloud, please back it up before you start. You never know what might go wrong. This "worked for me", but your mileage may vary. I take no responsibility if you phone stops working, explodes or tries to take over the world. Caveat Emptor!

Tuesday, July 10, 2012

The Android 4.1.1 Jelly Bean update is gradually rolling out OTA (over the air), but if you are impatient you can update manually. I had previously unlocked my boot loader and installed su (superuser), but I otherwise like to keep things as stock possible (no custom ROMs, no kernel hacks, no custom recovery manager). If you have a similar setup then this upgrade is very simple; it can actually be completed without connecting the phone to a computer, so it really is OTA.

P.S. Over time, the OTA files for other stock builds will become available (but only for Google supported Nexus devices). You can monitor this forum post at xda-developers if you have a non-yakju or non-takju ROM

If you have anything important that isn't stored in the cloud, please back it up before you start. You never know what might go wrong. This "worked for me", but your mileage may vary. I take no responsibility if you phone stops working, explodes or tries to take over the world. Caveat Emptor!

Thursday, April 19, 2012

For some bizarre reason the beta version of Chrome for Android doesn't expose a menu option for accessing the browser history. Thankfully, the latest (Apr 17) update includes support for accessing the history via the chrome://history/ URL (just type it into the URL bar). You can always bookmark this URL for future reference.

Hopefully they will add a menu option soon, but till then you can use this workaround.

Wednesday, April 4, 2012

The manual OTA upgrade from Android 4.0.2 to 4.0.4 on my Galaxy Nexus caused me to lose root access. Apparently the setuid bit was removed from /system/bin/su during the upgrade. This can be easily fixed by following the steps below. It assumes you are familiar with adb, fastboot and Clockwork Mod Recovery.

Sunday, April 1, 2012

The Android 4.0.4 is gradually rolling out OTA (over the air) , but if you are impatient you can update manually. I had previously unlocked my boot loader and installed su (superuser), but I otherwise like to keep things as stock possible (no custom ROMs, no kernel hacks, no custom recovery manager). If you have a similar setup then this upgrade is very simple; it can actually be completed without connecting the phone to a computer, so it really is OTA.

If you have anything important that isn't stored in the cloud, please back it up before you start. You never know what might go wrong. If something does go terribly wrong, and you need to start over from scratch. The Android 4.0.4 Factory Image for the Galaxy Nexus is now available as well.

Oh, and before you go, this "worked for me", but your mileage may vary. I take no responsibility if you phone stops working, explodes or tries to take over the world. Caveat Emptor!

Monday, April 11, 2011

Gavin King of Red Hat/Hibernate/Seam fame recently unveiled the top secret project that he has been working on over the past two years, a new language and SDK designed to replace Java in the enterprise. The project came out of hiding without much fanfare or publicity at QConBeijing in a keynote titled "The Ceylon Project - the next generation of Java language?". It took a fair amount of Google translate for me to get to the relevant slidedecks, (Embedded below) but once I found them, the information was all there in plain English.

According to the slides, the Ceylon Project aims to create a programming language and SDK for business computing, designed with an eye to the successes and failures of the Java. It is built to run on the JVM, uses static typing, and supports high-order functions, while maintaining a strong focus on being easy learn and easy to read.

If you ask, me it sounds like just what the doctor ordered. Java is great, it is an extremely popular, open(ish), robust, readable language that as a ton of superb libraries. However it is burdened by its legacy and cant seem to evolve enough to match the levels productivity and fun seen in more recently developed languages like Groovy, Python and C#, with C# being the most apropos comparison due to its statics typing and enterprise focus.

I've been eagerly waiting on the tech media to devour the details of this controversial effort and spew forth a riveting combination of analysis and hypothesis. Up till now, there has been nothing but crickets chirping so I figured I'd get the ball rolling with a layman's blog post.

What I like

The overall vision: learn from Java's mistakes, keep the good, ditch the bad

Things that may grow on me

Classes, Methods and Attributes looking almost identical...can't decide if that is good or bad

Things that make me go hmmm

All the new keywords for existing concepts: shared, satisfies, assign, variable, local

The simplification of the public/protected/private access/visibility levels

The Smalltalk-like syntax for inline functions as parameters

Things I didn't fully get

The Closure and block structure examples had some things that were a little puzzling. e.g. the "name" attribute of type "Name" returns "Name(“Gavin”, “King”)"

Some of the more intricate details of the type system..

While I am still waiting to hear some opinionated analysis from people who study theses things for a living, I am cautiously optimistic about the direction things are headed. I think the Java/Open Source/Programming world needs a language like this. Nevertheless, there are a number of factors that could affect whether or not the project gains momentum.

For one, while a lot of work has clearly gone into the language design, a production ready compiler and SDK a clearly still a ways off. That means that there is still a lot of work left to be done, especially if they plan to try and address the modularity issues that they claim Maven and OSGI have failed to solve. I would also love to see how Ceylon handles integration with existing Java code/libraries...smooth integration/compatibility is key for any pretender to the throne.

Additionally, I don't think Red Hat can do it alone, it is going to take buy in from the Java/Open Source community to really get things going. Google and Apache are two names that spring to mind, but that then immediately raises the question about where Ceylon comes into play in the ongoing power struggle between Oracle, Google and Apache over the rights to use Java without limitation. Could Ceylon become a key piece in the puzzle and spur an influx of supporters? Or will it simply raise Oracle's ire and force IBM to keep its distance?

I for one welcome our new CylonCeylon overlords. Its going to be interesting to watch and see how it all plays out.

Update: Gavin has posted a response highlighting two reasons for not reusing one of the many existing languages targeting the JVM (1) A built in solution for "defining user interfaces and structured data using a typesafe, hierarchical syntax" i.e. less dependency on XML (2) "The extremely outdated class libraries that form the Java SE SDK are riddled with problems. Developing a great SDK is a top priority of the project."