After the most recent updates I am not able to see vault item icons anymore on my ios device. I am able to see them in my google chrome browser extension as well as on the web vault. I was not having this issue prior to the recent update of the vaultwarden server and January client updates.
Can anyone direct me if this is 1) a confirmed issue? 2) Is this upstream where it needs to be reported there?
I was able to roll back the iOS app using test flight, no luck with getting the icons to show on iOS. I’ve even delete the app completely on the phone, ensuring that all data was removed as well with no luck. Judging by that I don’t think this appears to be a client issue then.
Anyone else having an issue where vault item icons aren’t showing on iOS bitwarden app? This started happening with the recent updates of VW latest server as well as bw’s latest client updates. I’m trying to rule out if it’s app side or server side.
I’ve already rolled back the iOS app to a previous version and that didn’t work. I don’t want to roll back VW server because I don’t want to cause any issues or corruption. I’ve tried log outs, app deletion, I can confirm form an iOS browser that I can see the vault icons using the below url. Ran out of ideas here.
https://vw.domain.tld/icons/sites.com/icon.png
I downloaded the bitwarden app on an iPad and the icons don’t show there too.
What kind of certificate are you using? Is it fully valid?
Try to run your domain through SSL Server Test (Powered by Qualys SSL Labs)
If it is missing a chain, that could cause issues.
And double check you do not have the don’t download icons feature enabled on the client settings.
Certificate is done thru Let’s Encrypt. The ssl test comes back as good.
The vault item icons work on the web vault, chrome browser extension, and windows desktop app. iOS iPhone and iPad app are both the only ones not working.
But, during that test, does it mention that the chain is valid also?
My apologies but nothing is sticking out relating to the chain on that page. What section should I be looking at.
Under certificate paths there’s a tab that says apple. If I click that I see path 1 as trusted. There’s then 2 items sent by server and 1 that says in green in trust store.
There’s also this:
Additional Certificates (if supplied)
Certificates provided 3 (3808 bytes)
Chain issues None
Looking more at the logs, when I connect one client at a time (such as desktop app, browser extension) I can see requests and responses for icons (icon_internal). I DO NOT see this with the ios app. So if the case is the ios app is not requesting for the icon, I need to see if anyone else can replicate this in their setup using the latest VW server and the latest ios BW client app. This would narrow down if it is the ios client app or something with my setup? I don’t think it is something with my setup because as mentioned this was working before. I also grabbed a new ipad that never had BW app and installed and that didn’t even work, therefore I am able to rule out my specific phone as the issue. It has to be an issue with the BW ios client not requesting the icons, and I have confirmed the setting is turned on to fetch the icons.
RESOLVED: I’ve linked this back to a setting on my Synology nas, under settings, security, advanced; there are three different TLS/SSL Profile Levels: Old backward, intermediate, and modern compatibility. I have changed this setting from modern to intermediate compatibility and now the vault icons on iOS are showing.
According to Synology’s help article the profile modern only uses TLS 1.3, so I am guessing the BW iOS app isn’t compatible with that?
It is a best practice to allow TLS 1.3 + 1.2. Older versions are vulnerable. It is like WPA2 and WPA3 in WiFi. WPA3 is there for years, but we all see how still popular is WPA2 and how very little of devices are compatible with WPA3, thus enabling mixed mode on your router is best shot. Cutting edge security always impact compatibility.
1 Like
Thank you very much for this explanation, I can certainly make the connections with your wpa example.