Securing HomeAssistant with client certificates (works with Safari/iOS)

chris April 30, 2017September 30, 2019 31 Comments

I recently moved from SmartThings to HomeAssistant. One of the things I didn’t have to think about too much with SmartThings was how to authenticate all of my connected devices (laptops, phones, tablets, etc.) with my HA platform. I wanted to find a good balance between security and convenience with HomeAssistant.

HomeAssistant makes it easy to secure your install with a password. Coupled with TLS, this is pretty solid. But there’s just something about the idea of a publically facing page that anyone on the Internet can get to, protected with nothing but a password that made me feel uneasy.

Client certificates are a very robust authentication mechanism that involves installing a digital certificate on each device you wish to grant access to. Each certificate is signed by the server certificate, which is how the server knows that the client is valid.

This feels nicer than HomeAssistant’s built-in security measures to me for a few reasons:

Individual client certificates can be revoked. You don’t have to configure authentication on every device you own if someone loses their phone.
While I highly doubt there are any issues with HomeAssistant, I feel more confident in nginx and openssl.
Unless you add a passphrase to the client certificates (I didn’t), the whole thing is passwordless and still manages to be pretty darn secure.
If I ever became truly paranoid, I could turn on HomeAssistant’s password protection and my HA dashboard would essentially need two authentication factors (the SSL cert + the password).

While I did find this approach more appealing, there are several drawbacks:

It’s way harder to set up. You need to run a bunch of openssl commands, and install a certificate on each device you want to grant access to.
The HomeAssistant web UI requires WebSockets, which seem to not play nicely in combination with client certificates on Safari or iOS devices. My household has iOS users, so this was something I needed to figure out.

I think I managed to get this working. The only disadvantage is that clients are granted access for an hour after successfully authenticating once. The basic approach is to tag authenticated browsers with an access token that’s good for a short period of time, long enough for them to establish a WebSocket connection. I’ll go through the steps in setting this up.

What you need

Install packages: sudo apt-get install nginx nginx-extras lua5.1 liblua5.1-dev
openssl
luacrypto module, which exposes openssl bindings in lua.

luacrypto was kind of a pain to install. Here’s what I did to get it working with my nginx install. It involved patching configure.ac (thanks to this very helpful StackOverflow post for the tip):

git clone https://github.com/mkottman/luacrypto /opt/luacrypto \
  && cd /opt/luacrypto \
  &&
     # Fix package names for compatibility with Ubuntu
     echo 'diff --git a/configure.ac b/configure.ac
index b6b9175..20ea20c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,10 +28,10 @@ AC_CHECK_FUNCS([memset])

 # pkgconfig
 PKG_CHECK_MODULES([OPENSSL], [openssl])
-PKG_CHECK_MODULES([LUA], [lua])
+PKG_CHECK_MODULES([LUA], [lua5.1])

 # lua libdir
-LUALIBDIR="`$PKGCONFIG --variable=libdir lua`"
+LUALIBDIR="`$PKGCONFIG --variable=libdir lua5.1`"

 # dest of headers
 CRYPTOINC="${includedir}/${PACKAGE_NAME}"' \
  | git apply \
  && autoreconf -i \
  && ./configure \
  && make \
  && sudo mkdir -p /usr/local/lib/lua/5.1 \
  && sudo cp src/.libs/crypto.so /usr/local/lib/lua/5.1/crypto.so

git clone https://github.com/mkottman/luacrypto /opt/luacrypto \

&& cd /opt/luacrypto \

# Fix package names for compatibility with Ubuntu

echo 'diff --git a/configure.ac b/configure.ac

index b6b9175..20ea20c 100644

--- a/configure.ac

+++ b/configure.ac

@@ -28,10 +28,10 @@ AC_CHECK_FUNCS([memset])

# pkgconfig

PKG_CHECK_MODULES([OPENSSL], [openssl])

-PKG_CHECK_MODULES([LUA], [lua])

+PKG_CHECK_MODULES([LUA], [lua5.1])

# lua libdir

