Https

Running multiple services on a single virtual machine (VM) can quickly become a logistical challenge, particularly when it comes to managing access and ensuring security. A reverse proxy, therefore, becomes a central piece of infrastructure. Traefik stands out among the options, offering native Docker integration, automatic HTTPS using Let’s Encrypt, dynamic routing via labels, and minimal manual configuration. But while Traefik boasts many advantages, achieving a clean, production-ready setup requires more than a simple “it works” configuration. This article will walk through structuring a robust Traefik setup on a VM, highlight key configuration choices, and delve into a subtle trap involving basic authentication and Docker Compose that could easily trip you up. ...

If you have worked with TLS certificates, you may have encountered files with the extensions .pem, .crt, and .key. You might be wondering what they are, what differences they have, and how to use them effectively. The good news is that these formats aren’t as complicated as they seem once you understand the basics: PEM, CRT, and KEY are not different certificate types — they are different ways of packaging the same data. ...

Let’s say we have a reverse proxy. The incoming request is HTTP, the target server hosts HTTPs APIs with self-signed TLS certificates. It is very common that we change the URL host or path with reverse proxy, so that the request can be directed a different API. However, in this case, we also need to add the self-signed certificates in reverse proxy. The below example will show how to achieve it. ...

Another way to ask this question is what will happen after typing a https url in your web browser? The browser requests secure page (HTTPs) from a web server. The server sends its public key with its SSL certificate, which is digitally signed by a third party, or we call Certificate Authority, or simply CA. Once the browser gets the certificate, it will check the issuer’s digital signature to make sure the certificate is valid. As we know, a digital signature is created by a CA’s private key, and the browser, either Chrome or Firefox, is previously installed with many major CA’s public keys. Thus, digital signature can be verified. Once the certificate’s signature is verified, the digital certificate can be trusted. The browser creates one symmetric key, or a shared secret. It keeps one and gives a copy to the web server. However, the browser does not want to send the shared secret in plain text. Therefore, it uses the web server’s public key to encrypt the secret, and then sends it to the web server. When the web server gets the encrypted symmetric key, it uses its private key to decrypt it. Now the web server gets the browser’s shared key. From now on, all traffic between the client and the web server will be encrypted and decrypted with the same key, a symmetric key.