Hosted Unifi controller with Let’s Encrypt SSL take 2!

Unifi Dashboard with SSL

I visited this idea months ago, but for anyone who implemented it, it has been a nightmare.  Each subsequent Unifi controller update broke the https in new and exciting ways.  After remaining a very squeaky wheel with Ubiquity support, they’ve pushed out a version that should permanently resolve the problems. They even made promises of native Let’s Encrypt support.  All this will prove true of false with time, but for now i wanted to share my working procedure for Unifi controller version 5.9.32.

This solution required me to become more familiar with Java’s keytool then i would have otherwise.  Unifi has a hardcoded keytool path and password, don’t change that (thanks Corey F @ubnt). i don’t think alias matter, but they must be consistent.  I used mykey.  We start by generating a key and a code signing request for our domain.  For permissions reasons, we will want to do this as root. . .
cd /var/lib/unifi
keytool -genkeypair -alias mykey -keyalg RSA -keysize 2048 -keystore keystore -dname "CN=custom.domain.name" -storepass aircontrolenterprise

Now we export the csr file we will give to Let’s Encrypt.
keytool -certreq -alias mykey -keystore keystore -file custom.domain.name.csr -ext san=dns:custom.domain.name -storepass aircontrolenterprise

Now we run the interactive certbot script to prove the domain is actually yours before they hand out a cert.  Follow the instructions you can use DNS or hosting a file to verify.
certbot certonly --manual --csr custom.domain.name.csr

Continue reading “Hosted Unifi controller with Let’s Encrypt SSL take 2!”

Hosted Unifi controller with Let’s Encrypt SSL!

Unifi controller with SSL from Let's Encrypt

UPDATE:  this is all outdated, go here.

I have been consolidating some of my sites onto a single hosted Unifi controller.  Documentation was outdated so I am going to post some useful info here. My original plan was to setup a basic apache2 site, use certbot to generate my certificates and then install them into the Unifi controller. The first frustration is that you cannot simply install the certs you want into the unifi controller.  second frustration, java.  once you get over that, it’s super easy.

I had some issues with the initial migration.  i ended up having to start over.  handy command to remove unifi controller with all it’s configuration and data. apt-get remove unifi --purge Just remember, you will need to reinstall Unifi after. It will be bran new and back to the wizard.

Getting started with SSL, I learned mostly from here.  First create a CSR with unifi through command line…
cd /usr/lib/unifi
java -jar lib/ace.jar new_cert <hostname> <company> <city> <state> <country>

this creates unifi_certificate.csr.der and unifi_certificate.csr.pem inside the data directory where you already are (/usr/lib/unifi/).  Now we need to feed the CSR into certbot.  Note that at this point,  i already have apache2 installed with a very simple virutalhost and site setup with the domain i am creating a cert for.  Here is the command to feed the CSR generated by Unifi into certbot to be certified:
certbot certonly --apache --csr /usr/lib/unifi/data/unifi_certificate.csr.der

Certbot will make sure that domain is yours (and your apache config is working) and then output a signed cert and a chain that is almost everything you need to install the certificate back into the Unifi controller.  Still in /usr/lib/unifi/data/ 0000_cert.pem is my signed cert and 0001_chain.pem is my signed cert plus the intermediate certificate. what’s missing is Let’s Encrypt’s Root certificate to validate the intermediate certificate and thus complete the chain of trust.

Continue reading “Hosted Unifi controller with Let’s Encrypt SSL!”

SSL problem, it wasn’t me!

broken keyI just assumed that the problem was related to my recent SSL renewal.  Turns out, Google security recently published Distrusting WoSign and StartCom Certificates and removed them from chrome.  How did I miss this?  It turns out that the SSL on my site has been broken on Chrome for some time.  It must be that I have been using Brave recently as my daily browser.  I moved this site to letsencrypt.org and it’s working fine for everyone now.  I don’t even know how much time I waisted on this one.  wow.

Something is getting better!

https lock iconMy blog is now distributed with Amazon’s Cloudfront CDN using powerful encryption and signed by a proper CA certificate.  See the shiny green lock?  Like a grown-up adult website.  After only 8.5 years.  Congratulations!  Thank you StartSSL!

