The easiest way to get a manaully verified Let's Encrypt SSL certificate

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).

 

TL;DR Version

1. Download the Google acme client binary from their GitHub page
2. acme reg -gen -accept mailto:username@domain.com
3. openssl genrsa -out api.mydomain.com.key 2048
4. acme cert -k api.mydomain.com.key -dns=true api.mydomain.com

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:

1. Created by a developer/company that I trust
2. Considered production ready by the developer
3. Works on Windows or Amazon Linux (ideally both)
4. Has as few dependencies as possible
5. 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.

 

 

Step 1: Download the google/acme client binary from GitHub

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 indirect dependency. 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.

openssl genrsa -out api.mydomain.com.key 2048

 

 

Step 4: Request a certificate from Let's Encrypt using DNS verification instead of HTTP

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

acme cert -k api.mydomain.com.key api.mydomain.com

How to manually "OTA" update your Galaxy Nexus from 4.1.1 to Android 4.1.2

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.

Preconditions:

1. You have a GSM Galaxy Nexus (i9250)
2. You are currently running the latest Android 4.1.1 (JRO03C)
3. You have the stock yakju or takju ROM.  (You can use this app to check)
4. You have root access (su/super user is installed) 
5. You have a terminal application installed (e.g. Android Terminal Emulator)
6. You *have not* replaced the stock recovery system/partition with a custom recovery (like Clockwork Mod)
7. You have 15 - 20 minutes to spare

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:

1. Download the yakju 4.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.  
2. Copy the update file to the /cache folder (this requires super user permission)
• Open a terminal window
• su
• cp /sdcard/Download/24a9a760f32e.signed-yakju-JZO54K-from-JRO03C.24a9a760.zip /cache/
3. Boot into recovery mode
• Power off your phone
• While the phone is off, press and hold Volume Up + Volume Down + Power
• Use the volume button to scroll through the menu options and press power to select "Recovery Mode"
• Once the Recovery Mode screen has come up (green android with red warning sign), press  Power + Volume Up to bring up the menu
4. Install the update from the /cache folder
• Use the Volume button to select the "apply update from /cache" menu option and press power to invoke it
• Use the Volume button to select 24a9a760f32e.signed-yakju-JZO54K-from-JRO03C.24a9a760.zip and press the power button to start the update
• Once the install is complete, select "reboot system now"

Warning: The last upgrade caused me to lose root access. Apparently the setuid bit was removed from /system/bin/su.  To prevent this you can try a proactive approach by using an app like OTA RootKeeper or see my previous for details on how to restore root access.

Discalimer:

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!

How to manually "OTA" update your Galaxy Nexus from 4.0.4 to Android 4.1.1 (Jelly Bean) in 4 easy steps

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.

Preconditions:

1. You have a GSM Galaxy Nexus (i9250)
2. You are currently running the latest Android 4.0.4 (IMM76I)
3. You have the stock takju (update: or yakju)  ROM.  (You can use this app to check)
4. You have root access (su/super user is installed) 
5. You have a terminal application installed (e.g. Android Terminal Emulator)
6. You *have not* replaced the stock recovery system/partition with a custom recovery (like Clockwork Mod)
7. You have 15 - 20 minutes to spare

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

Steps:

1. Download the takju 4.1.1 (JRO03C) from 4.0.4 (IMM76I) OTA update file directly to your phone (you are downloading directly from Google, not from this blog).  The file is about 147MB so you may want to do the download over wifi.  Update: The yakju OTA file is now available as well, the steps are basically the same, you just use the yakju 4.1.1 (JRO03C) from 4.0.4 (IMM76I) OTA file instead.
2. Copy the update file to the /cache folder (this requires super user permission)
• Open a terminal window
• su
• cp /sdcard/Download/5c416e9cf57f.signed-takju-JRO03C-from-IMM76I.5c416e9c.zip /cache/
3. Boot into recovery mode
• Power off your phone
• While the phone is off, press and hold Volume Up + Volume Down + Power
• Use the volume button to scroll through the menu options and press power to select "Recovery Mode"
• Once the Recovery Mode screen has come up (green android with red warning sign), press  Power + Volume Up to bring up the menu
4. Install the update from the /cache folder
• Use the Volume button to select the "apply update from /cache" menu option and press power to invoke it
• Use the Volume button to select  5c416e9cf57f.signed-takju-JRO03C-from-IMM76I.5c416e9c.zip and press the power button to start the update
• Once the install is complete, select "reboot system now"

