🏙️ Systemadministrator & IT Infrastructure Engineer aus 🪐 🌍 🇺🇳 🇪🇺 🇦🇹 :wien: :ottakring: :neulerchenfeld:

💻 Arbeitsfeld: Linux · Unix · Open Source — proprietärer Mist ist nicht willkommen

🧭 Einordnung: streng links :antifa: antifaschistisch · allergisch gegen rechte Normalisierung und Autoritarismus

😏 Privat: trockener Zynismus vor Sympathie · direkte Sprache · wenig Theater

🌐 Drei Welten:
· #AWiT https://awit.at/
· #FEROX https://ferox.cc/
· #AWsite https://weindl.biz/

⚠️ Willst du mehr wissen?
Besuche meine anderen Online-Präsenzen oder… einfach nur: Trööt! 😉

  • 0 Posts
  • 2 Comments
Joined 7 months ago
cake
Cake day: January 11th, 2026

help-circle
  • @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.