Update:  you may have noticed that the transition has been a bit bumpy.  Still getting the hang of things and this website needs a lot of work (possibly a complete resurfacing).  I am sorry about the downtime and all the SSL errors, I am working on it.  Thanks Eric, I hope I didn’t step on your birthday plans kidnapping your brain. 

Apple’s goto fail bug and what it means to you?

Apple goto fail SSL bugThe security community went into a frenzy this weekend over Apple’s latest iOS security update. On Friday, Apple quietly released iOS 7.0.6 and 6.1.6 to patch a bug in its SSL implementation. This particular bug nicknamed “goto fail” for the actual contents of its source code behind the error.  Basically, one too many goto fail causes the fail not to be conditional, but absolute.  This failure allows Apple’s SSL framework (the technology that secures web transmissions) to be easily bypassed.  In other words, Safari, Mail, Calendar, Software Update, as well as any 3rd party applications who take advantage of Apple’s SSL libraries could potentially have their communications intercepted by an unscrupulous individual.  Apple claims that it is a type-o, but many wonder if this might be a deliberate backdoor (one that has lasted over a year).

The real tragedy of this issue is that it effects Mavericks (Mac OS 10.9.x) as well as iOS, but there is yet no official fix for Apple Computers.  Update Published by Apple!  Apple desktops, laptops, and iMacs are now were left in a very dangerous position: unprotected to a known threat.  I am sure that the bad guys are already configuring their sslstip, sslsniff, or similar tools.  Accounts will be compromised, communications will be intercepted or manipulated, or in the case of software updates, malware could even be introduced.

What can we do?  First off, run the 7.0.6 update on any iOS devices not yet up to date.  Do this from a trusted wifi, not a public one.  With your mac, avoid public wifi until this is resolved.  Avoid Apple Mail except when absolutely necessary and only from trusted networks.  Only use Google Chrome for secure web browsing (it uses its own SSL framework).  Optional:  Install @i0n1c’s binary patch.  @i0n1c’s patch fixes the bug, but may break other things.  Run Apple 10.9.2 update!

links:
Test your system:  https://gotofail.com/
Great Writeup:  https://www.imperialviolet.org/2014/02/22/applebug.html
Quick & Dirty Patch:  http://www.sektioneins.de/en/blog/14-02-22-Apple-SSL-BUG.html
Official Apple Fix  http://support.apple.com/kb/HT6150

Updates keep the SSL boogiemen at bay.

all the ssl blacklists are updates. we can return to thinking we are safe. Apple included the patches in a Security Update, Firefox updated to 6.0.2. Jailbroken iOS users can update or install “sslfix” in Cydia to get the protections that apple has yet to release.

After watching Moxie’s BlackHat talk, we seriously need to fix SSL. It is holding up too many technologies to be this insecure.

More Certificate Authority Problems!

In the mist of  #antisec and on the heels of the Vegas Hacker/Security conferences, another CA (DigiNotar) was hacked.  This time the hackers got Google’s security certificates.   With that criminals could use a technique known as a Man in the Middle attack to impersonate google and nothing can stop them.  Personally i have heard @ioerror rant about the fundamental flaws of our present SSL system.  Perhaps this will help bring about a change more quickly but for now we can blacklist the offending certificates.  here is how (on a mac)

To protect Safari, the solution is, apparently, to run Applications/Utilities/Keychain Access, click on “System Root” on the upper-left, and “All items” on the lower-left, then type “DigiNotar” into the upper-right searchbox, then doubleclick on all the certs that show up (you may only have one), open the “Trust” detail area, and change “When using this certificate” to “Never Trust”, then close the dialog box.

For Firefox users, go to Firefox’s Preferences, click on Advanced, then the Encryption tab, then click on “View Certificates”, click on the “Authorities” tab, scroll down to DigiNotar, click on “DigiNotar Root or CA”, then click on “Delete…” or “Delete or Distrust…” below (depends on your version).

Read more here:
http://www.computerworld.com/s/article/9219606/Hackers_stole_Google_SSL_certificate_Dutch_firm_admits?taxonomyId=85