My web server is (include version): short.io link shortner service
This is an odd one, but we use short.io, which is a link shortner service with a custom domain (gofb.info). The SSL is powered by let’s encrypt (through short.io, we do not manage the cert directly).
When we share short links from gofb.info on instagram and other social media platforms, we have a handful of users report that they get the message “this sites security certificate is not trusted” usually from the in-app (instagram / facebook) browser when users swipe up on the links.
Again, small number of users (we are working to get device information), but I am trying to gather information to create a support ticket with short.io on the topic.
SSL Labs shows a score of an A as well as trusted on Android, Apple, so I assume the chain is good.
Guess that the users are on older Android devices or using older versions of the native apps, but hard to trouble shoot directly.
It would help to know the exact error message (including “advanced” information, if available) and browser and OS versions involved.
It’s true that some old clients won’t recognize Let’s Encrypt.
The web server configuration is probably a larger issue: It requires SNI, and the minimum supported TLS version is 1.2. That is reasonable, good and common at this point – there’s been a push for a couple years to get rid of TLS 1.0 and 1.1 – but will be incompatible with many old clients.
If you look at SSL Labs, there’s a section labeled “# Not simulated clients (Protocol mismatch)” in somewhat small blue text, with a “Click here to expand” button. It will list some older platforms that cannot access the site.
This is actually a good idea. As mentioned above, the setup itself looks valid overall and not having TLS 1.0 and 1.1 is actually good too (Chrome was going to remove 1.1 completely in version 81, but postponed until version 84). However, since your certificates are managed by a third-party, there might be some other issues in play (whether setup or infrastructure related), so your best shot is indeed to collect more data to see if any pattern emerges, and file a request with them.