10 okt 2009 kl. 14.51 skrev Jan Janak:
On Sat, Oct 10, 2009 at 2:21 PM, Andrei
Pelinescu-Onciul
<andrei(a)iptel.org> wrote:
On Oct 10, 2009 at 14:04, Jan Janak
<jan(a)ryngle.com> wrote:
On Sat, Oct 10, 2009 at 1:58 PM, Olle E.
Johansson
<oej(a)edvina.net> wrote:
??<title><varname>config</varname> (string)</title>
?? ?? ?? ??<para>
?? ?? ?? ?? ?? ?? ?? ??Sets the name of the TLS specific config
file.
?? ?? ?? ??</para>
?? ?? ?? ??<para>
?? ?? ?? ?? ?? ?? ?? ??If set the TLS module will load a special
config file, in
which different TLS parameters can be specified on a per role
(server or
client) and domain basis (for now only IPs). The corresponding
module
parameters will be ignored.
?? ?? ?? ??</para>
Is this still valid - that we only configure tls on IP?
Currently yes. It is on my todo list to extend the configuration
file
syntax to also support server names, but I am not there yet.
I think this is something that can wait. The server name extension is
quite new in openssl (on by default since 1.0). I doubt there are
many
clients supporting it and unless all or most your clients support
it is
It is also useful for server-to-server connections, there it allows
you to select and present the correct certificate. Even if you have no
clients that support it, you might still want to use the server name
extension for server-to-server connections.
Well, to support the current proposal we should have a security
association on every TLS link between ourself and other servers, where
we remember which domain we verified for this link. We can't reuse
this connection for other links between ourself and the peer for other
domains.
Now, I have a problem with the subj alt names, but that is something
that I need to discuss on IETF mailing lists... I don't really like
mixing verification of a server with hostname and authorization in the
same certificate.
We did a lot of tests of TLS at SIPit, me and Nils Ohlmeier. We used
the configuration script verification procedures, which (as we say in
the documentation) is a bit late, but nevertheless is working.
/O