TLS inspection
Please add medjot.app and *.medjot.app to your do-not-decrypt list.
This is the single most common cause of MedJot failing on a managed network.
What happens
Where a secure web gateway decrypts and re-signs traffic to medjot.app, devices receive a certificate minted by your inspection appliance rather than ours. If that appliance's root CA is not fully trusted on the device, the browser rejects the connection.
On .app domains this is a hard block
.app is an HSTS-preloaded top-level domain, enforced by every major browser. There is no "visit anyway" option — browsers do not offer one and cannot be persuaded to.
What the clinician sees instead is:
This Connection Is Not Private — this website may be impersonating medjot.app to steal your personal or financial information.
On a tool being used at a patient's side, that is a bad message to be wrong about. Neither the user nor we can work around it from the device; only the network policy can fix it.
The second, more confusing symptom
Because MedJot is an installed Progressive Web App, the cached interface may still open while every network request fails. The app then correctly reports itself as offline on a device that appears to have a working connection.
Users report this as "the app is broken" rather than "the network is blocking it", which is why it often reaches us before it reaches you.
What interception does and does not expose
We would rather be precise than reassuring, because this is the part that should decide your policy. Overstating it — "you are reading patient data" — would be untrue and would cost us credibility with anyone who checks.
It does not yield clinical content. There is none in transit. Patient findings, observations, the generated report and drafts are held in the device's own storage and are never uploaded. See Data flows.
It does expose authentication and refresh tokens, and all /api/* traffic, to the inspection infrastructure. Firebase refresh tokens are long-lived and are, in effect, an account-takeover surface on a clinical system.
That is the trade: inspecting MedJot gains you no clinical visibility, and places credentials for a clinical tool in front of an additional system and its logs. That is the whole of the argument for the exemption.
What we are asking for
Add to the do not decrypt / SSL bypass list:
medjot.app
*.medjot.app
No other change is required, and this does not prevent you from blocking, categorising or logging the domain as normal — only from decrypting it.
One wider point, respectfully
If MedJot fails this way on your network, SSL decryption is active without the inspection root CA being fully trusted on those endpoints.
If that is right, any inspected domain outside your vendor's default do-not-decrypt list will fail in exactly the same way. MedJot may be the first one reported to you rather than the only one affected — and on iOS in particular, installing the certificate is not sufficient; it must also be enabled under Settings → General → About → Certificate Trust Settings.
We raise it because it is usually cheaper to find out from us than from the next application.
Verifying our certificate
From outside your network, https://medjot.app presents a certificate with subject CN=medjot.app, issued by Let's Encrypt, chaining to ISRG Root X1.
If a device on your network sees any other issuer, that connection is being intercepted between the device and us.
We deliberately do not publish a certificate fingerprint. Our certificates rotate roughly every 60 days, and a stale fingerprint on a documentation page would cause more confusion than it prevents. The issuer is the reliable check.
Vendor-specific notes
Cisco Umbrella causes this most often and has its own page. The same principle applies to Zscaler, Netskope, Forcepoint, Palo Alto, Fortinet and any other gateway performing SSL decryption: the control you want is the do-not-decrypt exemption, however that vendor names it.
Talk to us
hello@swyftscale.com. We are happy to get on a call with whoever manages the policy if that is quicker.