invalid SSL cert for `*.packages.shiftkey.dev`
nuernbergerA opened this issue · comments
Hey @shiftkey,
it seems that your ssl cert for https://apt.packages.shiftkey.dev/ is the default azure one and causes an error for apt
Error: https://apt.packages.shiftkey.dev/ubuntu any InRelease
Certificate verification failed: The certificate is NOT trusted. The name in the certificate does not match the expected. Could not handshake: Error in the certificate verification. [IP: 13.107.246.44 443]
Facing a similar issue when installing GitHub Desktop using @shiftkey package feed
Similar issue on RHEL too.
Errors during downloading metadata for repository 'shiftkey-packages':
- Curl error (60): SSL peer certificate or SSH remote key was not OK for https://rpm.packages.shiftkey.dev/rpm/repodata/repomd.xml [SSL: no alternative certificate subject name matches target host name 'rpm.packages.shiftkey.dev']
Error: Failed to download metadata for repo 'shiftkey-packages': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Same issue in RPM repo
Just thought I would add that "invalid" in this case does not mean "expired," as tends to be the case when TLS goes awry and is what I expected to find when I myself encountered this issue just now. Rather, the Subject (Common Name) of the certificate no longer matches the domain name, instead being issued for azureedge.net rather than *.packages.shiftkey.dev. As the domain is also enrolled in HTST (good choice, BTW), the subject mismatch has completely disabled access to the domain. Hopefully this helps you to dig right into the meat of the problem when you have the time to troubleshoot it.
Thanks for maintaining such a useful resource for us Linux diehards out there. 👍🏻
Similar issue on Fedora Linux 40:
GitHub Desktop 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository 'shiftkey-packages':
- Curl error (60): SSL peer certificate or SSH remote key was not OK for https://rpm.packages.shiftkey.dev/rpm/repodata/repomd.xml [SSL: no alternative certificate subject name matches target host name 'rpm.packages.shiftkey.dev']
Error: Failed to download metadata for repo 'shiftkey-packages': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Ignoring repositories: shiftkey-packages
its joever 😭
Same here, Ubuntu 22.04.4 LTS. As @RogueScholar said, if you try to open the link in a browser (Firefox in my case), you see the following:
apt.packages.shiftkey.dev has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site.
The issue is most likely with the website, and there is nothing you can do to resolve it. You can notify the website’s administrator about the problem.
Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for apt.packages.shiftkey.dev. The certificate is only valid for the following names: *.azureedge.net, *.media.microsoftstream.com, *.origin.mediaservices.windows.net, *.streaming.mediaservices.windows.net
Error code: [SSL_ERROR_BAD_CERT_DOMAIN]
Hi there, i tried to do a simple sudo apt update && upgrade today and apt.package.shiftkey.dev denied being on a trusted certificate. here is a clip from my terminal.
do i need to fix/do/un-reinstall anything? Im not that deep into it to know exactly how to challenge such a problem, but it disturbs my otherwise fine working update and upgrade view and process. Tell me if you need more info.
The github-dektop is installed within
- Virtualbox@latest
- Guest Ubuntu 22.04@lateset
- Windows 11 hoste @latest
- Asus PC
as mentioned, if more info needed, feel free to ask. looking out for a fix. Workaround in the certification repo failed category didnt help much...
thx in advance, and i like github dektop on ubunt much, thx 4 that app port...:
Hit:9 https://ppa.launchpadcontent.net/flatpak/stable/ubuntu jammy InRelease
Hit:10 https://ppa.launchpadcontent.net/ondrej/apache2/ubuntu jammy InRelease
Hit:11 https://ppa.launchpadcontent.net/ondrej/php/ubuntu jammy InRelease
Get:1 https://packages.microsoft.com/repos/code stable InRelease [3’590 B]
Ign:7 https://apt.packages.shiftkey.dev/ubuntu any InRelease
Ign:7 https://apt.packages.shiftkey.dev/ubuntu any InRelease
Err:7 https://apt.packages.shiftkey.dev/ubuntu any InRelease
Certificate verification failed: The certificate is NOT trusted. The name in the certificate does not match the expected. Could not handshake: Error in the certificate verification. [IP: 13.107.213.60 443]
Fetched 114 kB in 8s (13.5 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: Failed to fetch https://apt.packages.shiftkey.dev/ubuntu/dists/any/InRelease Certificate verification failed: The certificate is NOT trusted. The name in the certificate does not match the expected. Could not handshake: Error in the certificate verification. [IP: 13.107.213.60 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.
krakatoom@krakatoom-Desktop:~/Downloads$ ```
Please don't post me too comments...
There is nothing to be done on the client side. We have to wait for @shiftkey to fix thie
Please don't post me too comments...
There is nothing to be done on the client side. We have to wait for @shiftkey to fix thie
thanks for info. I am rather new to this, the main info was more my terminal sequence, i thought it could help. But I am glad to get more infos on what or how I can better interact in places like this. so if you can give me some advice, i gladly take it.
👋 Apologies for the delay - I've been on holidays the past couple of weeks so this had to sit broken.
This has now been restored and I'll do a bit of a write-up on the next steps when I have bandwidth to document this further.
Unsure if related but I am getting timeouts with DNF on Fedora on the rpm.packages.shiftkey.dev. I have been getting them the past few days.
Unsure if related but I am getting timeouts with DNF on Fedora on the rpm.packages.shiftkey.dev. I have been getting them the past few days.
Which DNS are you using? I cannot reproduce the issue (using Fedora 40 too).
Unsure if related but I am getting timeouts with DNF on Fedora on the rpm.packages.shiftkey.dev. I have been getting them the past few days.
Which DNS are you using? I cannot reproduce the issue (using Fedora 40 too).
Thanks. Looks like it was DNS. I use PiHole but it was not blocking the request. Any outside requests are forwarded to Cloudflare DNS and for some reason I was not getting through. If I switched to another public DNS it seems to work. Thanks!
Certificate is failing again in the RPM repo
Yep, the same issue has been revived.
Facing same issue on Ubuntu 24.04
: Failed to fetch https://apt.packages.shiftkey.dev/ubuntu/dists/any/InRelease Certificate verification failed: The certificate is NOT trusted. The name in the certificate does not match the expected. Could not handshake: Error in the certificate verification.
I haven't done this write-up yet so I'm gonna reopen this for now to remind myself to not forget this issue...
Hi @shiftkey, there was a post on reddit which wrongly claimed you were difficult to contact so I raised this concern on the upstream repo instead, that is the ticket at desktop#18963 which @sergiou87 closed about a day ago.
I won't repeat the whole ticket here, but this is the key to the problem:
Please let me know if there is anything I can do at my end to help with the diagnosis (e.g. if you suspect that my DNS is not returning the same IP as other DNS at other locations where the problem does not arise).
Just did a fresh 'apt update', got this response:
W: Failed to fetch https://apt.packages.shiftkey.dev/ubuntu/dists/any/InRelease
Cannot initiate the connection to apt.packages.shiftkey.dev:443 (2620:1ec:bdf::31). - connect (101: Network is unreachable)
Could not connect to apt.packages.shiftkey.dev:443 (13.107.246.31), connection timed out
So resolving to different IPv6 and IPv4 addresses (unsurprising if this is hosted on Azure), now timing out rather than returning a bad certificate.
BTW apologies for raising the completely unfounded supply chain suspicion - I was panicking because azureedge.net and microsoftstream.com looked to me like domains which I might see in a phishing scam, but I should have realized that windows.net was unlikely to be under hostile control.