On Fri, 2009-09-25 at 14:45 +0100, Jonny Lamb wrote: > tags 548280 - moreinfo > tags 548280 + fixed-upstream > kthxbye > > On Fri, Sep 25, 13:50:50 +0200, Johannes Berg wrote: > > Thanks, that was quick. I'm indeed using jabberd 1.4 as well, and git > > (0.9.0.1, commit 271fd01cd5) connects fine with oldssl. Still no luck > > with TLS though, but that's ok for me for now and should be a separate > > bug report anyway. > > Great, thanks for testing that. We should be making a new release > soon, and that'll get uploaded as soon as that happens.
Cool, thanks. Regarding my other problem, I just found
8. Certificates MUST be checked against the hostname as provided by
the initiating entity (e.g., a user), not the hostname as
resolved via the Domain Name System; e.g., if the user specifies
a hostname of "example.com" but a DNS SRV [SRV] lookup returned
"im.example.com", the certificate MUST be checked as
"example.com". If a JID for any kind of XMPP entity (e.g.,
client or server) is represented in a certificate, it MUST be
represented as a UTF8String within an otherName entity inside the
subjectAltName, using the [ASN.1] Object Identifier
"id-on-xmppAddr" specified in Section 5.1.1 of this document.
in rfc 3920 so I suppose that's intentional and my server should return
a cert for "sipsolutions.net" instead for "secure.sipsolutions.net",
which is slightly unexpected since I told it to connect to
secure.sipsolutions.net manually, rather than via SRV. But I suppose
that the specified hostname is treated as though it had been gotten from
SRV.
johannes
signature.asc
Description: This is a digitally signed message part
