github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-21 13:52:07 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

On-premise Hosting and different port than 443 #122

New Issue
Closed
opened 2025-11-07 08:27:44 -06:00 by GiteaMirror · 24 comments
GiteaMirror commented 2025-11-07 08:27:44 -06:00
Owner
Copy Link

Originally created by @tolazi on GitHub (Nov 20, 2017).

I have a Problem with my On-premise Hosting. Browser login and browser extensions work perfectly. Only the login with the Android App (version 1.12.1 and 1.12.2) does not work. I use Let´s Encrypt Certificate and another Port then 443 and the Syntax looks like e.g.:
Server URL
https:\my.ownbitwarden.com:54921
I always get the Error “There is a problem connecting to the server”.

Originally created by @tolazi on GitHub (Nov 20, 2017). I have a Problem with my On-premise Hosting. Browser login and browser extensions work perfectly. Only the login with the Android App (version 1.12.1 and 1.12.2) does not work. I use Let´s Encrypt Certificate and another Port then 443 and the Syntax looks like e.g.: Server URL https:\\my.ownbitwarden.com:54921 I always get the Error “There is a problem connecting to the server”.
GiteaMirror commented 2025-11-07 08:27:45 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 20, 2017):

Are you able to monitor the network traffic (proxy maybe?) and see what the requests going out are looking like? Do they include your port properly?

@kspearrin commented on GitHub (Nov 20, 2017): Are you able to monitor the network traffic (proxy maybe?) and see what the requests going out are looking like? Do they include your port properly?
GiteaMirror commented 2025-11-07 08:27:45 -06:00
Author
Owner
Copy Link

@Shadow00Caster commented on GitHub (Nov 20, 2017):

I'm having this same issue and as well use a custom port. I ran a packet capture and do indeed see it going to the correct resolved IP and port as specified in my custom server URL.

15:01:40.149754 IP y.y.y.y.48745 > x.x.x.x.8091: tcp 0
15:01:40.150169 IP x.x.x.x.8091 > y.y.y.y.48745: tcp 0
15:01:40.152246 IP y.y.y.y.48745 > x.x.x.x.8091: tcp 0
15:01:40.152384 IP y.y.y.y.48745 > x.x.x.x.8091: tcp 182
15:01:40.152535 IP x.x.x.x.8091 > y.y.y.y.48745: tcp 0
15:01:40.153628 IP x.x.x.x.8091 > y.y.y.y.48745: tcp 1448

@Shadow00Caster commented on GitHub (Nov 20, 2017): I'm having this same issue and as well use a custom port. I ran a packet capture and do indeed see it going to the correct resolved IP and port as specified in my custom server URL. 15:01:40.149754 IP y.y.y.y.48745 > x.x.x.x.8091: tcp 0 15:01:40.150169 IP x.x.x.x.8091 > y.y.y.y.48745: tcp 0 15:01:40.152246 IP y.y.y.y.48745 > x.x.x.x.8091: tcp 0 15:01:40.152384 IP y.y.y.y.48745 > x.x.x.x.8091: tcp 182 15:01:40.152535 IP x.x.x.x.8091 > y.y.y.y.48745: tcp 0 15:01:40.153628 IP x.x.x.x.8091 > y.y.y.y.48745: tcp 1448
GiteaMirror commented 2025-11-07 08:27:46 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 22, 2017):

@Shadow00Caster The issue doesn't appear to be the port. I am using your server URL and I get a SSL handshake exception:

Javax.Net.Ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

Are you using a self-signed cert?

@kspearrin commented on GitHub (Nov 22, 2017): @Shadow00Caster The issue doesn't appear to be the port. I am using your server URL and I get a SSL handshake exception: > Javax.Net.Ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. Are you using a self-signed cert?
GiteaMirror commented 2025-11-07 08:27:46 -06:00
Author
Owner
Copy Link

@Shadow00Caster commented on GitHub (Nov 22, 2017):

@kspearrin No it's an LE cert

Because of port issues, I was not able to do the auto LE as part of the installation, so I just did a manual dns option with certbot and then moved the 3 files and renamed appropriately to the bwdata/ssl folder from the certbot/live folder.

