Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bug(Android): Support user-installed certificates #236

Open
Fen-nix opened this issue Sep 5, 2023 · 10 comments · Fixed by #544 · May be fixed by #545
Open

Bug(Android): Support user-installed certificates #236

Fen-nix opened this issue Sep 5, 2023 · 10 comments · Fixed by #544 · May be fixed by #545
Labels
bug Something isn't working

Comments

@Fen-nix
Copy link

Fen-nix commented Sep 5, 2023

Is this urgent?

None

What parts are affected

Both

What are the Server/Client versions of KitchenOwl

Latest Client and Server (Docker)

What's the problem 🤔

I've configured a reverse proxy for Apache and through a browser KitchenOwl is functioning just fine; However the Android app simply displays the message "Hmmmm... couldn't reach server".

The logs from the android device don't show any errors.

May relate to #211 but in my case the web works fine just the mobile app doesn't.

I have tested every permutation of hostname, IP, port, in the Android App's Switch Server screen. Examples:

Unless I'm missing it somewhere, the documentation doesn't really spell out how to connect the app to the selfhosted environment but the hint in the url entry when switching servers leads me to believe it needs to connect directly to the backend itself so I'd have expected at least one of the :5000 options above to work.

This is reverse proxied via Apache (though I've also tried it without this and the problem persists there too). TCP/8080 and TCP/5000 are both permitted via firewall.

Apache configuration:

<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLEngine on
        SSLCertificateFile      /etc/pki/certs/ko.cer
        SSLCertificateKeyFile   /etc/pki/private/ko.key
        SSLCertificateChainFile /etc/pki/certs/chain.pem

        RewriteEngine On
        RewriteCond ${HTTP:Upgrade} websocket [NC]
        RewriteCond ${HTTP:Connection} upgrade [NC]
        RewriteRule .* "ws://localhost:8080/" [P,L]

        ProxyPreserveHost On
        ProxyPass / http://localhost:8080/
        ProxyPassReverse / http://localhost:8080/
</VirtualHost>

Share your logs

No response

Share your configuration

version: "3"
services:
  front:
    image: tombursch/kitchenowl-web:latest
    restart: unless-stopped
    environment:
      - FRONT_URL=https://ko.lan.home/
    ports:
      - "8080:80"
    depends_on:
      - back
  back:
    image: tombursch/kitchenowl:latest
    restart: unless-stopped
    environment:
      - JWT_SECRET_KEY=<random data>
      - FRONT_URL=https://ko.lan.home/
    ports:
      - "5000:5000"
    volumes:
      - /home/ko/ko_data:/data
@Fen-nix Fen-nix added the bug Something isn't working label Sep 5, 2023
@TomBursch
Copy link
Owner

This is most likely related to #187. Not sure what I can do about it, since it seems setup specific. (Most likely to some weird certificate resolving of flutter?)

Unless I'm missing it somewhere, the documentation doesn't really spell out how to connect the app to the selfhosted environment but the hint in the url entry when switching servers leads me to believe it needs to connect directly to the backend itself so I'd have expected at least one of the :5000 options above to work.

It doesn't, and the 5000 port mapping isn't required. It used to be like that, that's why the hint is outdated, thanks for the info! Will update the hint and add it to the documentation.

@Fen-nix
Copy link
Author

Fen-nix commented Sep 5, 2023

In my case I'm using my own CA on my LAN, the full chain for which is already imported in Android. I'm able to use a number of other apps from both F-Droid and the Appstore this way.

It looks like possibly this? flutter/flutter#118286

@TomBursch TomBursch changed the title Bug: Android App can't connect: Hmmmm... couldn't reach server Bug(Android): Support user-installed certificates Sep 6, 2023
@TomBursch
Copy link
Owner

I think this is the relevant dart issue dart-lang/sdk#50435, will mark this as upstream.

@SchucoSlimane
Copy link

So what about the issue? It's neither an option to use a development version (cronet) nor trust a specific certificate. Will there be a fix?

@TomBursch
Copy link
Owner

TomBursch commented Sep 20, 2023 •
edited
Loading

Yeah I'm not really sure what to do about it. Some other projects I've seen linked in the same issue just publish an additional APK that accepts all certificates (valid or not). I could do the same but feel like it's not a good solution. The only other thing I can do is wait until the flutter issue is resolved. I'm open to suggestions though.

@pedroapero
Copy link

pedroapero commented Nov 26, 2023 •
edited
Loading

I might have the same issue:
I can load the webUI and login; but with the app I get the "hummmm" message with no other detail.
I'm using a Let'sEncrypt certificate that's working fine with all my other apps on port 443.

It's working fine with HTTP via the same reverse proxy.

@TomBursch TomBursch mentioned this issue Feb 1, 2024
Open
@TomBursch TomBursch removed the upstream label Feb 1, 2024
@TomBursch TomBursch moved this to Next Up in KitchenOwl Project Feb 1, 2024
@thatso
Copy link

thatso commented Apr 8, 2024 •
edited
Loading

In my case I'm using my own CA on my LAN, the full chain for which is already imported in Android. I'm able to use a number of other apps from both F-Droid and the Appstore this way.

After finally getting the Docker instance #422 to run, I was hit by the same issue. 😢
@TomBursch: is there a preferred way to get logs from the app trying to connect? The Docker container logs don't show anything useful.

As for suggestions: I agree that silently accepting all certificates (even those which are failing checks) is more of a security nightmare than a solution. How about an "I know what I'm doing" option to manually disable certificate checks so the app can at least connect for now until a real solution is available upstream?

@coderph0x
Copy link
Contributor

coderph0x commented Apr 21, 2024 •
edited
Loading

I'd like to suggest to add <certificates src="user" /> to the network_security_config.xml like mentioned here.

Provided a PR and hope I did that right (because it's the first ever :D): #433

@coderph0x coderph0x mentioned this issue Apr 21, 2024
Merged
@coderph0x
Copy link
Contributor

coderph0x commented Apr 25, 2024 •
edited
Loading

Apparently the PR hasn't fixed the issue, just like @TomBursch predicted :-(

Since you mentioned dart and http client, maybe this can be of any help: https://stackoverflow.com/questions/69511057/flutter-on-android-7-certificate-verify-failed-with-letsencrypt-ssl-cert-after-s

Since I don't know flutter enough, I cannot tell if this has to be compilated beforehand or if putting the ca cert into the docker container would be sufficient.

@TomBursch TomBursch mentioned this issue Nov 15, 2024
Merged
@TomBursch TomBursch linked a pull request Nov 15, 2024 that will close this issue
feat: Use cronet client on android (Support device certificates) #544
Merged
@github-project-automation github-project-automation bot moved this from Next Up to Ready for Testing in KitchenOwl Project Nov 15, 2024
@TomBursch TomBursch linked a pull request Nov 15, 2024 that will close this issue
Draft
@TomBursch
Copy link
Owner

Well, it seems I was a bit too fast with merging that PR. It breaks the flutter web build process.

@TomBursch TomBursch reopened this Nov 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
KitchenOwl Project
Status: In Progress
Milestone
No milestone
6 participants
@pedroapero @TomBursch @SchucoSlimane @thatso @coderph0x @Fen-nix