-LUALIBDIR="`$PKGCONFIG --variable=libdir lua`"

+LUALIBDIR="`$PKGCONFIG --variable=libdir lua5.1`"

# dest of headers

CRYPTOINC="${includedir}/${PACKAGE_NAME}"' \

| git apply \

&& autoreconf -i \

&& ./configure \

&& make \

&& sudo mkdir -p /usr/local/lib/lua/5.1 \

&& sudo cp src/.libs/crypto.so /usr/local/lib/lua/5.1/crypto.so

Setting up a Certificate Authority

There are already good guides on doing this. I recommend this one. In this guide, I’m using the default_CA parameters pre-filled by openssl on my system.

Generate client certificates

I put a script in /usr/local/bin to make this easier:

$ cat `which create-client-ssl-cert`
#!/bin/bash

function usage () {
  echo "$0 [CA section name] [username]"
  exit 1
}

if [ $# -ne 2 ]
then
  usage
fi

CA_NAME="$1"
USERNAME="$2"

SSL_DIR="/etc/ssl"
SSL_PRIVATE_DIR="$SSL_DIR/${CA_NAME}/private"
SSL_CERTS_DIR="$SSL_DIR/${CA_NAME}/certs"
USERS_DIR="${SSL_CERTS_DIR}/users"

mkdir -p ${USERS_DIR}

if [ -f "${USERS_DIR}/${USERNAME}.key" ]; then
  echo "Key for $USERNAME already exists! Delete it to continue."
  exit 1
fi

# Create the Client Key and CSR
openssl genrsa -des3 -out ${USERS_DIR}/${USERNAME}.key 1024
openssl req -new -key ${USERS_DIR}/${USERNAME}.key -out ${USERS_DIR}/${USERNAME}.csr

# Sign the client certificate with our CA cert.  Unlike signing our own server cert, this is what we want to do.
openssl x509 -req -days 1095 -in ${USERS_DIR}/${USERNAME}.csr -CA $SSL_CERTS_DIR/ca.crt -CAkey $SSL_PRIVATE_DIR/ca.key -CAserial $SSL_DIR/${CA_NAME}/serial -CAcreateserial -out ${USERS_DIR}/${USERNAME}.crt

echo "making p12 file"
#browsers need P12s (contain key and cert)
openssl pkcs12 -export -clcerts -in ${USERS_DIR}/${USERNAME}.crt -inkey ${USERS_DIR}/${USERNAME}.key -out ${USERS_DIR}/${USERNAME}.p12

echo "made ${USERS_DIR}/${USERNAME}.p12"

$ cat `which create-client-ssl-cert`

#!/bin/bash

function usage () {

echo "$0 [CA section name] [username]"

exit 1

}

if [ $# -ne 2 ]

then

usage

CA_NAME="$1"

USERNAME="$2"

SSL_DIR="/etc/ssl"

SSL_PRIVATE_DIR="$SSL_DIR/${CA_NAME}/private"

SSL_CERTS_DIR="$SSL_DIR/${CA_NAME}/certs"

USERS_DIR="${SSL_CERTS_DIR}/users"

mkdir -p ${USERS_DIR}

if [ -f "${USERS_DIR}/${USERNAME}.key" ]; then

echo "Key for $USERNAME already exists! Delete it to continue."

exit 1

# Create the Client Key and CSR

openssl genrsa -des3 -out ${USERS_DIR}/${USERNAME}.key 1024

openssl req -new -key ${USERS_DIR}/${USERNAME}.key -out ${USERS_DIR}/${USERNAME}.csr

# Sign the client certificate with our CA cert. Unlike signing our own server cert, this is what we want to do.

openssl x509 -req -days 1095 -in ${USERS_DIR}/${USERNAME}.csr -CA $SSL_CERTS_DIR/ca.crt -CAkey $SSL_PRIVATE_DIR/ca.key -CAserial $SSL_DIR/${CA_NAME}/serial -CAcreateserial -out ${USERS_DIR}/${USERNAME}.crt

echo "making p12 file"

#browsers need P12s (contain key and cert)

openssl pkcs12 -export -clcerts -in ${USERS_DIR}/${USERNAME}.crt -inkey ${USERS_DIR}/${USERNAME}.key -out ${USERS_DIR}/${USERNAME}.p12

echo "made ${USERS_DIR}/${USERNAME}.p12"

You then run this for each device you want to grant access to:

# create-client-ssl-cert ca chris_pixel

1	# create-client-ssl-cert ca chris_pixel

Make sure to supply an export password. Generated certificate files will be placed in /etc/ssl/ca/certs/users .

Get the certificates on the devices

The .p12 file is the one you want. Make sure to not compromise the certificates in the process.

I rsynced the files to my laptop and attached them to a LastPass note, which I could access on my devices. On most devices, you should be able to just open the .p12 file and it’ll do what you want.

On iOS devices, I needed to serve the certificates over HTTPS on a trusted network because they needed to be “opened” by Safari in order to be recognized.

Configure nginx

Here’s my nginx config. You’ll need to substitute your domain and SSL certificate parameters:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream hass_backend {
  server 127.0.0.1:8123;
}


server {
  listen 80;
  listen 81;
  server_name my-homeassistant-install.mydomain.com;
  return 301 https://$host$request_uri;
}

server {
  listen      443 ssl;
  server_name my-homeassistant-install.mydomain.com;

  error_log  /var/log/nginx/my-homeassistant-install.mydomain.com/error.log;
  access_log /var/log/nginx/my-homeassistant-install.mydomain.com/access.log;

  ssl_certificate     /etc/letsencrypt/live/my-homeassistant-install.mydomain.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/my-homeassistant-install.mydomain.com/privkey.pem;
  ssl_dhparam         /etc/nginx/ssl/dhparams.pem;
  ssl on;

  add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;

  ssl_client_certificate /etc/ssl/ca/certs/ca.crt;
  ssl_crl                /etc/ssl/ca/private/ca.crl;
  ssl_verify_client      optional;

  proxy_buffering off;
  proxy_redirect http:// https://;
  proxy_set_header        X-Real-IP $remote_addr;
  proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header        X-Forwarded-Proto $scheme;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
  proxy_set_header Host $host;

  location / {
    #access_by_lua_file /etc/nginx/scripts/hass_access.lua;
    proxy_pass  http://hass_backend;
  }
}

map $http_upgrade $connection_upgrade {

default upgrade;

'' close;

}

upstream hass_backend {

server 127.0.0.1:8123;

}

server {

listen 80;

listen 81;

server_name my-homeassistant-install.mydomain.com;

return 301 https://$host$request_uri;

}

server {

listen 443 ssl;

server_name my-homeassistant-install.mydomain.com;

error_log /var/log/nginx/my-homeassistant-install.mydomain.com/error.log;

access_log /var/log/nginx/my-homeassistant-install.mydomain.com/access.log;

ssl_certificate /etc/letsencrypt/live/my-homeassistant-install.mydomain.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/my-homeassistant-install.mydomain.com/privkey.pem;

ssl_dhparam /etc/nginx/ssl/dhparams.pem;

ssl on;

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:10m;

ssl_client_certificate /etc/ssl/ca/certs/ca.crt;

ssl_crl /etc/ssl/ca/private/ca.crl;

ssl_verify_client optional;

proxy_buffering off;

proxy_redirect http:// https://;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection $connection_upgrade;

proxy_set_header Host $host;

location / {

#access_by_lua_file /etc/nginx/scripts/hass_access.lua;

proxy_pass http://hass_backend;

}

If this all worked, you should be able to access my-homeassistant-install.mydomain.com from a device with a client certificate installed, but not otherwise. Unfortunately if you’re using iOS or Safari, you’ll probably notice that the page loads, but you get a forever spinny wheel. If you look in the debugger console, you might see messages that look like this:

[Error] WebSocket connection to 'wss://my-homeassistant-install.mydomain.com/api/websocket' failed: Unexpected response code: 400 (x11)

1	[Error] WebSocket connection to 'wss://my-homeassistant-install.mydomain.com/api/websocket' failed: Unexpected response code: 400 (x11)

This is because the browser isn’t sending the client certificate information when trying to connect to the WebSocket and is therefore failing.

Fixing compatibility with iOS/Safari

Safari does actually send client cert info along with the initial request. Nginx has a really cool module that allows you to insert all sorts of fancy logic with lua scripts. I added one that tags browsers supplying a valid client certificate with a cookie granting access for about an hour. This worked really well. Since this is all over HTTPS, and the access tokens are short-lived, I felt pretty comfortable.

The easiest way I could think of to create a cookie that was valid for a limited time was to use an HMAC. Basically I “sign” a hash of the client’s certificate along with an expiry timestamp. The certificate hash, expiration timestamp, and HMAC are all stored in cookies. Nginx can then validate that the expiration timestamp is in the future, and that the HMAC signature matches what’s expected.

You’ll notice the commented-out line in the nginx config above. Uncomment it:

access_by_lua_file /etc/nginx/scripts/hass_access.lua;

1	access_by_lua_file /etc/nginx/scripts/hass_access.lua;

And add the script:

local HMAC_SECRET = "hunter2"
local crypto = require "crypto"

function ComputeHmac(msg, expires)
  return crypto.hmac.digest("sha256", string.format("%s%d", msg, expires), HMAC_SECRET)
end

verify_status = ngx.var.ssl_client_verify

if verify_status == "SUCCESS" then
  client = crypto.digest("sha256", ngx.var.ssl_client_cert)
  expires = ngx.time() + 3600

  ngx.header["Set-Cookie"] = {
    string.format("AccessToken=%s; path=/", ComputeHmac(client, expires)),
    string.format("ClientId=%s; path=/", client),
    string.format("AccessExpires=%d; path=/", expires)
  }
  return
elseif verify_status == "NONE" then
  client = ngx.var.cookie_ClientId
  client_hmac = ngx.var.cookie_AccessToken
  access_expires = ngx.var.cookie_AccessExpires

  if client ~= nil and client_hmac ~= nil and access_expires ~= nil then
    hmac = ComputeHmac(client, access_expires)

    if hmac ~= "" and hmac == client_hmac and tonumber(access_expires) > ngx.time() then
      return
    end
  end
end

ngx.exit(ngx.HTTP_FORBIDDEN)

local HMAC_SECRET = "hunter2"

local crypto = require "crypto"

function ComputeHmac(msg, expires)

return crypto.hmac.digest("sha256", string.format("%s%d", msg, expires), HMAC_SECRET)

end

verify_status = ngx.var.ssl_client_verify

if verify_status == "SUCCESS" then

client = crypto.digest("sha256", ngx.var.ssl_client_cert)

expires = ngx.time() + 3600

ngx.header["Set-Cookie"] = {

string.format("AccessToken=%s; path=/", ComputeHmac(client, expires)),

string.format("ClientId=%s; path=/", client),

string.format("AccessExpires=%d; path=/", expires)

}

return

elseif verify_status == "NONE" then

client = ngx.var.cookie_ClientId

client_hmac = ngx.var.cookie_AccessToken

access_expires = ngx.var.cookie_AccessExpires

if client ~= nil and client_hmac ~= nil and access_expires ~= nil then

hmac = ComputeHmac(client, access_expires)

if hmac ~= "" and hmac == client_hmac and tonumber(access_expires) > ngx.time() then

return

end

ngx.exit(ngx.HTTP_FORBIDDEN)

Update (August, 2019)

After upgrading to Ubuntu 18.04, the nginx LUA module stopped working, and every combination of fixes I tried didn’t work.

Fortunately, OpenResty worked out of the box. After adding their PPA and installing it, all of my existing scripts worked. I just copied over my entire nginx config.

Join the Conversation

31 Comments

Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

elratt0r says:

May 31, 2019 at 5:55 am

Thanks for this great post!
Because luacrypt won’t compile anymore I rewrote your script for luaossl.
(lua-luaossl on debian)

Here as a gist:
https://gist.github.com/elratt0r/e059aeed5eff5d8a2dab2bfcd1a56728

Reply
Anonymous says:

December 4, 2018 at 2:04 pm

I’ d like to be able to both reach the default hass webinterface securely via client certificates, and use the Google Assistant plugin.

Would it be possible to tweak nginx to allow for this? Or any other method?

Thanks a lot for your advice.

Reply
1. chris says:
  
  December 4, 2018 at 3:10 pm
  
  I’m not familiar with the Google Assistant plugin. If it provides some form of auth, it’s possible to mess around with the LUA to detect either that or the client cert.
Pingback: Single Sign On with client certificates | Chris Mullins
Andy says:

July 21, 2018 at 7:35 am

I’ve tried a ton of different things to get luacrypto running, even tried other openssl packages, etc. This was the only way I got it working with lua 5.1..:

git clone https://github.com/evanlabs/luacrypto.git
luarocks install rockspecs/luacrypto-git-1.rockspec
ln -s /usr/local/lib/lua/crypto.so /usr/local/lib/lua/5.1

Reply
1. chris says:
  
  July 21, 2018 at 8:31 pm
  
  Did the trick I mentioned in the post with patching configure.ac not work for you? Sort of sounds like what you’re suggesting would have roughly the same effect.
2. Andy says:
  
  July 23, 2018 at 4:57 am
  
  The code above is a bit of a mess 😉 I’ve changed both lua entries in the configure.ac to lua5.1
  So far so good, right?
  
  After that I did the autoreconf, stopping with this error:
  /usr/share/automake-1.15/am/ltlibrary.am: warning: ‘crypto.la’: linking libtool libraries using a non-POSIX
  /usr/share/automake-1.15/am/ltlibrary.am: archiver requires ‘AM_PROG_AR’ in ‘configure.ac’
  
  So I’ve added this line to configure.ac before LT_INIT:
  m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
  
  Everything seemed to work fine then. Could run configure but make fails.
  lcrypto.c:1602:20: error: storage size of ‘ctx’ isn’t known
  Error 2 and so on.
Tor Arne says:

July 10, 2018 at 10:41 am

With the broken pkcs12 conversion fixed as described in https://blog.christophermullins.com/2017/04/30/securing-homeassistant-with-client-certificates/comment-page-1/#comment-4778, I can now successfully make the initial connection to HA using Safari on both iOS and macOS, BUT they both stop at loading the main UI with the Safari web inspector reporting: WebSocket connection to 'wss:///api/websocket?latest' failed: Unexpected response code: 403. Seems the Safari/WebKit bug still hasn’t had any love: https://bugs.webkit.org/show_bug.cgi?id=158345

I could work around this using the lua script, but I noticed the HA iOS app doesn’t even show the HA loading UI, just the ngninx 403 forbidden page, so apparently it doesn’t even send the client cert for the normal HTTP requests 🙁

Did anyone solve the latter part?

Reply
1. chris says:
  
  July 10, 2018 at 10:45 am
  
  Yeah, the entire point of this post is the Lua workaround. Websockets in both Chrome and Safari just do not play nicely with client certificates.
  
  I don’t think the iOS app supports using client certificates, but I don’t use the iOS app. Just use a homepage link which works fine for my purposes.
2. Tor Arne says:
  
  July 10, 2018 at 2:01 pm
  
  Actually Websockets in Chrome (68.0.3440.42 on macOS) work fine without the Lua workaround, but yes, it’s needed for Safari (and Chrome on iOS, which is just wrapping the WebKit engine and networking backend, so it has the same issues as Safari).
  
  The advantage of the iOS app is that it supports location updates for presence detection. According to this tech note (https://developer.apple.com/library/archive/qa/qa1745/_index.html) the UIWebView used by the iOS app does not inherit the keys added to the Safari keychain, but it should be possible to add the client certs to the HA iOS app itself. I’ll have a look at implementing that.
3. chris says:
  
  July 21, 2018 at 8:34 pm
  
  Er, yeah. Sorry. I guess I probably meant service worker. Or some other similar frontend thing. There’s definitely something in either Chrome or HomeAssistant that does not work well with client certs for long periods of time.
  
  I actually sort of gave up on using client certs for every request. Doubled down on the HMAC cookies, and now redirect to a domain that drops authed cookies based on client certs when cookies are not present.
  
  Works absolutely beautifully — exactly how I wanted.
  
  This makes sense, I would want to use the native app if I were using this feature as well.
Tor Arne says:

July 10, 2018 at 7:10 am

Any tips on how to get the client certificate working on macOS and iOS? I’ve installed the PKCS #12 file in the Keychain on macOS, and onto the iOS device, but Safari doesn’t seem to pass the certificate on, even with ssl_verify_client on;. Nor does Chrome on macOS, probably because it uses the Keychain certs as well. In Firefox there’s a separate preference to add “personal certificates”, and after adding the p12 file there, things work fine in Firefox. I can also load the page with curl from the macOS machine if I pass the key, cert, and cacert arguments.

Do you need to do something extra after importing the p12 onto the iOS device? Does the CA root certificate also need to be added, or trusted? (I thought that was part of the p12 file).

Does the name, organisation, city, etc, in the certs (CA or client, or both) need to match the server cert (from LetsEncrypt in my case) or something along those lines?

Reply
1. Tor Arne Vestbø says:
  
  July 10, 2018 at 8:45 am
  
  Aparently, the command in your script:
  
  openssl pkcs12 -export -clcerts -in ${USERS_DIR}/${USERNAME}.crt -inkey ${USERS_DIR}/${USERNAME}.key -out ${USERS_DIR
  
  and the one in e.g. https://gist.github.com/mtigas/952344:
  
  openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12
  
  does not match exactly the one I used, from https://fardog.io/blog/2017/12/30/client-side-certificate-authentication-with-nginx/:
  
  openssl pkcs12 -export -out user.pfx -inkey user.key -in user.crt -certfile ca.crt
  
  The certfile argument seems to mess things up, possibly because the ca.crt isn’t installed on iOS/macOS?
2. chris says:
  
  July 10, 2018 at 9:59 am
  
  I use this trick on OSX, Android, and iOS. Works really well for me.
  
  One of the fields you specify when generating the certificate has to match the domain you hit to access HomeAssistant (or whatever you’re securing). I think it’s probably the “Organization” field of the Subject Name. This supplies a hint to the OS that this certificate should be used when a client cert is requested by the server.
  
  In OS X there’s a concept of an “Identity Preference,” which you can set up in “Keychain Access.” (File > New Identity Preference…). I don’t think this is necessary if the certificate is configured correctly, but it might be a workaround if you don’t want to regenerate things.
Tor Arne says:

July 10, 2018 at 7:01 am

You’re setting ssl_verify_client optional;, but not verifying the $ssl_client_verify variable later on. From my testing and reading the docs, this means that if the browser doesn’t send a certificate, ngnix will happily serve the page. Is there something I’m missing? Shouldn’t this be ssl_verify_client on;, or if ($ssl_client_verify != SUCCESS) { return 403; }
?

Reply
1. Tor Arne says:
  
  July 10, 2018 at 7:03 am
  
  Never mind, I just realised you’re doing the $ssl_client_verify check in the lua script 🙂
2. chris says:
  
  July 10, 2018 at 9:51 am
  
  Yep, the whole trick here is to not enforce that the client supply a TLS certificate on every request, and provide a fallback authentication mechanism which is populated when the client does supply a certificate.
marcel says:

May 13, 2018 at 1:19 pm

Any idea how to get this working on a Synology DS1515+? There’s no lua or even make to compile lua installed.

Reply
1. chris says:
  
  May 18, 2018 at 9:58 am
  
  I have no experience with that system, but this particular technique definitely requires the Lua plugin.
dersimn says:

April 30, 2018 at 4:05 pm

I spent quite some time figuring out why your script wasn’t working properly. I always got errors like:

WebSocket network error: The operation couldn’t be completed. (OSStatus error -9807.)

The solution is quite “simple” tough.. iOS is much, much more picky about certificates and stuff than Safari on a Mac is.

On a Mac it seems to be enough to just install and trust the (self created) Root CA, but on iOS you really need the whole chain from Root CA -> Intermediate CA -> Website. If you’re testing this locally, you have actually to create a certificate with the Common Name 10.1.1.100 or whatever your local IP for testing is! Otherwise Safari will prompt you with something like »really open this website?«, then the website loads, you think »Everything is loading, so why is the web socket not working?«.

So, solution: Provide the whole chain of certificates via a Profile (create one with Apple Configurator 2), install it on your device and then explicitly trust the Root CA (because installing the Profile doesn’t trust the certificates yet).

Reply
1. chris says:
  
  May 1, 2018 at 12:05 am
  
  I didn’t need an intermediate certificate. But the CN in the cert is for the appropriate URL. I assume that’s necessary for Safari to know when it’s appropriate to use a particular certificate.
  
  I did need to trust the cert, though. On OS X I was able to do that in the keychain manager. On iOS opening the p12 lead to a series of prompts that resulted in the certificate being trusted, I think.
  
  The biggest problem I’ve run into that I’ve not exactly solved is that HomeAssistant started using ServiceWorkers about 6 months ago (I think?). It tries to download /service_worker.js every so often, and it Chrome doesn’t seem to support client certs in this context.
Tor Arne says:

January 10, 2018 at 3:43 pm

Is the iOS app using a WebView? If so it might perhaps share client certs with Safari. Perhaps the workaround using the lua script leaves any Safari-based WebView to access HA during the one hour window?

Reply
Nicola says:

August 24, 2017 at 2:38 pm

Hi Chris,

sounds good but unfortunately seems not to work as I would expect on my side.

I mean, setting ssl_verify_client as ‘optional’ I suspect client authentication is just skipped by nginx and in fact I am able to see HA page from iOS Safari even commenting out the lua script.

Instead forcing ssl_verify_client to ‘on’ I cannot access to that page even with the lua script enabled.

Any thoughts?

Nicola

Reply
1. chris says:
  
  August 25, 2017 at 9:42 pm
  
  The LUA script is what’s doing the enforcing. It enforces that either the browser provides client cert details, or that a valid auth cookie is in place. So having ssl_verify_client to optional while commenting out the LUA script should have the behavior you’re seeing.
  
  Having it set to “on” will force every request to provide client cert details, which is exactly what the LUA script is trying to get around.
2. Nicola says:
  
  August 26, 2017 at 6:30 am
  
  Got it,
  performing some further testing I confirm that it works as you are describing.
  
  Thank for sharing all this info and the script code!
3. chris says:
  
  August 26, 2017 at 10:55 am
  
  Awesome, glad it’s working!
Jimmy says:

June 19, 2017 at 7:23 pm

Does client certificate authentication work on iOS HomeAssistant app?

Reply
1. chris says:
  
  June 19, 2017 at 10:45 pm
  
  I’m not really familiar with the native iOS app. It’s not impossible that it works, but I sort of doubt it does.
2. Mal Curtis says:
  
  August 18, 2017 at 12:07 am
  
  So surprisingly this worked out of the box in the iOS app for me. In the recent iOS11 beta I’ve been having some issues, but I’m not sure if that’s specific to me upgrading the OS or the version of Caddy that I use (a replacement for nginx).
3. chris says:
  
  August 26, 2017 at 10:57 am
  
  You’re saying that client certs out of the box works with the HASS iOS app? The issue I observed was that Safari (OS X and iOS versions) didn’t send client cert details when making web socket requests, which I think would only be fixed by a software update on Apple’s side.
Larry says:

May 13, 2017 at 5:59 am

This was super-informative, and exactly what I was looking to do! Thanks for the great write up and step-by-step instructions. The worst part was luacrypto, but your patch even made that a breeze. Thanks again!

Reply