@Shadow00Caster commented on GitHub (Nov 22, 2017): @kspearrin No it's an LE cert Because of port issues, I was not able to do the auto LE as part of the installation, so I just did a manual dns option with certbot and then moved the 3 files and renamed appropriately to the bwdata/ssl folder from the certbot/live folder.
GiteaMirror commented 2025-11-07 08:27:46 -06:00
Author
Owner
Copy Link

@tolazi commented on GitHub (Nov 23, 2017):

@kspearrin Sorry I was not able to monitor the network traffic. But meanwhile I think I have not an issue with the port, I think I have the same issue as Shadow00Caster with the cert.
I use Let´s Encrypt Certificate without the bitwarden docker-setup and it is not possible to connect with the App (Internet and direct LAN). I moved also the files (private.key, certificate.crt) in the directory (/bwdata/ssl/self/xxx.com/). With the browser and the browser extensions looks like the certificate is ok.

@tolazi commented on GitHub (Nov 23, 2017): @kspearrin Sorry I was not able to monitor the network traffic. But meanwhile I think I have not an issue with the port, I think I have the same issue as Shadow00Caster with the cert. I use Let´s Encrypt Certificate without the bitwarden docker-setup and it is not possible to connect with the App (Internet and direct LAN). I moved also the files (private.key, certificate.crt) in the directory (/bwdata/ssl/self/xxx.com/). With the browser and the browser extensions looks like the certificate is ok.
GiteaMirror commented 2025-11-07 08:27:46 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 25, 2017):

Is it possible to test your installations on port 80/443 to see if that makes any difference?

@kspearrin commented on GitHub (Nov 25, 2017): Is it possible to test your installations on port 80/443 to see if that makes any difference?
GiteaMirror commented 2025-11-07 08:27:46 -06:00
Author
Owner
Copy Link

@Shadow00Caster commented on GitHub (Nov 25, 2017):

@kspearrin Wouldn't I have to do the install script again to change nginx to 80/443 since it's listening internally on 8090/8091.

@Shadow00Caster commented on GitHub (Nov 25, 2017): @kspearrin Wouldn't I have to do the install script again to change nginx to 80/443 since it's listening internally on 8090/8091.
GiteaMirror commented 2025-11-07 08:27:47 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 25, 2017):

Yes. I would just do a whole new installation folder. Is it possible to shut down the existing service on 80/443 in order to test this there, as a temporary test of course?

@kspearrin commented on GitHub (Nov 25, 2017): Yes. I would just do a whole new installation folder. Is it possible to shut down the existing service on 80/443 in order to test this there, as a temporary test of course?
GiteaMirror commented 2025-11-07 08:27:47 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 25, 2017):

Or rather, just try shutting down 80/443 first and trying your existing installation. The only reason I suggest this is I noticed that your 80/443 on the same domain has a self-signed cert and I'm wondering if it is causing some issue.

@kspearrin commented on GitHub (Nov 25, 2017): Or rather, just try shutting down 80/443 first and trying your existing installation. The only reason I suggest this is I noticed that your 80/443 on the same domain has a self-signed cert and I'm wondering if it is causing some issue.
GiteaMirror commented 2025-11-07 08:27:48 -06:00
Author
Owner
Copy Link

@Shadow00Caster commented on GitHub (Nov 25, 2017):

@kspearrin port 80 is not open externally and 443 which is running Home Assistant is also using a LE cert, it's not self signed. I tested the Android app again with 443 NAT disabled on my firewall, same issue.

@Shadow00Caster commented on GitHub (Nov 25, 2017): @kspearrin port 80 is not open externally and 443 which is running Home Assistant is also using a LE cert, it's not self signed. I tested the Android app again with 443 NAT disabled on my firewall, same issue.
GiteaMirror commented 2025-11-07 08:27:48 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 25, 2017):

@Shadow00Caster when i enter your the domain you emailed us in my browser I get certificate warnings.

@kspearrin commented on GitHub (Nov 25, 2017): @Shadow00Caster when i enter your the domain you emailed us in my browser I get certificate warnings.
GiteaMirror commented 2025-11-07 08:27:48 -06:00
Author
Owner
Copy Link

