From: "Peter Moylan" <ecs-isp@2rosenthals.com>
Subject: Re: [eCS-ISP] Getting started with Let's Encrypt
To: eCS ISP Mailing List <ecs-isp@2rosenthals.com>
References: <list-11323466@2rosenthals.com>
Message-ID: <67551B89.2030100@pmoylan.org>
Date: Sun, 8 Dec 2024 15:07:37 +1100
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <list-11323466@2rosenthals.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 07/12/24 17:33, Steven Levine wrote:
> In <list-11323402@2rosenthals.com>, on 12/07/24 at 01:28 PM, "Peter
> Moylan" <ecs-isp@2rosenthals.com> said:
>
>> Yes, in one way. I only have one server machine, with a single
>> external IP address, so all domains that I host will have to go on
>> the same certificate.
>
> This may work best for you and may be required for your webserve2
> implementation, but this is server dependent and not required in
> general. For apache httpd, each virtual host can have its own cert
> and private key.
>
>> (Unless I have missed seeing some detail, there is no way to know
>> which domain is being addressed until the TLS negotiation is
>> finished.)
>
> This does not seem to be the case for apache httpd.  I'd need to do
> some research to understand why.

If anyone knows the answer to this paradox I would love to hear it,
because this question has me greatly puzzled.

As I understand it, the sequence of events is:
1. The web client, knowing which domain it wants to access, uses a DNS
lookup to get an IP address. It then connects to that IP address.
2. The server sees the connection, and as a result it finds out the IP
addresses at both ends. These IP addresses are the ONLY thing it knows.
It has no domain name information.
3. The client sends a ClientHello message, starting the handshake
negotiation.
4. Client and server exchange several other messages, including the
certificate sent from the server to the client.
5. At the end of the handshaking, both client and server have switched
to encrypted communication.
6. The client now sends an HTTP command (probably GET). The parameters
of this command include a specification of which domain is being addressed.

Step 6 is the earliest point at which the server knows which domain it
is acting on behalf of. At that point, the certificate has already been
sent.

So how is it possible to have one certificate per domain, in a web
server that hosts several domains, but only has one IP address for all
those domains?

While writing this, I found a partial answer on Stack Exchange.
<quote>
But, multiple certificates on the same system can be a problem when you
try to serve multiple domains from a single IP address. In this case the
client needs to use the Server Name Indication (SNI) extension to signal
the server which of the hosts it tries to access. While SNI is supported
by all recent web browsers it is not supported by older browser ...
</quote>
This seems to be the answer. The Wikipedia article on SNI says that the
feature was introduced in 2003, to solve precisely the problem I'm
asking about, so it's not surprising that Apache can do it.

In fact the Wikipedia article effectively says that, prior to SNI,
secure servers could only host one domain, because of the difficulty of
getting certifcates that covered multiple domains.

Now I'll have to look up RFC 6066, and implement it on my web server.

(I am now starting to understand that the whole point of "hello
extensions" in TLS is to work around bugs in the original SSL design.)
-- 
Peter Moylan                  peter@pmoylan.org
http://www.pmoylan.org