Thursday, July 28, 2005
TLS/SSL certificates and multiple A records
We're in the process of migrating from our current server-oriented approach
of handling services to a more generic services-based approach. The idea is
instead of dedicating one machine to running a particular service, we'll
dedicate a cluster of identical machines to running all services. One of
the services that's earmarked to move is our outgoing mail server. As we
allow users to establish a TLS/SSL connection to this server, we had some
concerns about how to handle TLS/SSL certificates on our cluster. Do we
need one certificate for the whole cluster or does each machine need a
certificate?
Like good scientists, to work out the answer to this problem, we set up an
experiment. What we did was set up a test environment that mimicked what we
wanted to do with our mail server. This involved setting up the following
DNS:
guy@walrus:~$ host test.ru.ac.za
test.ru.ac.za has address 192.168.94.20
test.ru.ac.za has address 192.168.94.21
test.ru.ac.za has address 192.168.94.22
guy@walrus:~$ host 192.168.94.20
20.94.168.192.in-addr.arpa domain name pointer a.test.ru.ac.za.
guy@walrus:~$ host 192.168.94.21
21.94.168.192.in-addr.arpa domain name pointer b.test.ru.ac.za.
guy@walrus:~$ host 192.168.94.22
22.94.168.192.in-addr.arpa domain name pointer c.test.ru.ac.za.
guy@walrus:~$ a.test.ru.ac.za
a.test.ru.ac.za has address 192.168.94.20
guy@walrus:~$ b.test.ru.ac.za
a.test.ru.ac.za has address 192.168.94.21
guy@walrus:~$ c.test.ru.ac.za
a.test.ru.ac.za has address 192.168.94.22
Each of the three IP addresses is bound by a different machine in the
cluster. The idea is that users will use test.ru.ac.za in their
configuration and their client will randomly chose one of the three hosts to
connect to. This works neatly, in part because BIND9 lets us randomize the order in
which results are returned. You'll notice that the forward and reverse
lookups for these hosts are different.
The next stage was to create some self-signed
certificates. We created four such certificates, one for test.ru.ac.za
and one each for the *.test.ru.ac.za hosts. Ideally we wanted to use
test.ru.ac.za, but we were unsure whether the mismatch between forward and
reverse mattered ...
We configured Apache on each of the
three machines to operate as an SSL web server and configured each of them
to use the appropriate *.test.ru.ac.za certificate. We could then use a web
browser to test things.
As expected, visiting each of https://a.test.ru.ac.za/,
https://b.test.ru.ac.za/ and https://c.test.ru.ac.za/ worked. The
certificate CN matched the DNS (both forward and reverse) and the browser
was happy. Visiting https://test.ru.ac.za/ (the preferred hostname),
however, caused the browser to complain.
So the next stage was to change each of the web-servers to use the
test.ru.ac.za certificate. Now we had three servers sharing the same
certificate. This time around, the visiting the *.test.ru.ac.za addresses
caused the browser to produce a warning about a CN mismatch. Visiting
https://test.ru.ac.za/ was better though — Internet Explorer, Firefox and links accepted the certificate without
complaint.
The conclusions, therefore, are that reverse DNS lookups are irrelevant when
validating an SSL/TLS certificate, and that a single SSL/TLS certificate can
be shared between several machines. This is good news.
posted by guy at: 08:32 SAST |
path: /systems |
permanent link
