Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certificate error? #922

Open
ntn-x2 opened this issue Jan 30, 2022 · 10 comments
Open

Certificate error? #922

ntn-x2 opened this issue Jan 30, 2022 · 10 comments

Comments

@ntn-x2
Copy link

ntn-x2 commented Jan 30, 2022

When trying to run any command from within rust/generate_message, like cargo run load_metadata -n westend, I get the following error:

Error: "Fetching error. Could not make rpc call at wss://westend-rpc.polkadot.io. Networking or low-level protocol error: Failed to load system certs: 0"

I cannot find the root of the issue, and since I have not seen anyone else complaining about it, I assume it's something additional I need to configure on my machine (M1 Macbook Pro)?

@Slesarew
Copy link
Contributor

Hi. I've seen this before, it's something related to system networking or general network availability state. Although when I saw this error previously, it was gone when I tried re-running exactly same command later. Might be something to do with DNS gremlins or something along the lines (I've seen wrong IP resolved on these addresses), sorry it's not more verbose.

Please let me know if it persists. If it does, I'll try to make output more verbose. As workaround (temporary?), I can recommend either trying different network connection or if that's not an option - you can download .wasm file from tagged release and generate all the things from it using same generate_message tool

@Slesarew
Copy link
Contributor

"failed to load system certs" indicates something is wrong on system level.

Another thing to try - try fetching metadata for other networks and/or other endpoints for westend.

@Slesarew
Copy link
Contributor

After some research I've found possible solution: try going to Application>Utilities and look around in Keychain Access; the certificates in question should be there; maybe you don't have correct ones - usually system should fetch them on its own, but worth checking.

@ntn-x2
Copy link
Author

ntn-x2 commented Jan 30, 2022

Hey, update. I tried westend, the example Dock, and also KILT, none of them succeeded. Tried different networks, different configurations (VPN on/off, custom DNS on/off), no luck. I could not find anything suspicious in the keychain either.

@ntn-x2
Copy link
Author

ntn-x2 commented Jan 30, 2022

Plus, I never had issues connecting to any of those RPC endpoints previously, via simple command-line scripts.

@Slesarew Slesarew self-assigned this Jan 30, 2022
@ntn-x2
Copy link
Author

ntn-x2 commented Jan 30, 2022

It works if I run the executable with sudo, which is definitely not secure. But it might have to do with permissions to access system certificates, somehow. Not sure. Might be worth investigating though...

@Slesarew
Copy link
Contributor

Just checked with the only macbook (MacBook Pro, old processor arch) I have (the one used to make Signer), it works nicely without root. I'm almost sure it's something about system setup, please let me know if you learn anything more, a reasonable solution has to get into FAQ. I'll ask around folks with other M1s what's their experience.

@Slesarew
Copy link
Contributor

Found this thread, they are dealing with somewhat similar issue. Again, most probably something seems to be forbidden for cargo called by user.

rust-lang/cargo#6757

Thus, we should try to figure out what network settings could be blocking this. Another related thing to test- instead of cargo run we could first run cargo build --release on generate_message and then just try same commands with cargo run replaced with binary name.

@ntn-x2
Copy link
Author

ntn-x2 commented Feb 6, 2022

Yeah, building and then running as two separate steps is a good workaround. Should I close the issue for now?

@Slesarew
Copy link
Contributor

Slesarew commented Feb 6, 2022

No, please leave it, maybe rename into something more relevant to what really happened. It shouldn't be closed until it's in docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants