Check whether your certificate works with Opter Terminal
Last updated: 18 June 2026
In this article
If many users are unable to log in to Opter Terminal or Opter Driver for Android, this may be because the version of Android on their mobiles or scanners is unable to handle the certificate you are using for Opter’s services. There is a tool for checking the certificate against Android’s requirements, which shows whether there are any issues.
This applies only if you have your own server environment. If you use the cloud, Opter will manage the certificate.
Proceed as follows:
Enter the web address of the server you are using for Opter Driver in the field Hostname or URL.
You can find the web address under QR codes and links for our apps in the main menu in Opter, for example “https://transportfirman.se/mobileserver”. If you want to check a specific port, type “https://transportfirman.se:567/mobileserver”
Click on Check.
If the check shows that the certificate will not work, follow the instructions in the tool.
Background
Most modern web browsers can handle incorrectly configured TLS certificates. If a server is not configured entirely correctly, web browsers compensate for this by retrieving intermediate certificates if they are missing (via the AIA extras), reconstructing the certificate chain in the correct order, and trying several root certificates until one works. As a result, web administrators often assume that the certificate is fine, as everything looks fine in the browser.
Android apps use Java’s built-in HTTP client, which is more stringent than standard web browsers when it comes to TLS certificates. Android apps do not retrieve intermediate certificates, and the server must present the entire certificate chain in the correct order. The standard client HttpsURLConnection (and older versions of OkHttp/Volley) adhere strictly to the TLS specification: the server must send the entire certificate chain in the correct order, signed by a CA that is already present in Android’s built-in trust store. If something isn’t quite right, the handshake won’t go ahead.
The most common errors:
The intermediate certificate is missing.
The server only sends leaf. A web browser fetches the REST via AIA and doesn’t say anything. Android doesn’t do that, so the client doesn’t work.
The chain is in the wrong order.
The server sends leaf – root – intermediate in the wrong order. A web browser corrects this. Older Android Java clients do not do this, and the client therefore does not work.
Newer root certificates are not supported in older versions of Android.
Let's Encrypt's ISRG Root X1 was not included in Android until version 7.1.1. Devices running Android 4.x–7.0 will not work unless the certificate chain is cross-signed by an older certificate (DST Root CA X3, which expired on 30 September 2021).
The SAN is missing or incorrect.
Android has long ignored the CN field (Common Name). Without a matching SAN (Subject Alternative Name), the certificate will not work, even if everything else is correct.
Valid for longer than 398 days.
Certificates issued after 1 September 2020 with a validity period of more than 398 days do not work on Android 11 and later.
