Support self-signed SSL Certs

[gjabell]

The Android client doesn't appear to support self-signed SSL certs, which is inconvenient if the server is for internal use. Would it be possible to add an option to ignore self-signed errors, or pull certificates from the user's certificate authority store during certificate validation?

[jmattheis]

@gjabell Thanks for your issue (:
Yeah it should be possible, later this week I'll have a look at it.

[gjabell]

@jmattheis Sure thing! I might be able to contribute too if you want some extra help.
Looking forward to trying it out!

[jmattheis]

@gjabell That would be great (:, I myself have not much experience with self-signed certificates and android, so feel free to try it.

[gjabell]

@jmattheis Looks like it isn't too hard to implement, I have some partial implementation already. Would you prefer that we disable SSL validation completely, or ask the user for their self-signed Certificate Authority certificate to use for validation?

[jvandenbroek]

Does it work at all with SSL? Because I've set up my already issued Letsencrypt certificate (certfile / certkey) and this work fine from the browser, but the Android client keeps returning status code 0. The server prints this log: http: TLS handshake error from 192.168.130.203:44707: remote error: tls: unknown certificate

Sorry for hijacking this thread, but it seems related ;)

[gjabell]

@jvandenbroek All good! Are you connecting to your server from your phone with the IP address or hostname? Also can you list your server config file here (just put placeholders in place of the private information).

[jvandenbroek]

@gjabell Alright :) I'm using the hostname which works fine on the browser, so the certificate itself seems to be loaded fine.

My /etc/gotify/config.yml:

server:
  port: 8084 # the port for the http server
  ssl:
    enabled: true # if https should be enabled
    redirecttohttps: true # redirect to https if site is accessed by http
    port: 4444 # the https port
    certfile: /etc/letsencrypt/live/mydomain/cert.pem # the cert file (leave empty when using letsencrypt)
    certkey: /etc/letsencrypt/live/mydomain/privkey.pem # the cert key (leave empty when using letsencrypt)
    letsencrypt:
      enabled: false # if the certificate should be requested from letsencrypt
      accepttos: false # if you accept the tos from letsencrypt
      cache: data/certs # the directory of the cache from letsencrypt
      hosts: # the hosts for which letsencrypt should request certificates
      - mydomain.tld
      - myotherdomain.tld
database: # for database see (configure database section)
  dialect: sqlite3
  connection: data/gotify.db
defaultuser: # on database creation, gotify creates an admin user
  name: admin # the username of the default user
  pass: admin # the password of the default user
passstrength: 10 # the bcrypt password strength (higher = better but also slower)
uploadedimagesdir: data/images # the directory for storing uploaded images

Where 'mydomain' is the correct domain dir I use for all my apps. Running with root (only during testing of course ;)), so no permission issues.

Btw I also tried the default port 443, same issue.
Edit: I'm using the prebuild arm64 binary, maybe has something to do with that?

[gjabell]

@jvandenbroek Ah, ok, I think I know the issue. Letsencrypt should give you multiple files, one is cert.pem and another is fullchain.pem. Fullchain.pem has the entire certificate chain in it, and that's the one you want to use. I just got the same error message as you when testing your config locally, but if I change the certfile line to be /etc/letsencrypt/live/mydomain/fullchain.pem it works for me :) Can you try that out?

[jvandenbroek]

@gjabell Great, that seems the culprit! Thank you, I could have tested that myself.. Was a bit mislead by the fact it works with only the privkey file when accessing from desktop :)

[jmattheis]

@gjabell

@jmattheis Looks like it isn't too hard to implement, I have some partial implementation already. Would you prefer that we disable SSL validation completely, or ask the user for their self-signed Certificate Authority certificate to use for validation?

It would be great to support both, I guess adding the self-signed certificate would be more secure than just disabling it.

[gjabell]

@jvandenbroek Glad to hear it :) yeah it's a bit confusing, I think in browser the cert is enough to prove that it's from letsencrypt but I guess if you're accessing it from android you need the full chain.

@jmattheis Yeah that's a good point. I guess I can just add some options to the login screen to either disable SSL validation for the current login or select a certificate authority file from the filesystem?

[gjabell]

@jmattheis Alright, just opened a merge request in #15 :) sorry there are so many changes. If you want me to explain any of the changes I made or want something done differently just let me know. I tested it using both my self-signed cert and also a LetsEncrypt cert and didn't have any issues, but if you find anything not working let me know and I'll fix it.

[jmattheis]

@gjabell Thanks! I'll have a look at it in the afternoon.

[Leopere]

It's pretty trivial to setup a Traefik reverse proxy with automatic LetsEncrypt provisioning if you deploy via docker.

[jmattheis]

@Leopere Yup, but if Gotify is hosted inside an internal network then letsencrypt is not an option cause it shouldn't be visible to the outside.

[Leopere]

You can still verify a LE certificate within an airgap its just more steps.

…

On Sat, Nov 10, 2018 at 3:48 AM Jannis Mattheis ***@***.***> wrote: @Leopere <https://github.com/Leopere> Yup, but if Gotify is hosted inside an internal network then letsencrypt is not an option cause it shouldn't be visible to the outside. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBNVvQ8BFuGpa5l95qZo5aVMkCuL15Fks5utpLvgaJpZM4YQ0q_> .

[gjabell]

It's possible, just more work than using a self-signed CA especially if you are provisioning lots of clients. You can also run into rate-limit issues if you have many certificates to issue.

[Leopere]

SSL/TLS is a trust platform, trusting a self signed certificate within a LAN is somewhat moot. If you have a MITM attacker inside your airgap you have other things to worry about but I do appreciate the desire for wanting it. I'm a supporter of encrypt everything but it doesn't seem like its a good use of dev time. Although I'm not part of this project just a whiny issue commenter. ;) I don't know if you're going to be issuing 20+ TLS certificates within the hour especially if it's airgap so I doubt that would be an issue. It is important to write that down though I suppose.

…

On Sat, Nov 10, 2018 at 9:52 AM Galen Abell ***@***.***> wrote: It's possible, just more work than using a self-signed CA especially if you are provisioning lots of clients. You can also run into rate-limit issues if you have many certificates to issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBNVnLB3skObvPrmYcOLJCadNUYNupiks5utugrgaJpZM4YQ0q_> .

[gjabell]

It depends on the context, obviously since I'm running all of my services for myself, using SSL/TLS for internal networks is a bit overkill (gotta get that green lock though!), but in a corporate setting it's equally as important to encrypt internal as external traffic.

[Leopere]

Sure, although generally corporate settings you generally need certified software so even fewer potential reasons to work on it. It's not a bad idea just seems tricky and implementing your own crypto solutions can be a burden that just risks peoples sensitive data. If anything maybe an end to end encryption system using asymmetric key cryptography from the sender to the receivers would be better. It's been a matter of contention within a project I'm working on but its an important one.

…

On Sat, Nov 10, 2018 at 10:05 AM Galen Abell ***@***.***> wrote: It depends on the context, obviously since I'm running all of my services for myself, using SSL/TLS for internal networks is a bit overkill (gotta get that green lock though!), but in a corporate setting it's equally as important to encrypt internal as external traffic. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBNVvFcLh59Y47_ZLIAj0ruzsmsWHhfks5utuswgaJpZM4YQ0q_> .

[jmattheis]

Done in #15