send with CLI at only one client/user + CLI and letsencrypt-certificate

[reschresch]

Hello,
in my test-environment I have 2 clients (smartphones) who logged in with different usernames.
Now I want to send a message over the CLI only to "user1", but I dont know what's the syntax.

And: I have a letsencrypt-certificate. With the smartphone-client I can check on that the client ignore somewhat so he had login correctly. Is this possible with the CLI too?

With best regards,
reschresch

[jmattheis]

in my test-environment I have 2 clients (smartphones) who logged in with different usernames.

Do you mean different users or only different clients of one user?

Now I want to send a message over the CLI only to "user1", but I dont know what's the syntax.

Have you followed the steps on https://github.com/gotify/cli#installation ? There are examples for sending a message.

And: I have a letsencrypt-certificate. With the smartphone-client I can check on that the client ignore somewhat so he had login correctly. Is this possible with the CLI too?

If you have a letsencrypt certificate all should work out of the box, as the certs are generally accepted by your OS without further configuration.

[reschresch]

Hello jmattheis,

• I have two clients (two smartphones) with two different usernames.
• I follow the steps with the cli-examples.
  I send in the CLI a "gotify push "Test001".

After many tries (where nothing appears on the phones, but I see in the server-console that something happened) on one phone with "user1" the message appears, on the 2nd (user2) not.
OK, I dont know why is appears at this time, but something goes right. I'm happy.
After that I try again, on both phones the same user - on both phones the message appears.
OK, I think I understand a little bit - I'm happy again.
After that I init the cli again and use an app-token I generate with the browser-web-ui.
No message appears. (I see in the server console that it generate a new line when I send the message)

Hmmmm, what can I do?
I would be thankful if you can explain me how I can send with the cli a message to user:"user1" on client:"phone1".
I try to understand the context between user and client as "receiving devices" and the app as sender.

It's possible I read not enough the docu.
Give me a hint (link) where I can find a docu to that topic.

My first thought was that in the cli is a parameter like "gotify push -receive "user1" "messagetext". (Or somtehing like that.)
But I think I have not understand your principle at this time.

With best regards,

reschresch

[jmattheis]

Have a look at https://gotify.net/docs/ for explanation what a client/application/user is.

When you init the cli, you either provide login credentials or an application token. When you now use cli push you send a message to the user that owns the application. So it is not possible to send a message to user2 with an application token from user1.

Are there any errors in the log or rather could you paste the whole output of cli init and the gotify/server log? (you can hide urls)

[reschresch]

Hello jmattheis,
thank you for this information.
Actual I have no errors in my log - I understand now that there is a relationship between the used app-token (sender) and the client (receiver).
I will try it out.
Yesterday I implement my (existing) letsencrypt-certificate. I put it my config-file and my browser runs perfectly without error.
But the CLI throws an error:
http: TLS handshake error from xxx.yyy.zzz.aaa:44140: remote error: tls: bad certificate

This is my server-config for this part:
ssl:
enabled: true # true # if https should be enabled
redirecttohttps: true # redirect to https if site is accessed by http
listenaddr: "xxx.yyy.zzz.aaa" # the address to bind on, leave empty to bind on
port: 111 # the https port
certfile: /etc/letsencrypt/live/XXXDomain.YY/cert.pem # the cert file
certkey: /etc/letsencrypt/live/XXXDomain.YY/privkey.pem # the cert key
enabled: false # if the certificate should be requested from letsencrypt
accepttos: true # 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
- XXXDomain.YY

I will be very happy if you can give me a hint.

With best regards,
reschresch

[jmattheis]

Could you run the following command?

$ curl -vvv https://yourdomain.de/version

and paste the output

[reschresch]

I try run local on my server.
Actually I use port 90:
root@server ~ # curl -vvv https://mydomain.xx:90/version

• Trying 123.456.789.123...
• Connected to mydomain.xx (123.456.789.123) port 90 (#0)
• found 148 certificates in /etc/ssl/certs/ca-certificates.crt
• found 596 certificates in /etc/ssl/certs
• ALPN, offering http/1.1
• SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
• server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates .crt CRLfile: none
• Closing connection 0
  curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-cer tificates.crt CRLfile: none
  More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

[jmattheis]

Have you updated that server lately? maybe your certs in /etc/ssl/certs/ca-certificates.crt are outdated.

Could you try updating these?

$ update-ca-certificates

See https://superuser.com/a/437377

[reschresch]

Hello jmattheis,
I have executed your command but under linux-CLI there is no difference. The message is the same I wrote yesterday.
Today I try out the Windows-CLI and it runs perfectly. No problem to send a push-message, the init-procedure runs without problems from beginning to the end.
On the smartphone I have to disable the checkbox the SSL-validation.
For my better understanding: Is "my" error-message from the letsencrypt-certificate or is this the ssl-certificate? I read again which from the four letsencrypt-pem-files is the right one.
With best regards,
reschresch

[jmattheis]

Yeah, your letsencrypt certificate may not be valid or you linux server somehow thinks that it is. Using this cli with an unsecure cert would require #27