I use Tailscale for this, with my own Headscale server so that I am in control of everything. It’s a much easier approach that is more likely to pass the spousal acceptance factor.

MTLS is great protection, but the use case must support it. For example, if you want your app to support registration for new accounts or if you have a lot of people you want to have access, that might make mTLS unwieldy to manage.

I host apps behind Traefik reverse proxy, using the d.rymcg.tech framework. It make it easy to protect your apps behind HTTP basic auth, Oauth2, or mTLS(or any combination).

I use it for Home Assistant and ntfy in combination with Caddy. Certificates are managed by Vaultls (https://github.com/7ritn/VaulTLS) which makes it quite easy to setup and use on new devices.

@observantTrapezium

mTLS can be a very good extra gate for a small, controlled device set. But “some services”, “smartphones” and “Apache reverse proxy” is not enough to recommend it responsibly.

The decisive questions are:

• Which services are we talking about: a normal web UI in a mobile browser, native apps, APIs, WebDAV, SSH-like administration, something else?
• Are those personally managed devices, or devices belonging to multiple users?
• iOS, Android, both — and which browsers/apps?
• Is there MDM, or would certificate enrollment, replacement, revocation and renewal all be manual?
• What happens when a phone is lost, reset, sold, or its private key leaks?
• Does each device get its own certificate, or would the same .p12 be copied around? (Please do not do the latter.)
• Is the real goal “no public login page”, “device authentication”, or simply private remote access?

For a handful of your own devices, per-device mTLS certificates can be perfectly reasonable. For a mixed fleet of smartphones without MDM, the operational overhead is often the actual attack surface: secure initial delivery of the PKCS#12 bundle, private-key protection, expiration, rotation, revocation, backups, and users selecting the right certificate.

Also: mTLS is a gate, not a replacement for normal authentication and authorization. I would usually still keep the application login, use individual device certificates with a private CA, short-ish validity, documented revocation, and rate limits. Otherwise you have merely replaced password brute force with “whoever extracted or copied the client private key gets through.”

Depending on the service, a WireGuard/Tailscale-style private network or an identity-aware proxy may be less painful on phones — but that is impossible to judge without knowing the actual services and client workflow. Certificate-based mobile access is feasible, yet the setup and lifecycle vary materially across platforms and applications.

So yes: the missing basics are not a minor omission; they are the question.

It's very easy to make a custom CA and issue certs. Here's a good tutorial.

Unfortunately in practice It depends greatly on what's on the other side (the client app). Some examples:

• DAVx5 on Android works perfectly fine and uses the client cert from the system store. 10/10, this is how all apps should work.
• Ntfy on Android works perfectly fine but wants the client cert file loaded in the app, it doesn't use the one loaded in the system store. This sucks because instead of loading a cert into the system store once and then deleting it you have to keep the cert file around for this kind of apps, in Android shared storage, which is accessible to all apps.
• Same for Immich, wants the cert loaded in the app. Also, it will randomly lose it (on both iOS and Android). Yes, you heard that right. So it's basically useless and I had to resort instead to a key in a custom HTTP header; which isn't exactly the same as mTLS, but helps secure the service at reverse proxy level so it's better than nothing.
• Firefox on Android will use the cert from the system store, and then it will crash. Again, useless.

Oh did I mention how you get a mTLS client cert to an app on an iOS device? You send it over email to an account that the device has access to through the Mail app, then share the attachment. Yep.

It's also not exactly straightforward to use mTLS with reverse proxies.

Let's take for example Caddy and say you want unconditional mTLS for all reverse proxy hosts. Easy enough:

tls /path/to/domain-cert/fullchain.pem /path/to/domain-cert/privkey.pem {
  client_auth {
    mode required
    trust_pool file /path/to/custom/ca.pem
  }
}

But suppose you don't want unconditional mTLS, you'd like to let clients in if they have mTLS or a custom header, or do different things depending if the client has valid mTLS or not. Does Caddy offer a built-in conditional to act on mTLS status? Nope!

As a workaround I'm setting the client_auth mode to verify_if_given and then using a DIY conditional that checks if the variable http.request.tls.client.certificate_der_base64 is empty or not. But it's undocumented so who knows if it may break at any point.

For reference, how you handle both custom headers and mTLS at once (after setting the mode as I've mentioned):

@immich host "whatever.example.com"
handle @immich {
  @not_authorized {
    not header X-Custom-Pass "LONGRANDOMKEY01" # jim
    not header X-Custom-Pass "LONGRANDOMKEY02" # bob
    vars_regexp {http.request.tls.client.certificate_der_base64} ^$
  }
  error @not_authorized 403
  reverse_proxy http://immich.lan:port
}

The nested "not not" is required because Caddy can only do logical AND in group conditionals, so to do logical OR you basically have to do NOT (NOT a AND NOT b).

I use mTLS with Caddy to expose some of my services. It is quite manageable, and I only use if for myself and my wife.

We both use Android phones, and I configure access via apps for the services, that use the devices' certificate store. It seems like the iOS way is to provide the client certificate and password to each app that's gonna use it. I'm happy we can avoid that.

Big plus side for us is the simplicity of it all, there is no "always on VPN" requirement, and things "just work" with acceptable security.

I also sometimes access the services via Firefox, which is also able to use the device's certificate store, although I have to keep selecting the same certificate each time.

It can be a pain to manage but it works well once it is setup

Just make sure it isn't your only line of defense

I am using mTLS implemented by nginx to access my services like Home Assistant, Paperless, Tandoor, Immich and so on. Clients are Windows, Linux and Android based so no iOS experience. Adding new clients can be tricky if you need to figure out how to provide the certificate first. Once it works, it's rock solid

I have been thinking about it until I realize that nginx still can have zero days vulnerabilities that could be even in the tls layer or so and decided to actually close the port completely in the Firewall and just run Wireguard on devices. And as fallback I have external program that have a webbserver with qr code with link and ip query encrypted so when i scan it on smartphone i have to follow the link to internal server that i only can access with Wireguard so then only that public ip is then added to my Firewall rules temporary.

It's a good option if you can't do anything better, like a VPN. Because there is always the risk of an authentication bypass vulnerability. The less attack surface, the better.