Warning: The upgrade caused me to lose root access. Apparently the setuid bit was removed from /system/bin/su.  This was fixed by doing the following. It assumes you are familiar with adb, fastboot and Clockwork Mod Recovery. See my previous for details on how to restore root access.

Discalimer:

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!

How to view the browser history in Chrome for Android

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.

Source: http://code.google.com/p/chromium/issues/detail?id=114066

How to restore root access after upgrading from Android 4.0.2 to 4.0.4

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.

1. Power off your phone and boot to the bootloader
• Volume Up + Volume Down + Power
2. Temporarily boot into the Clockwork Mod Reovery using fastboot (on the computer) 
• fastboot boot cwmt-recovery-5.8.0.2.maguro.img (or whatever version you are using)
3. Mount /system using Clockwork Mod (on the phone): 
• mounts and storage -> mount /system
4. Chmod su using adb to turn on the setuid bit (on the computer)
• adb shell chmod 6755 /system/bin/su
• adb shell chown root:root  /system/bin/su
• adb shell ls -l /system/bin/su (permissions should now be -rwsr-xr-x)
5. Reboot. Super user should be working as expected (and your stock recovery is still intact)

How to manually upgrade your Galaxy Nexus to Android 4.0.4 (OTA) in 4 easy steps

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.

Preconditions:

1. You have a GSM Galaxy Nexus (i9250)
2. You are currently running Android 4.0.2 (ICL53F)
3. You have the stock yakju ROM (How to tell)
4. Your bootloader is unlocked
5. You have root access (su/super user is installed) 
6. You have a terminal application installed (e.g. Android Terminal Emulator)
7. You *have not* replaced the stock recovery system/partition with a custom recovery (like Clockwork Mod)
8. You have 15 - 20 minutes to spare

Steps:

1. Download the OTA update file for Android 4.0.2 (ICL53F) -> 4.0.4 (IMM76D) directly to your phone (you are downloading directly from Google, not from this blog).  The file is about 40MB so you may want to do the download over wifi.
2. Copy the update file to the /cache folder (this requires super user permission)
• Open a terminal window
• su
• cp /sdcard/Download/7f97fbc19417.signed-yakju-IMM76D-from-ICL53F.7f97fbc1e.zip /cache/
3. Boot into recovery mode
• Power off your phone
• While the phone is off, press and hold Volume Up + Volume Down + Power
• Use the volume button to scroll through the menu options and press power to select "Recovery Mode"
• Once the Recovery Mode screen has come up (green android with red warning sign), press Volume Up + Power to bring up the menu
4. Install the update from the /cache folder
• Use the Volume button to select the "apply update from /cache" menu option and press power to invoke it
• Use the Volume button to select  7f97fbc19417.signed-yakju-IMM76D-from-ICL53F.7f97fbc1e.zip and press the power button to start the update
• Once the install is complete, select "reboot system now"

Warning: The upgrade caused me to lose root access. Apparently the setuid bit was removed from /system/bin/su.  This was fixed by doing the following. It assumes you are familiar with adb, fastboot and Clockwork Mod Recovery. See my next post for details on how to restore root access.

Discalimer:

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!

Gavin King unveils Red Hat's Java killer successor: The Ceylon Project

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 QCon Beijing 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 slide decks, (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

1. The overall vision: learn from Java's mistakes, keep the good, ditch the bad
2. The focus on readability and ease of learning/use
3. Static Typing (find errors at compile time, not run time)
4. No “special” types, everything is an object
5. Named and Optional parameters (C# 4.0)
   
6. Nullable types (C# 2.0)
   
7. No need for explicit getter/setters until you are ready for them (C# 3.0)
8. Type inference via the "local" keyword (C# 3.0 "var")
9. Sequences (arrays) and their accompanying syntactic sugariness (C# 3.0)
10. Straight-forward implementation of higher-order functions

Things that may grow on me

1. The new assignment operator ":="
2. The new string interpolation syntax
3. The new types: Natural, Numeric, etc
4. Classes, Methods and Attributes looking almost identical...can't decide if that is good or bad
   

Things that make me go hmmm

1. All the new keywords for existing concepts: shared, satisfies, assign, variable, local
   
2. The simplification of the public/protected/private access/visibility levels
3. The Smalltalk-like syntax for inline functions as parameters

Things I didn't fully get

1. 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”)"
2. 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 Cylon Ceylon 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."

Update 2: InfoQ has posted an article which includes a Q&A with Gavin King.

Embedded slides courtesy of  devstonez

Introducing the Ceylon Project - Gavin King presentation at QCon Beijing 2011

View more presentations from devstonez

The Ceylon Type System - Gavin King presentation at QCon Beijing 2011

View more presentations from devstonez