@Shadow00Caster commented on GitHub (Nov 25, 2017):

@kspearrin When you hit HTTP or when you hit HTTPS on the domain without the port? If you hit it without the port, that makes sense. The cert for HTTPS:443 is a different domain, so the cert does not match the domain I sent you.

ie.

https://sub.domain.com:8091 == BItWarden with matching cert from LE
https://sub1.domain.com:443 == HA with matching cert from LE

@Shadow00Caster commented on GitHub (Nov 25, 2017): @kspearrin When you hit HTTP or when you hit HTTPS on the domain without the port? If you hit it without the port, that makes sense. The cert for HTTPS:443 is a different domain, so the cert does not match the domain I sent you. ie. https://sub.domain.com:8091 == BItWarden with matching cert from LE https://sub1.domain.com:443 == HA with matching cert from LE
GiteaMirror commented 2025-11-07 08:27:49 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 26, 2017):

I go to https://sub.domain.com (443) and get HSTS warnings.

@kspearrin commented on GitHub (Nov 26, 2017): I go to https://sub.domain.com (443) and get HSTS warnings.
GiteaMirror commented 2025-11-07 08:27:49 -06:00
Author
Owner
Copy Link

@Shadow00Caster commented on GitHub (Nov 26, 2017):

Yes that makes sense because the service listening on port 443 is not bitwarden and not the domain I provided you via e-mail. The service listening on port 443 and serving a certificate is for a different domain (if you view the cert you can see that it's not the cert for the domain I sent you).

@Shadow00Caster commented on GitHub (Nov 26, 2017): Yes that makes sense because the service listening on port 443 is not bitwarden and not the domain I provided you via e-mail. The service listening on port 443 and serving a certificate is for a different domain (if you view the cert you can see that it's not the cert for the domain I sent you).
GiteaMirror commented 2025-11-07 08:27:50 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 27, 2017):

Can you try the following to see if it changes anything? Edit ./bwdata/nginx/default.conf and comment out the following line (add a # at beginning):

add_header Strict-Transport-Security max-age=15768000;

Then restart and see if anything is different.

@kspearrin commented on GitHub (Nov 27, 2017): Can you try the following to see if it changes anything? Edit `./bwdata/nginx/default.conf` and comment out the following line (add a `#` at beginning): ``` add_header Strict-Transport-Security max-age=15768000; ``` Then restart and see if anything is different.
GiteaMirror commented 2025-11-07 08:27:50 -06:00
Author
Owner
Copy Link

@tolazi commented on GitHub (Nov 27, 2017):

I changed the port to 443 (Forwarding Service Port 443 -> Internal Port 192.168.2.25:443). The same problem wit the App: “There is a problem connecting to the server”.

@tolazi commented on GitHub (Nov 27, 2017): I changed the port to 443 (Forwarding Service Port 443 -> Internal Port 192.168.2.25:443). The same problem wit the App: “There is a problem connecting to the server”.
GiteaMirror commented 2025-11-07 08:27:50 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 27, 2017):

@tolazi So it is not a port issue for you then?

@kspearrin commented on GitHub (Nov 27, 2017): @tolazi So it is not a port issue for you then?
GiteaMirror commented 2025-11-07 08:27:51 -06:00
Author
Owner
Copy Link

@tolazi commented on GitHub (Nov 27, 2017):

@kspearrin Meanwhile i think the problem is with the Certificate and the App.

@tolazi commented on GitHub (Nov 27, 2017): @kspearrin Meanwhile i think the problem is with the Certificate and the App.
GiteaMirror commented 2025-11-07 08:27:51 -06:00
Author
Owner
Copy Link

@Shadow00Caster commented on GitHub (Nov 27, 2017):

@kspearrin I commented out the line as suggested, same error message from mobile app. Side note, I can access the web vault from Chrome on my mobile device without issue, so it would appear the LE chain is trusted on Android at least.

@Shadow00Caster commented on GitHub (Nov 27, 2017): @kspearrin I commented out the line as suggested, same error message from mobile app. Side note, I can access the web vault from Chrome on my mobile device without issue, so it would appear the LE chain is trusted on Android at least.
GiteaMirror commented 2025-11-07 08:27:51 -06:00
Author
Owner
Copy Link

@tolazi commented on GitHub (Nov 30, 2017):

@kspearrin Now i have found a solution for my issue.
I made a port Forwarding (Service Port 443 -> Internal Port 192.168.2.25:443 and Service Port 80 -> Internal Port 192.168.2.25:80). Then i start the Installer with default Ports and Let´s Encrypt. After finished the Setup i renamed the "bwdata" directory, an changed the port Forwarding (Service Port 443 -> Internal Port 192.168.2.25:54921) and start the Installer again with Port 54921 and without Let´s Encrypt. After this i copied the "letsencrypt" directory from the first setup in the new "bwdata" directory and changed Certificate-path in the nginx default.conf.
I know, this is a little bit confuse, but the Server is running with Let´s Encrypt Certificate an all seems ok. Browser login, browser extensions and the App work perfect.

@tolazi commented on GitHub (Nov 30, 2017): @kspearrin Now i have found a solution for my issue. I made a port Forwarding (Service Port 443 -> Internal Port 192.168.2.25:443 and Service Port 80 -> Internal Port 192.168.2.25:80). Then i start the Installer with default Ports and Let´s Encrypt. After finished the Setup i renamed the "bwdata" directory, an changed the port Forwarding (Service Port 443 -> Internal Port 192.168.2.25:54921) and start the Installer again with Port 54921 and without Let´s Encrypt. After this i copied the "letsencrypt" directory from the first setup in the new "bwdata" directory and changed Certificate-path in the nginx default.conf. I know, this is a little bit confuse, but the Server is running with Let´s Encrypt Certificate an all seems ok. Browser login, browser extensions and the App work perfect.
GiteaMirror commented 2025-11-07 08:27:52 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 30, 2017):

