diff options
Diffstat (limited to 'posts/curl-and-the-tls-sni-extension.rst')
| -rw-r--r-- | posts/curl-and-the-tls-sni-extension.rst | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/posts/curl-and-the-tls-sni-extension.rst b/posts/curl-and-the-tls-sni-extension.rst index 1753dd5..dc03c2d 100644 --- a/posts/curl-and-the-tls-sni-extension.rst +++ b/posts/curl-and-the-tls-sni-extension.rst @@ -12,14 +12,14 @@ via HTTP and HTTPS. You own the NS domain *example.org* and it points to your machine. -You are using virtualhosts to manage your different websites. In other words, -the *Host* HTTP header is analysed by your webserver so it can make the +You are using virtual hosts to manage your different websites. In other words, +the *Host* HTTP header is analysed by your web server so it can make the decision of which website it is going to serve. -However, these virtualhosts are not pointing to your machine yet. Only +However, these virtual hosts are not pointing to your machine yet. Only *example.org* does. -Here is an excerpt of a Nginx configuration using three virtualhosts: +Here is an excerpt of a Nginx configuration using three virtual hosts: * example.org (it will be served by default because of the **default_server** directive), * vhost1.example.org, @@ -87,7 +87,7 @@ Let's try that out with HTTP:: default The default website is served because 172.31.99.217 does not match any -virtualhost *server_name* directive:: +virtual host *server_name* directive:: $ curl http://vhost1.example.org curl: (6) Could not resolve host: vhost1.example.org @@ -143,21 +143,21 @@ Now let's see what happens if we use the HTTPS version:: $ curl https://176.31.99.217 curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217' -The second command fails because the default webserver answered with its +The second command fails because the default web server answered with its certificate, but it is not valid for *176.31.99.217*, only *example.org*. This is a normal behaviour. We can solve this issue by creating a certificate valid for *example.org* and *176.31.99.217* for example. -But what about requesting our virtualhosts ? Well, pretty much the same happens -as it did before (unless you didn't clear your */etc/hosts* file):: +But what about requesting our virtual hosts ? Well, pretty much the same +happens as it did before (unless you didn't clear your */etc/hosts* file):: $ curl https://vhost1.example.org curl: (6) Could not resolve host: vhost1.example.org $ curl https://vhost2.example.org curl: (6) Could not resolve host: vhost2.example.org -The good news is: it will still work if you modify your */etc/hosts* file (huray):: +The good news is: it will still work if you modify your */etc/hosts* file (hurray):: $ cat /etc/hosts 127.0.0.1 localhost @@ -183,9 +183,9 @@ website to serve. Nevertheless, when HTTPS is being used, the first thing that the user agent and the server have to do is negotiate the certificate. At this point, the HTTP headers have just NOT been sent yet. -So how does the webserver decide which certificate to send ? +So how does the web server decide which certificate to send ? -.. note:: 10 years ago, that was simply not possible. The webservers had to send the same certificate for every virtualhost behind the same address and port. +.. note:: 10 years ago, that was simply not possible. The web servers had to send the same certificate for every virtual host behind the same address and port. Nowadays, there is a TLS extension named **SNI**, which stands for Server Name Indication, which has been created to address this issue. SNI is supported |