I’m a new user to Manjaro and Linux systems in general, so I apologize if this issue is a result of me misunderstanding how to use or properly maintain the OS. This is a very specific problem that I’ve exhausted my immediate leads on and am not sure what to check next.
At some point in May, after deciding to move on from kernel 5.13, I installed kernel 5.15 but never actually started running it. I didn’t understand at the time that I had to use pacman multiple times before the new kernel would be used. I suspect that I left my system in a partially upgraded state until two days ago, June 9th, when I finally completed the upgrade and followed steps online to clear up disk space and perform system maintenance (I can’t post the links to these threads/wiki pages because my account is too new). I didn’t encounter any problems with the OS before doing the upgrade, and the upgrade process went smoothly.
Since finishing that upgrade, I discovered that everything worked normally except for when I open an IDE and try to serve an API that needs HTTPS. It tells me that it’s listening on https ://localhost:8990, but all attempts to fetch data from this address fails without making any connection.
I think it’s possible that this issue might be related to any number of the programs responsible for hosting or developing this project… but I know that it worked before upgrading Manjaro and it doesn’t work now.
I figured out that I could host the API on HTTP and it would work fine. I can also tell that connecting to HTTPS websites in a browser works with no issues (otherwise pacman itself would likely be broken). So I’m stumped as to the cause. I thought maybe it was an issue with openssl upgrading, but it looks like downgrading this package is a bad idea since so many things rely on it. I think it’s possible that some of the commands I ran while clearing up disk space could have changed something important, but the issue I’m having affects such a small part of the system that I’m really not sure.
What should I test to narrow this problem down? What might be some related issues?
Why not simple let the system take care of itself (It’s good at that) . At least that what I do. I always update, I always use the latest kernel (not experimentell, thats for pro). Easy with AUR. I have not any major problem since when I moved from Windows to Manjaro.
Latest kernel I use is 5.17.9-1
This is not caused by kernel but is a configuration issue.
Your dev environment is reponsible for for setting up your services.
I am building an API client which runs locally on https against both a local IIS and a staging environment using CORS - I can assure you - this has nothing to with kernel.
dotnet has a configuration tool to setup dev certificates
ss -tln shows me that it does actually listen on the port I’m using for HTTPS. If there’s a way to check how my browser is connecting to that local address, that might help me figure out what’s not working?
I’m wondering if it’s possible for the package updates to have caused the problem, and not the kernel update itself. My development environment and all of its certificates were working immediately beforehand. Then I performed a pacman upgrade, was told that kernel 5.15 would now be used, and restarted my PC. I then tested my development environment immediately afterwards and the only thing that was broken was the connection between the browser and my API.
For full transparency, here’s what my browser says:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://localhost:8990/api/user. (Reason: CORS request did not succeed). Status code: (null).
I believe this error has little to do with CORS: If I shut my API down completely and fetch from the same address, I get the same error. So it seems likely that the browser is just unable to connect to the endpoint.
I know that this problem is isolated to HTTPS because the API also listens on a different port for HTTP requests, and I get an actual response from the API when I fetch from that port instead.
This sounds more like a browser problem with the current. Did you tried to use a tool like curl to connect to it. Or a different browser (in this case older versions of browsers) of any kind?
That explains your issue - you need to configure the server to allow cors request from your specific browser url:port.
e.g.
https://localhost:7964
Your issue has zero-zilch-nada connection to any system updates - it is the configuration of the server you connect to - CORS policy is controlled by the server - the client has no say.
Using curl was a great suggestion. I believe I’ve solved the problem.
Firefox was giving me the same error when connecting to my API whether it was online or offline, which made the error look misleading. But curl confidently told me that my self-signed SSL certificate was the problem, and it only said this when the API was running.
The issue had to do with Firefox being upgraded and invalidating my self-signed SSL certificate. I discovered that I couldn’t re-assign my certificate or even generate and assign a new SSL certificate; something wasn’t being handled correctly by the browser. I had to invalidate my entire Firefox cert database by deleting the cert9.db file and rebooting the browser.
Other users in Mozilla forum threads have encountered similar problems in the past, I just managed to miss any of them in the searching I did before coming here.
I have to remove the soution checkmark - because what you did is not the solution.
The solution is to ensure you server presents a trusted valid certificate even if it is selfsigned and only locally trusted.
So all my pointers to your configuration was valid - the issue was you self-signed certificate which became untrusted after a browser update - that is what happens in real life.
When you put something into production - and your clients cannot connect because the browsers certificate chain has been updated - you cannot tell them - oh you have to delete all your browsers certificate chain.
It does sound like I would’ve mitigated this problem a lot faster if I had a better understanding of how a certificate is created and trusted. Just so I can understand this issue better in the future, I have a few questions:
If it’s normal for a browser update to cause a self-signed certificate to become distrusted, why did generating a new self-signed certificate and telling Firefox to accept it not solve my problem? Is there a better way to generate self-signed certificates for development environments that would allow the browser to update and automatically trust my old self-signed certificate?
The answer to the above question might be to change the backend’s CORS configuration, as you originally suggested. I’m unsure what to reconfigure, as nothing in the configuration is related to the browser’s version, and in development mode, the backend accepts all origins.
Worth noting: in production, my project does use a different certificate which is signed by a third-party. So at the very least, I’m not torturing users of the actual website.