On Tue, Nov 21, 2017 at 12:13:14PM +0100, Olle E. Johansson wrote: > Propably because they don’t trust your CA. You need to install the > CA cert in the trust store on the systems you run Bria and Blink on > (and remember to remove it later)
Since I wrote that, I got an authoritative certificate for the host from Comodo. Its CN happens to correspond to the serving SIP domain & canonical hostname, so I cannot tell whether the UAs properly deal with SAN. Bria and my Polycom VVX 411 validate the certificate. Bria does not, despite using OpenSSL defaults which include root CA certs/chains for several Comodo issuers. I suspect that this is an adequate bellwether of how other UAs will behave: inconsistently. I have heard it said by some that authoritative certificates from well-known CAs are not a big thing in the SIP TLS world. The folklore has it that most large service providers and enterprises run their own CAs and simply mass-provision their own certificates into devices. I cannot say if it's true. But if it is true, it would greatly differ from the practice in the WWW world, it would seem. I am also unsure as to the status of LetsEncrypt. It seems a handful of handset vendors might have been persuaded to support it. > SAN is an extension so that ONE certificate is valid for multiple names. > If you have SAN fields, the CN of the cert is ignored. > > SNI is a TLS function where the client says “I’m going to connect to > alex.domain.com <http://alex.domain.com/>” early in the TLS negotiation so > that the server > can select a valid certificate. The server now has one certificate > per domain and selects which one to use for the session. > > In summary > * SAN = One cert, many names, one server > * SNI = One cert per domain, one server Interesting. For my use-case, SNI might be more appropriate than SAN; You say Kamailio supports SNI? How? > > Interesting; so as a practical matter, it is formally acceptable to send > > a request with neither sips: scheme nor ;transport=TLS, just happen to > > send it via TLS? The only indication of transport would then be > > SIP/2.0/TLS in the Via header, no? > Right. And hopefully the server will add proper headers (what they are > without the transport flag) to the record-route and route headers. > THis is a bug in SIP. Kamailio adds RRs with ;transport=tls for the appropriate hop. > You need to look at SIP outbound so that the client opens the > connection to the server and the server has the right to use > the *very same* connection for messages to the client. Without > outbound, the server is required to open a TLS connection to the > client and vertify the client’s certificate against the target URI. I assume it is common practice to turn off verification of the client certificate? That is what I have done in my Kamailio test environment. > In summary, one can get SIP over TLS to work if you break some parts > of the RFCs and rely more on developers than the documentation from > IETF. That has been consistent with my exploration thus far. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors