Cause:

The blog has been serving on Github. IO before, because github access speed is really slow, so I plan to migrate to buy ali cloud server.

However, when I resolved my domain name to ali Cloud server, WTF returned a page of Ali Cloud, asking me to put on record on the server.

For the record? emmm… Acceptable. I clicked on it, and here’s what I found…

20 working days! Can you still let people have fun!

So how do you get around that annoying filing? I find that when I just access via IP, everything works fine; When I use domain name access, it will return to ali Cloud record page. And my domain name is in Tencent cloud buy, so you can conclude: this is an HTTP hijacking incident.

Ali Cloud hijacked my HTTP request, judging that it was accessed through the domain name, and tampered with my HTTP response. How to solve it? HTTPS solves this problem perfectly.

I might add that HTTPS encrypts the data and prevents middlemen from modifying it. It is often found that some websites are implanted unicom advertising, the actual operator modified the response. If you switch to HTTPS, the carrier won’t be able to tamper with your response.

Let’s Encrypt

The next step is to make the service accessible via HTTPS.

The problem is that HTTPS requires a certificate that the browser trusts. At this point, Let’s Encrypt, as a free, widely trusted certificate issuer, was naturally my first choice.

But, just then, I stepped in two holes.

Cloud domain name resolution

Let’s Encrypt is an external CA, so you need to select the default line type. At that time, I chose domestic instead of knowing it, and it took some time to find out that the domain name could not be resolved overseas.

Ali Cloud tampered with HTTP responses

Let’s Encrypt issues you a certificate that proves that the domain name is yours. There are two ways, one is webroot, where you serve a let’s ENCRYPT specified page on port 80 of the server where your domain name is resolved. After I visit http://www.example.com/letsencrypt, return the need is to let ‘s encrypt the specified text. That’s how I started, using the Webroot mode of Certbot from Let’s Encrypt. It was found that the response returned by TM was hijacked by Aliyun. I realized I’d come full circle and come back.

Fortunately, Let’s Encrypt provides an alternative: domain name resolution for a specified TXT. This is much easier to do, like the following configuration of domain name resolution can be:

Then you can get the certificate that let’s encrypt issued to you in /etc/letsencrypt/live/domain/path.

In nginx configuration

Finally, use Nginx to serve your service. Nginx configuration:

server {
        listen       443 ssl http2 default_server;
        listen[: :] :443 ssl http2 default_server;
        server_name  _;
        root         /root/workspace/eltonzhong.github.io;

        ssl_certificate "/etc/letsencrypt/live/therollingstones.cn/cert.pem";
        ssl_certificate_key "/etc/letsencrypt/live/therollingstones.cn/privkey.pem";
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
        ssl_ciphersHIGH:! aNULL:! MD5;ssl_prefer_server_ciphers on;
}
Copy the code

The end

Overall or quite simple, as long as not like me to step on Tencent cloud domain name resolution route pit. Thanks for reading, if you find it helpful, can you click a like ~ thanks!