I've spent some time on this today and I cannot reproduce it. I installed a brand new installation on different ports, using Let's encrypt SSL certs. I was able to connect to it just fine with the Android app. I'm not really sure what else to try.

@kspearrin commented on GitHub (Nov 30, 2017): I've spent some time on this today and I cannot reproduce it. I installed a brand new installation on different ports, using Let's encrypt SSL certs. I was able to connect to it just fine with the Android app. I'm not really sure what else to try.
GiteaMirror commented 2025-11-07 08:27:52 -06:00
Author
Owner
Copy Link

@tolazi commented on GitHub (Dec 1, 2017):

I am confused myself, but now all works fine. Thank you for your fast support.

@tolazi commented on GitHub (Dec 1, 2017): I am confused myself, but now all works fine. Thank you for your fast support.
GiteaMirror commented 2025-11-07 08:27:52 -06:00
Author
Owner
Copy Link

@Brudertac commented on GitHub (Dec 29, 2017):

@kspearrin
Sorry to say but i think this is not resolved. I have exactly the same Problem here.
Latest bitwarden self hostet in Docker. Ports are changed away from default.

Access via webbrowser on Android Phone works fine but not in the App.

Update:
Found the Solution. I use another HTTPS Port for bitwarden. So i entered the HTTPS://URL:PORT in the Android App. This bringes the Error.

Then i setup an Reverse Proxy for my bitwarden URL so i can remove the PORT in the APP and now it works.

@Brudertac commented on GitHub (Dec 29, 2017): @kspearrin Sorry to say but i think this is not resolved. I have exactly the same Problem here. Latest bitwarden self hostet in Docker. Ports are changed away from default. Access via webbrowser on Android Phone works fine but not in the App. Update: Found the Solution. I use another HTTPS Port for bitwarden. So i entered the HTTPS://URL:PORT in the Android App. This bringes the Error. Then i setup an Reverse Proxy for my bitwarden URL so i can remove the PORT in the APP and now it works.
GiteaMirror commented 2025-11-07 08:27:53 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Mar 9, 2018):

This is usually always due to an improper trust chain on the SSL cert. We have updated our docs to reflect the proper steps on chaining the CS cert to resolve this problem on android.

@kspearrin commented on GitHub (Mar 9, 2018): This is usually always due to an improper trust chain on the SSL cert. We have updated our docs to reflect the proper steps on chaining the CS cert to resolve this problem on android.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#122
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?