I have a question about HTTPS requirements for remote services. I would like to be able to provide updates for the self-hosted version of my extension I2P in Private Browsing from within the I2P network itself. In order to do this I would have to reach out to a remote service at a .b32.i2p
hostname. Most of the time we haven’t used HTTPS for these domains because b32.i2p
hostnames are self-authenticating and self-encrypting just like .onion
hostnames.
I can configure the update server to use HTTPS on the .b32.i2p
hostname, but the remaining problem is basically, I’m not Facebook. I can’t get a real, signed, CA-issued certificate for my I2P hostname. There’s no guarantee that there would even be a non-I2P site where the extension would be updated which could apply for a certificate that could eventually be used to sign the .b32.i2p
hostname. The bottom line is that I can only use a self-signed certificate.
So, my questions: Does a self-signed certificate for a hidden service hostname satisfy the requirement of “Real, in-browser HTTPS?”
If not, could it be made possible for self-hosted extensions to deliver a self-signed certificate which they can indicate within in their manifest.json
, which indicates that the self-signed certificate is valid only for the domain used in the update_url
field? That would enable people who use browser extensions like ours to integrate with hidden service networks, the distributed web, etc. to distribute in-network updates in a way which is straightforward to them and to the users, and would not involve making a self-signed certificate valid for things that it should not be valid for(By encouraging users to install certificates or make unwise exceptions). Changes to the certificate could be detected by the automated addon scans and you could contact the extension maintainer to confirm it was deliberate?