ISP blocks ports 80 and 443. Can I still get an encryption certificate?

My service provider won’t open up ports 80 and 443 (without charging an extra fee.) As a result, I can’t seem to use Let’s Encrypt - I get a timeout error when starting up.

Is there a workaround to get an encryption certificate?

Best Wishes,

Derek

You can use the DNS challenge of Let’s Encrypt instead of http/https challenge.

This feature is currently not supported by yunohost, so you had to configure it your self. Do you use a common domain name or a noho.st nohost.me nane ?

I use a nohost.me name! Is there a tutorial I could follow?

D

Hm if you’re using a nohost.me then you wont be able to manually edit the DNS zone, so that doesnt work unfortunately :confused:

On the other hand, you should also question how relevant it is to self-host at home if your ISP doesn’t let you control port 80 / 443 … that mean that you’ll have to tell people to go to your website with a custom port, which is really inconvenient. And if you’re the only user, then is it such a burden to add exceptions for the self-signed certificate ? (Just trying to get a better idea of your exact use case here)

Hi Alecks,

Good questions. The main concern is security. I confess I’m not an expert in this, but as I understand it using self-signed certificates leaves the device open to man-in-the-middle attacks. This is an issue because I occasionally have to travel to areas that have a level of government monitoring of the internet and I’d like to have my connection be secured.

That being said, I think I’m going to go down the route of getting a custom domain. I didn’t realize how cheap it would be! This will, hopefully, enable me to at least get a let’s encrypt certificate. I still am not thrilled about having my ip address exposed but some day I’ll get the VPN Client app figured out.

Not really, but it’s easy to get lost in all the security thing if you are not used to it or if the technical bits are a bit fuzzy. So : yes and no.

Basically the certificate’s job is only to address the problem of authenticity, which is "Alice and Bob want to talk to each other through the internet. But they know Eve is malicious and might be intercepting messages and altering them so that Alice thinks she is talking to Bob, but Eve is actually intercepting messages and messages.*. That’s a man-in-the-middle attack, yes. But to solve this, Alice and Bob use certificates. At some point, Bob sends his certificate to Alice, such that only messages encrypted and signed with this certificate should be recognized as ‘Bob’s messages’. Hence Eve can’t impersonate Bob because she doesn’t know the private key (Only Bob does).

But on the internet, it’s a tricky matter. You (Alice) want to talk to thousands of different Bobs (your bank, your husband, your favorite cat website, and the yunohost forum). You cant meet them in person to get their certificate and be sure that those are indeed their certificate (and not Eve sending you a certificate to then impersonate Bob !)… So how do you solve this ? Well, first your browsers come packaged with a handful of “trusted certificates” from “big, trustable companies” a.k.a certificate authorities. Among those are, for instance, Google, Microsoft, and (doing a shortcut) Let’s Encrypt.

When you visit Bob’s website, he’ll show you his certificate. And his certificate is actually signed by one of those CA (Certificate Authority). And because you trust those CA, you trust that they checked that it’s indeed “the real Bob” which is behind this certificate. Hence, you trust the certificate you get. Eve wouldn’t be able to impersonate Bob, because that would mean a CA didnt do her job of checking the person behind the certificate… (Spoiler : this actually happened several time in real life, with dramatic consequences)

So what are self-signed certificates ? Those are certificates signed by your own server … hence they don’t come with any clue that Microsoft or Google or Lets Encrypt saying that the certificate is from who it claims to be from … For instance, you could forge a certificate for google.com. But nobody would trust that certificate, except maybe you because you know what you did…

But in a context where you are the only user of your server, it’s quite fine to just accept a self-signed certificate for your.domain.tld, because you know where this certificate comes from. And once you accepted it, it should be okay. Eve won’t be able to man-in-the-middle, because if she did, she would have to use a different certificate crafted and validated by a CA. But she can’t do that (except if the CA is evil, again).

I think I see. So OTHER people don’t know that my I.P. address is legitimately the website they are looking for, but since I do, no third party cert is needed?

It’s not really about the adress IP. Because even if I send a message to Bob at IP 111.222.33.44, this message can still be intercepted by Eve which can send impersonate Bob. Rather, the certificate kinda solves the problem of “how to exchange cryptographic keys without having to meet, and still trust the key [because Eve could man-in-the-middle during the exchange]” by trusting some third parties.

But in the context of “I just set up my server and it has a self-signed certificate”, you don’t really need a third party because you know what you are doing and this is your server. There is very little probability that you got an Eve on your local network (though you could increase the tin-foil-hat level here if you wanted :stuck_out_tongue: ) so that’s fine to just accept it.