Hi, now that I have VW running on my own Linux Server, I wanted to move to the next step; Using it on my Android galaxy s21 mobile phone.
So, I clicked on the “Get the Apps” menu and found myself sent off to the BW web-site. (I’m still somewhat confused about where line is drawn between BW and VW).
Anyway, I tried to install the BW Android client (since that’s where I was directed, and there doesn’t seem to be a nativ VW Android client anywhere).
But I couldn’t figure how to connect to vw.mydomain.com with the Android App…
Is it supposed to work?
Hello, Vaultwarden is just an alternative backend, you just use the Bitwarden clients.
The main benefit of Vaultwarden are it’s reduced memory and cpu requirements and ease of setup, the later because it is able to use an embedded database for storing stuff.
In the client there is a small gear in the corner of the login screen. There you may enter your hostname. And it works like a charme for me 
1 Like
Thank you. I tried that, but it doesn’t work.
All I get is the following error message:
Exception message: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
If I use Chrome on my Android phone to log in to VW, everything works just fine, but of course, the page is not adapted to the tiny phone screen, so zooming in and out constantly makes it not very user friendly.
It seems you use a self-signed certificate and probably accepted it in Chrome as an exception. So either you try to setup Let’s Encrypt which gives you a valid certificate known to your mobile’s OS or get it into the certificate store manually.
No, I’m not using self-signes certificates. I’m using Let’s Encrypt certificates.
I have never used self-signed certificates, and the Android Phone is a brand new Galaxy S21 with everything installed fresh last week, including Chrome. I’ve also tried Samsungs own browser which comes bundled with the phone, and it too works prefect.
It’s only the BW App that fails.
Have you tried connecting it to bitwarden.com?
No, I don’t have an account with them, and I do not want to use an online service.
But I’m sure that would work.
Is that how you are using it?
1 Like
No, I use the client on my VaultWarden instance.
Connecting to bitwarden.com would allow checking if the app works in the first place.
Yes, if I clear all settings and choose “create new account”, then I can log on using that account.
Well, that is strange. AFAIK Chrome on Android just uses the standard OS certificate store.
Maybe you do not return the complete certificate chain? Browsers do cache intermediates, so if you ever accessed another website which uses the same intermediate, your browser is “spoiled”.
On my instance, e.g. the chain looks like this: “ISRG Root X1” → R3 → vw.myprivate.domain
Well, to eliminate that possibility, I borrowed my wife’s iPhone. It only has safari and she has never visited my VW site before. She doesn’t even know that it exists.
But using her phone, with WiFi disabled going only via the mobile network to vw.mydomain.com and everything worked perfectly.
The problem with a browser is, that if your wife ever visited another web site which uses the same intermediate (in my example R3) that is enough.
I assume you run vaultwarden on Linux. So you could try to use curl? If curl https://vw.mydomain.com does not report an error and you did not add the intermediate to the certificate store there manually by placing it in e.g. /usr/local/share/ca-certificates or the like then the intermediate is not the problem.
A workaround could be to add the intermediate into your smartphone’s truststore but that is brittle, once Let’s Encrypt uses a new intermediate you would to download and add that one.
This is very interesting (besides OP’s problem). I did not know that you could return a partial chain (I have never given much thought about that as I trust Caddy to do the right thing).
In such as case how would a cache be useful? In my case the chain is
DST Root CA X3 → R3 → vw.my.domain
Say I would just return
R3 → vw.my.domain
You mean that my browser would have cashed the fact that R3 was signed by DST Root CA X3?
If so - what would be wring with the certificate and its incomplete (but completed by the cashe) chain?
Hi, before jumping into “workarounds”, here’s some additional information about my setup that may or may not be of importance:
-
External access to my VW site goes through an Apache Reverse Proxy.
-
My Let’s Encrypt certificate has 5 aliases associated to it. VW is one of them.
This has never been an issue with any of my web apps. Adding aliases to a cert is within the spec. Still, I suspect that the BT app hasn’t been written and tested with alias cert names.
I may be wrong.
- My certs are generated using an integrated feature of a QNAP OS (QTS). QNAP known to be somewhat “off- track” from time to time.
Certs generated failed to support webhooks and I had to use Nginx Proxy Manager to get webhooks working for one particular web app.
Also, I did not proxypass any other protocols than HTTPS.
For whatever this additional info is worth.
In any case, thank you so much for you continued support and help.
Rgds
-------- Opprinnelig melding --------
Hi,
the uppermost certificate must be trusted by your OS/browser/program/client, the public key and intermediates must be delivered by the service itself, so in your example, yes, you need return R3 and vw.my.domain. In my VW setup I use traefik and it does the right thing 
I can only say that at the company where I work we experienced this browser-intermediate caching. There we have an internal CA. A fresh profile in Firefox with only the uppermost certificate installed does reveal the problem as well, once you got the intermediate by visiting another internal site, the profile was burnt. So, yes, browser cache the fact that R3 is trustable and was signed by DST Root CA X3 somehow (at least for Safari/Chrome and Firefox I saw this).
In Nginx you need to provide your own pub-key and the intermediates concatenated in one file, Apache wants it in another file given by SSLCertificateChainFile directive.
Hello Viking,
what do you mean with “Aliases”? Virtual Hosts? Or do you mean Subject Alternative Names (SANs) in the certificate?
Another difference to my knowledge: browsers still accept the value of the certificate given in the common-name but I think newer versions of TLS now default to ignore the common-name and only take entries from the SANs section.
Regards
Mirko
Sorry for my late reply - I’ve been away.
regarding your question as to what I mean by “aliases”, I guess this taken from Let’s Encrypts Q&A answers that:
You can find it here: FAQ - Let's Encrypt
I suspect that perhaps VW is unable to accept/handle a certificate with multiple hosts (?) where vw.mydomain.com is just a wildcard (alias). However, I see no reason why this shouldn’t work as it is perfectly legitimate and common practice.
Hi, so as I suspected “alias” is your wording for SAN. Hm, I only ever used Let’s Encrypt with Traefik 1.7 and do know nothing about QNAP.
However wildcard and SAN are different concepts, you may have certificate for the wildcard SAN *.your.domain and the same certificate could contain another SAN vw.another.domain. The first SAN entry is valid for every “hostname” ending on your.domain while the second SAN only matches exactly vw.another.domain.
Without using something openssl it might be tricky to get correctly. Did you try to reach the host with curl? Together with the option -v you should get a lot of information which may be useful for debugging.
The challenge with QNAP is that they do not document much details about how things are implemented.
But, from what you explain, and from what I have read in the Let’s Encrypt docs, I think that QNAP’s implementation is based on SAN and not wildcards.
The above screen cap shows the dialog box used by QNAP to generate the certificates (the names are of course just to illustrate). Clicking the blue “info” button gives me the fly-out box where you can see them using the word “alias”. One can add many names to the list, and it works well.
The result can be downloaded as the following three files:
SSLcertificate.crt
SSLIntermediateCertificate.crt
SSLprivatekey.key
If I open the file SSLcertificate.crt file in Windows, I get the “Certificate Window” where all the domain names are listed in the “Subject Alternative Name” field, each name beginning with “DNS Name=” followed by the name of the domain (alias). So apparently, Windows accepts the result as a valid certificate file. I guess this is SAN by definition, and not wildcards (?).
Anyway, I have used this technique for several years on a number of subdomains that I have established for a variety of Web applications (currently I have 12 different web apps running), all handled by an Apache Reverse Proxy, and I have never ever run into any kind of combability issues. The Web version of VW also works just fine (as expected), but the Android app fails.
So, I suspect there’s some unfortunate programming that must have slipped in under the QC radar.
But, what do I know?