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

Reply via email to