Closed SkyLined closed 8 months ago
Note that I can manually download an image and ask imager to burn it as a work-around.
Others have experienced this issue as well.
That user chose to use other software to burn the image, suggesting that this issue may be under-reported.
What I do know is that the IP address 176.126.240.86 responds to ping
That is the download server that do is the final target. It is however complaining that it cannot contact the revocation server that is used to double check that our SSL certificate is in good standing and has not been revoked.
Can you reach http://r3.o.lencr.org/ ?
No, I could not reach it: my pi-hole DNS server resolved it to 0.0.0.0. I found out I manually added it to the blocklist. I assume I did this after I noticed devices connecting to it for no obvious reason (I tend to lock things down hard).
After removing the blocklist entry, it resolves in DNS and the issue disappears. Thank you for the help!
If time allows, I would recommend improving the error message to provide additional details such as the domain name for the revocation server that cannot be contacted, as that might help others debug this.
If time allows, I would recommend improving the error message to provide additional details such as the domain name for the revocation server that cannot be contacted, as that might help others debug this.
I am afraid that is not trivial for us to do. Imager outsources connectivity to libcurl who in turns outsources TLS to system libraries like schannel, OpenSSL or GnuTLS depending on operating system.
Due to all the abstractions involved all Imager gets to hear on error, is a generic error code like CURLE_SSL_CONNECT_ERROR indicating SOMETHING tls related failed, and the textual error message coming from the system library. The textual error message not only differs by system library, but can also be different depending on the language of the system, so may not always be in English either. So it is hard for Imager to determine exact error and improve the message coming from the library...
I had this issue and solved it by disconnecting my VPN.
I had this issue and solved it by disconnecting my VPN.
+1. Had the same error and resolved by disconnecting my VPN.
Describe the bug While attempting to write any Raspberry Pi OS to storage, I get the following error popup:
Windows Error 0x80092013 is CRYPT_E_REVOCATION_OFFLINE.
I do not know how revocation servers are implemented, so I cannot provide detailed info. What I do know is that the IP address 176.126.240.86 responds to ping and has a HTTP server that redirects to the secure https://www.raspberrypi.org. It also has a HTTPS server that provides a certificate is for
*.raspberrypi.org
. When sending a request to the HTTPS server with aHost: www.raspberrypi.org
header, I get a 200 OK response. In another attempt, I got the IP address 46.235.227.39, which has the exact same properties.Given that I have had this issue for a few weeks now, I suspect there's something about my set-up that is causing it; otherwise more people would have reported it.
To Reproduce
My system:
Expected behaviour Download and write the OS.
Screenshots or video See above.
Desktop (please complete the following information):
The name of the OS you are trying to write The problem appears to affect all Raspberry Pi OS & OS Lite versions (32- and 64-bit) for all devices, but I have not exhaustively checked all of them.
Are you using OS Customisation? Yes and No: tried both with the same result.
Additional context N/A