INSECURE SSL is a switch on the FrontDesk kiosk app’s pairing screen, directly under the server address and device key. It decides how the kiosk judges your server’s security certificate - not whether the connection is encrypted.
The name oversells the danger, and understanding what it really does is the difference between a sensible deployment and a genuinely exposed one.
What the switch actually does
Switched off (the default). The kiosk checks your server’s certificate the way a browser does: it must be issued by a certificate authority the tablet trusts, it must not have expired, and the name on it must match the address you typed. A self-signed certificate, an expired one, or one issued for a different name is refused and pairing fails.
Switched on. The kiosk relaxes those checks at pairing, and instead locks onto the specific certificate your server presents:
- During pairing it connects to your server and accepts whatever certificate it is given, without checking the issuer, the expiry or the name.
- It takes a fingerprint of that certificate and stores it with the pairing.
- From then on, every request the kiosk makes requires the server to present that same certificate. A different one is refused.
So it is not “security off”. Traffic is encrypted either way. What changes is how the kiosk decides which server to trust: by a public authority, or by remembering the exact certificate it met when you paired it.
When to switch it on
Turn it on when the kiosk cannot validate your certificate through the normal route and you accept the trade-off below:
- The server uses a self-signed certificate, common on a closed site network.
- The certificate is issued by your organisation’s own internal certificate authority, which the tablet has not been told to trust.
- The kiosk reaches the server by an address the certificate was not issued for, such as an internal hostname or an IP address.
Leave it off whenever your server has a certificate from a public authority and the kiosk reaches it by the name on that certificate. That is the stronger configuration and it needs no maintenance.
The trade-off, stated plainly
The risk is concentrated in the moment you pair. The kiosk trusts whatever it is handed at that moment, so if somebody is intercepting the connection while you pair, the kiosk will remember the interceptor’s certificate and keep trusting it afterwards - and it will look completely normal.
That leads to one firm rule: pair the tablet on the trusted network you intend to run it on, not over guest Wi-Fi, a hotel connection or a mobile hotspot. Pairing on a network you control is what makes this feature safe. After pairing, the stored fingerprint blocks an interceptor who arrives later.
There is also a quieter failure worth knowing about. If the kiosk cannot read the certificate during pairing - for example the connection is refused at the exact moment it checks - it may complete pairing without storing a fingerprint at all. In that state it accepts any certificate on every request, with nothing on screen to say so. If pairing was unreliable and you finished it on the second or third attempt, re-pair the device from a clean start so you know a fingerprint was stored.
What happens when the server certificate changes
This is the consequence sites most often meet, usually months later and without connecting it to this switch.
Because the kiosk pins one specific certificate, renewing or replacing your server’s certificate breaks every kiosk paired with the old one. The kiosk stops connecting; nothing on the server changed from its own point of view.
Plan for it:
- Note which kiosks were paired with INSECURE SSL switched on, and when.
- When you renew the certificate, re-pair those kiosks afterwards. Clearing the app’s data returns it to the pairing screen.
- If you would rather not repeat this, use the certificate renewal as the moment to move to a certificate the tablets trust natively, and pair with the switch off.
Renewing a certificate from a public authority while the switch is off does not require re-pairing, because the kiosk trusts the authority rather than the individual certificate.
Symptoms and what they mean
| What you see | What it usually means |
|---|---|
| Pairing fails on a server that works in a browser, switch off | The tablet does not trust the certificate: self-signed, internal authority, or the address does not match the name on it. Switch INSECURE SSL on, or install your authority’s certificate on the tablet. |
| Kiosks that ran for months all stop at once | The server certificate was renewed or replaced. Re-pair the kiosks that were paired with the switch on. |
| One kiosk stops, the rest are fine | Not this feature. Look at that tablet: network, or the clock, covered in FrontDesk Troubleshooting. |
| Pairing fails with a message about server configuration and timezone | The tablet’s clock, not the certificate. See FrontDesk Troubleshooting. |
The better long-term answer
INSECURE SSL exists so a site can get running on a network where the normal certificate route is not available. It is a legitimate configuration, not a hack, but it carries the pairing-time risk and the re-pairing chore forever.
If you run more than a handful of kiosks, the lower-maintenance path is to make the tablets trust your certificate properly and leave the switch off:
- Install your internal certificate authority on the tablets, through your device management tooling if you have it.
- Or give the server a certificate from a public authority and reach it by the name on that certificate.
Either removes the pairing-time exposure and the re-pair-on-renewal cycle in one step.
See also: Set Up Kiosk and Guard Devices for where the switch sits in the pairing sequence, and FrontDesk Troubleshooting for pairing failures that are not certificate-related.