mirror of
https://github.com/Aetherinox/ntfy-desktop.git
synced 2026-04-25 06:55:54 +03:00
[GH-ISSUE #80] 🐛 Bug: Failed to resolve HTTPS #158
Labels
No labels
Build › MacOS
Status › Need Info
Status › No Action
Status › Released
Type › Bug
Type › Feature
Type › Feature
Type › Roadmap
pull-request
❔ Question
📰 Progress Report
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ntfy-desktop#158
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @shooolme on GitHub (Jun 4, 2025).
Original GitHub issue: https://github.com/Aetherinox/ntfy-desktop/issues/80
Originally assigned to: @Aetherinox on GitHub.
Hello, I'm not sure what all to include but I am able to navigate from my client machine browser to both the http and https pages of my self hosted ntfy server. However, I can only configure the ntfy-desktop app to connect with http. I've cut a certificate with my internal PKI and trust the root and intermediate, the browser is happy. I'm not sure what to check next.
@Aetherinox commented on GitHub (Jun 5, 2025):
Try out this command and paste the response
Is your browser not detecting that an SSL certificate is installed and you're still seeing it as insecure?
@shooolme commented on GitHub (Jun 5, 2025):
I'm using Edge, I see my ntfy-server as a secure site when I browse to it directly. My root and subordinate CA certs are in my trusted root certificate store but I see it says it cannot verify the first certificate in the chain.
`winpty openssl s_client -showcerts -connect sil-ntfy.mel.dom:443
Connecting to 172.16.53.69
CONNECTED(000001A0)
depth=0 C=US, L=Eglin AFB, O=U.S. Air Force, OU=692nd CYOS, CN=SIL-NTFY
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C=US, L=Eglin AFB, O=U.S. Air Force, OU=692nd CYOS, CN=SIL-NTFY
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 C=US, L=Eglin AFB, O=U.S. Air Force, OU=692nd CYOS, CN=SIL-NTFY
verify return:1
Certificate chain
0 s:C=US, L=Eglin AFB, O=U.S. Air Force, OU=692nd CYOS, CN=SIL-NTFY
i:DC=DOM, DC=MEL, CN=SIL-SCA1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 3 21:22:12 2025 GMT; NotAfter: Jun 3 21:22:12 2027 GMT
-----BEGIN CERTIFICATE-----
MIIFoTCCA4mgAwIBAgITfAAAAB1W/+7hH2C0+wAAAAAAHTANBgkqhkiG9w0BAQsF
ADA9MRMwEQYKCZImiZPyLGQBGRYDRE9NMRMwEQYKCZImiZPyLGQBGRYDTUVMMREw
DwYDVQQDEwhTSUwtU0NBMTAeFw0yNTA2MDMyMTIyMTJaFw0yNzA2MDMyMTIyMTJa
MGIxCzAJBgNVBAYTAlVTMRIwEAYDVQQHEwlFZ2xpbiBBRkIxFzAVBgNVBAoTDlUu
Uy4gQWlyIEZvcmNlMRMwEQYDVQQLEwo2OTJuZCBDWU9TMREwDwYDVQQDEwhTSUwt
TlRGWTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMthLlmRF6kqBwds
uBga7Z31/sb6pSUtUw29RHJdskPbTfm2pAYbssrIQMpPM19J16vYvZyyaEFm2rk7
4dLQwwavP90Y0wBIp2cwsxAQynkyw0HymS2aQvr7M7kPJN15sRgObzEVVjcHV19n
K4HiiuI2uOecbvTS/o3qbk3WDVZJ4TgUZ7kXNAINOUn2HVXpolXNkPhtJOyRQxFp
KBMAbWBcszcQLL1DgkbSR2KTeUSMNutfTNweU/GSgpmllCD3AQ/WuTY/TDpS+2XK
qaGllULNFXP+nzg2TafL+opy7Dm5QnCFmEPSCVYo6nby6S/nhHMaao6a4D1yjWdf
2sjdbjECAwEAAaOCAXMwggFvMDwGCSsGAQQBgjcVBwQvMC0GJSsGAQQBgjcVCIOk
qDmzq12GrZ8Lh5X0U4GS7n1tgpnqDoPk+AICAWQCAQkwEwYDVR0lBAwwCgYIKwYB
BQUHAwEwDgYDVR0PAQH/BAQDAgWgMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUH
AwEwHQYDVR0OBBYEFG993G8N8lyOt9iW79E+Vo1CozljMCUGA1UdEQQeMByCCFNJ
TC1OVEZZghBTSUwtTlRGWS5tZWwuZG9tMB8GA1UdIwQYMBaAFJA+sMB6UslPSCja
j9IICftK6DX7MDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9wa2kubWVsLmRvbS9w
a2kvU0lMLVNDQTEuY3JsMFAGCCsGAQUFBwEBBEQwQjBABggrBgEFBQcwAoY0aHR0
cDovL3BraS5tZWwuZG9tL3BraS9TSUwtU0NBMS5NRUwuRE9NX1NJTC1TQ0ExLmNy
dDANBgkqhkiG9w0BAQsFAAOCAgEAGEX6XM4/yJ9PwejQsHjxlzPWBi4BpNdCwJli
TVkhxI8H1tAdPUypfDih3QWSsn54UsGb8qqcvA6nNOHgOOx/nqR3IexKrYDzxELX
VOXj/LZJ4MNGw+oBI8qZCPxlYWz8QTmfbhsrVbR4FTXl4I1Olrd3TfDjhVMpkenr
iDbU/r9P3tI78NKcCZQSc/Aa/a30d4xRakCDvdM/i7nSwW9MrTMEBpxHblUhRUpW
CfvDjbT21HW1ovEw/JUTpS9ObRy5D1PUYZ1GTtCH3AySNZSIF5+9XGUHltnMvQyI
zxFUGRfVxdqgIr2+m0gby2NmbnkpzCYM4CzJtFLUI4Nqpp1+1nMgBlsYzxjNAOmd
+vzCrt/et0xEIqPpXWZ9JQD9naxzlIE0L97SFXSd9DC6NEdE13F++jgYP4QhIlA2
Hy6hqXgDBTLgPWkkyQlLur60ovAkB1nR8RPjCGGU3FNGvXXBXhWZUBjtQHQu6zpr
5fCILOJOzwjOX6T3Q5mwHyy2g3dFqMMxsK9tZuhdcH9Udx3GYLao/mvT1pHS5BA1
rdAa1Uj6f5BBLfiLXSEhyJZDaqIUBfKWD+Sm4Xz4abLI/B88GUwhsZD1INFMurW0
dsMd2iKCvANsq2zhk7BrCyT/1kWWvetCToxO8RrvIq3/hM1vTD1kxgtomQQquZ9l
MKIXX8I=
-----END CERTIFICATE-----
Server certificate
subject=C=US, L=Eglin AFB, O=U.S. Air Force, OU=692nd CYOS, CN=SIL-NTFY
issuer=DC=DOM, DC=MEL, CN=SIL-SCA1
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
SSL handshake has read 1985 bytes and written 395 bytes
Verification error: unable to verify the first certificate
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_128_GCM_SHA256
Session-ID: 61D3E90EDE046B4376CA7A5063D75CD4A631B9BCCFAC20CC74981810405251F5
Session-ID-ctx:
Resumption PSK: 63D69DC371922A0E3E0B4E709873F3E87FDA4D7DE0EB5553E3A022305CEBFB98
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 604800 (seconds)
TLS session ticket:
0000 - db c3 e9 a1 1d aa f3 fb-d5 ba 04 77 cb 4a d3 56 ...........w.J.V
0010 - fe a3 0b 63 b5 88 ce 5f-08 7d 39 e7 0f b4 51 0c ...c..._.}9...Q.
0020 - 0e dd 1d 09 5d 86 94 5e-00 03 5c 31 d7 14 42 92 ....]..^..\1..B.
0030 - e8 b8 ed a8 e1 3d a5 fc-5c c3 eb f1 b1 66 7f 91 .....=......f..
0040 - 51 f9 eb f8 61 eb b7 09-0a 9f 66 fe 59 10 60 1d Q...a.....f.Y..
0050 - 13 74 bd 5c e7 a4 33 db-e0 07 4a c7 9c c6 06 24 .t...3...J....$
0060 - 3a 74 7d 86 94 d7 ed 53-0c :t}....S.
read R BLOCK`
@Aetherinox commented on GitHub (Jun 5, 2025):
Maybe I'm misunderstanding something as to where the issue is.
Are you referring to your personal self-hosted copy of Ntfy? Or something within this ntfy desktop app. Because once you set up Ntfy-desktop with your instance URL in the settings, the electron wrapper will go to your self-hosted ntfy server. The SSL certificates for the website are handled between your webserver and whatever client you're using to view your self-hosted web instance (in this case, it would be my ntfy desktop app).
My ntfy desktop app just fetches whatever is webserver is getting from the host, and the certs are managed by the self-hosted copy of Ntfy you are running.
How you set up the SSL certs for your ntfy self-hosted server entirely depends on which method you're using to host it. Ntfy provides a large number of documents here:
If you are using a reverse proxy such as Traefik, then you'll need to add the SSL certificates to Traefik in the dynamic config .yml file for Traefik and then give Traefik a restart.
I use Traefik, so I configured Ntfy server through Traefik to use my self-hosted SSL certs, and then in the Ntfy Desktop app, I set the instance URL to my self-hosted copy, and then this app uses the SSL certs if they are announced by the webserver and traefik.
Adding your SSL certs to your computer cert store is one part, but the server itself needs to announce that it has the certificates which are going to be given out to the clients upon connection.
Once you completely configure your certificates between the web server you are using, and your self-hosted ntfy server; once you use my desktop app to view your instance, it will pull the ssl certificates from the webserver.
My desktop app doesn't need to have anything configured to use SSL certs, it is 100% done from the server ntfy is being hosted on.
@shooolme commented on GitHub (Jun 5, 2025):
Let me start off by thanking you for your help. Hopefully I can clarify. I'm using a self hosted instance of the ntfy-server, installed on Ubuntu, with no proxy. I've cut certificates and configured the server to use them. I can browse to the server and receive notifications fine while using a web browser. However, when trying to use the ntfy desktop app, I cannot set the URL to my instance of ntfy-server. The desktop app is almost acting like its using a different certificate store. Does the desktop app require the use of a proxy like traefik instead of getting the server certificate directly from ntfy-server?
Setting URL to https://sil-ntfy.mel.dom
Setting URL to http://sil-ntfy.mel.dom
Navigating to https://sil-ntfy.mel.dom in the Edge Browser
@Aetherinox commented on GitHub (Jun 5, 2025):
No, the desktop app doesn't use any self-injected SSL certs.
Ah, I see the error at the bottom. Forgot I added that.
I assume http://sil-ntfy.mel.dom/ is a network only domain that is not accessible outside your local intranet correct? If so, are there any special Edge settings you've set in order to access the domain? Because that specific error is triggered by:
All it's attempting to do is just ping the URL so that it can load it. Which means for some reason, the application cannot see the path to the domain like your browser can.
If you open up the developer tools (in the menu) try setting the instance URL again, and then as the page loads / error shows up, see what's spitting out in the dev tools "Console" tab.
Because I have my own local domain that is not available via the internet, and I use this app on that local domain and it loads fine. However, I have it set up through Traefik, and I let that application manage all of my network routing / SSL certs.
@Aetherinox commented on GitHub (Jun 5, 2025):
Side note, just because I'm curious, can you open the
index.jsfile and find the following lines:github.com/Aetherinox/ntfy-desktop@4bd7a7df4e/index.js (L466-L479)Change all of that code to:
Sort of wondering if your domain is just set up in a way where it's acting weird. Then re-run the app. The
loadUrlfunction being called is built into electron. So it's not even a custom coded function I have control over.The code is in two spots, one for when you set the instance URL, and the other for when the window is loaded. The other one is:
github.com/Aetherinox/ntfy-desktop@4bd7a7df4e/index.js (L814-L827)Needs to be cleaned up, but there were other important features to work on at the time.
@shooolme commented on GitHub (Jun 5, 2025):
Rock on! Its working for me now.
@Aetherinox commented on GitHub (Jun 5, 2025):
So wait, that one change in the code, and your page loads fine now?
If so, I need to go read Electron's API, because I never read that the function had any conditions as to it not working. Going to have to run to Google.
@shooolme commented on GitHub (Jun 5, 2025):
Yes, its receiving notifications as well! However, I do see this in my PowerShell console though
@Aetherinox commented on GitHub (Jun 5, 2025):
Ok, it's just yelling about needing a promise (try/catch) on
GetMessageData. Odd that I never got that. But it shouldn't break anything, it just won't know what to do if it ends up failing, which that function shouldn't do based on the conditions.I'm going to do some digging with loadUrl / electron, see if I can come up with a test, and then I'll throw a promise in.
Checklist
@EuropaServ
GetMessageDatawin:loadUrlnot working on some localhost servers@BinaryServ commented on GitHub (Jun 5, 2025):
@Aetherinox I have started tracking the progression of this ticket.
@Aetherinox commented on GitHub (Jun 6, 2025):
So, just so it works for everyone, I've opted to move things around. I added a new setting.
This pretty much bypasses verification and allows you to connect to a local copy of NTFY.
@Aetherinox commented on GitHub (Jun 6, 2025):
Alright, I've added the new setting, and I added a try/catch.
There's still quite a bit of code to clean up and stuff I want to re-do, but at least with this setting, you don't need to go modifying code anymore.
Sometime soon I'll work on a pre-compiled copy being built through Github workflow, so people don't have to run node.
A few other bugs I fixed, damn hotkeys weren't working, and developer console.
@Aetherinox commented on GitHub (Jun 8, 2025):
All of the issues in this ticket have either been resolved, or will be resolved in the new update. If you have any issues in the future, let me know.
@Aetherinox commented on GitHub (Jun 9, 2025):
Just an update. pre-built binaries are now available in the Releases section of the repo.
The changes I posted are in this release.