[Date Prev][Date Next]
Re: Change over to anonymous binds
At 02:57 AM 2002-08-19, Tony Earnshaw wrote:
>man, 2002-08-19 kl. 00:25 skrev Kurt D. Zeilenga:
>> Choosing the name to put in the CN of your server cert
>> should be simple. Choose the fully qualified domain name
>> which will return for the client the desired IP address(es)
>> of the server and place the certificate. If there are
>> multiple FQDNs, choose the one which you would like the
>> users to enter.
>Though ... as I wrote, that's o.k. if your host is constantly connected
>to the network bearing/served by that domain name. Mine isn't.
It works fine as long as the domain name always returns the
appropriate IP address for your host (at that time).
>This machine is a dialup node with a static IP number (18.104.22.168)
>for which I and my ISP have chosen the name billy.demon.nl. My name
>server cannot possibly be authorative for demon.nl.
So, use billy.demon.nl in your certificates... and deal with
the addressing issues below LDAP and TLS.
>So if I put billy.demon.nl in my certificate, it constantly wants to go
>to the Internet to resolve it.
Then setup your name resolution system such that when you are
not connect to the Internet you still can resolve billy.demon.nl
to the right IP address (at that time). There are many ways to do
this, from overriding DNS with /etc/hosts to using a caching DNS
server (which you hardwire billy.demon.nl into). You can even
have the address return change as your connective changed.
>My workaround was to make certificates with non-qualified cn=localhost
>and configure the caching nameserver on the node to be authorative for
>localhost.demon.nl - 127.0.0.1 - which is the answer it would get from
>Demon's nameservers anyway (I used to be DNS admin for my firms, with up
>to 4 Internet nameservers, for which the zone tables first had to be
>approved by the Dutch Internet authority).
>Or perhaps someone has a better suggestion? Mine works fine for me :-)
Whatever works fine for you is fine for you. But I think it
is not a general solution to dealing with such situations,
namely because the certificate would only be usable if the
client was on the local host and connected to "localhost"
and didn't map "localhost" to your local host name (as
some clients do).
A better approach would be to configure your name resolution
system such that billy.demon.nl resolved to the appropriate
address (which may change over time) of your server. At
times, may the appropriate address is 127.0.0.1... but
I would suggest you set up your addressing/routing such
that 22.214.171.124 is appropriate at all times.