I read in the following passage in this DigitalOcean article, concerning HTTP/2:

Even though HTTP/2 does not require encryption, developers of two most popular browsers, Google Chrome and Mozilla Firefox, stated that for the security reasons they will support HTTP/2 only for HTTPS connections. Hence, if you decide to set up servers with HTTP/2 support, you must also secure them with HTTPS.

Okay, let's say I install OpenSSL on port 443 and use TLS to wrap each packet with an encryption wrapper.

Will I still have HTTPS if I didn't setup an SSL certificate for each domain and associated it with OpenSSL? and if I will, will this be valid in Chrome/Firefox?


I feel like a primer on how TLS works might answer some of your questions. We have a canonical question here for that:

How does SSL/TLS work?

The part that's relevant for your question is that in order to do TLS, the server must have an encryption private key.

This key is private, meaning that no copies of the key should exist anywhere else, so we can use it (and the corresponding public key) to uniquely identify the server.

Consider a browser visiting your site for the first time - how does it know that it's talking to the real yourdomain.com and not an attacker trying to spoof your site?

That's where certificates come in: a Certificate Authority issues a certificate to say "we have verified that this public key does in fact belong to the legitimate owners of mydomain.com. Browsers take this as proof that they are talking to the authentic server for that URL / domain.

Browsers require every server to present a valid certificate matching the domain requested for each TLS connection, and (in theory at least) each server should be using a unique keypair and certificate.

TLS is a bit tricky to wrap your head around, and getting a cert from a CA and installing it properly can be a bit fiddly, but if you follow your guide you should have it up and running in a day or two.

| improve this answer | |
  • Thx Mike. I think I still mis this: If the certificate prevents spoofing, why is it needed to encrypt the packets with TLS? I mean, one could send and receive data encrypted, whether the site site is spoofed or not (example.com or example1.com that look 99% like the former). Both example.com and example1.com could have their packets wrapped and the user could fill in sensitive data into both of them. So I miss either how certification is necessitated for the technical process of encrypting, and also, how it actually prevents spoofing (not our topic but your might want to elaborate a bit). – user123574 Aug 5 '17 at 4:02
  • I didn't "spoofing" in the link. – user123574 Aug 5 '17 at 4:03
  • @Benia You are right that encryption and anti-spoofing (done by digital signatures) are completely independent and not necessary for each other. You could design your own protocol in which you can do one without the other, but the people who designed TLS decided that you always need both. There was no technical reason why it needed to be this way, only that they wanted "your connection is secure" to mean that you are talking to the correct server, and that nobody can read / modify your traffic. – Mike Ounsworth Aug 5 '17 at 4:07
  • That said, encryption without authentication isn't really very useful. Think of it this way: you have a secret that you put in a safe, but if you're willing to tell the lock combination to anybody who asks, then it's not really a secret is it? – Mike Ounsworth Aug 5 '17 at 4:11
  • 1
    There are also different "levels" of green lock. It's becoming more and more common to see a company name ([Microsolf, inc], or [Bank Of America]) in the green lock. This is nearly impossible to spoof because in order to get that certificate, you need a signed letter from the CEO of the company. – Mike Ounsworth Aug 5 '17 at 18:09