...
- Linux machine
- SER version 2.0rc or higher. Se also SER 2rc1
- Server certificate and private key in PEM fomrat
- CA list - list of trusted authorities in PEM format
- TLS enabled client - i.e. EyeBeam or new CMC
If you use binary package, see if it supports TLS. command ser -V should show something like
...
and tls module (tls.so) has to located in module directory (depends on distribution and package i.e. /usr/local/lib/ser/modules)
Otherwise you have to recompile SER from source. Download daily snaphot from iptel.org or from CVS.Make everything
Ser 2rc daily snaphost
Ser 2.0 cvs branch
No Format |
---|
makeexport group_include="standard" include_modules="tls" all CVSROOT=:pserver:anonymous@cvs.berlios.de:/cvsroot/ser cvs co -r rel_2_0_0 sip_router |
Ser head cvs branchInstall it (and make before)
No Format |
---|
makeexport group_include="standard" include_modules="tls" install CVSROOT=:pserver:anonymous@cvs.berlios.de:/cvsroot/ser cvs co sip_router |
Compiling of source
Make everythingYou can adjust compiled modules by group_include, include_modules and exclude_modules parameters.
Print-modules parameter show set of modules that will compiled.
No Format |
---|
make group_include="standard" include_modules="tls" print-modules
|
Configuration
Edit your ser.cfg
Enable TLS
Enable TLS and define the address and port where TLS will be listening
all
|
Install it (and make before)
No Format |
---|
make group_include="standard" include_modules="tls" install
|
You can adjust compiled modules by group_include, include_modules and exclude_modules parameters.
Print-modules parameter show set of modules that will compiled.
No Format |
---|
make group_include="standard" include_modules="tls" print-modules
|
Configuration
Edit your ser.cfg
Enable TLS
Enable TLS and define the address and port where TLS will be listening
No Format |
---|
# ----------- global configuration parameters --- |
No Format |
# ----------- global configuration parameters ------------------------
enable_tls=yes
listen=tls:1.2.3.4:5061
|
...
No Format |
---|
# ----------------- setting module-specific parameters --------------- modparam("tls", "private_key", "/etc/certs/key.pem") modparam("tls", "certificate", "/etc/certs/cert.pem") modparam("tls", "ca_list", "/etc/certs/ca_list.pem") modparam("tls", "require_certificate", 0) modparam("tls", "verify_certificate", 1) modparam("tls", "tls_method", "TLSv1") #modparam("tls", "tls_method", "SSLv23") modparam("tls", "tls_log", 2) modparam("tls", "handshake_timeout", 10) modparam("tls", "send_timeout", 10) |
Verification
If tls_log is separate control for TLS logging, If it is set to lower value then debug value tls logs are printed.
Verification
No Format |
---|
modparam("tls", "require_certificate", 0) modparam("tls", "verify_certificate", 1) |
Ser acting as TLS server sends his certificate everytime.
Require=0 and Verify=0 is the weaker weakest settings which provides just an encrypted tunnel (if cipher is not NULL)
Require=0 and Verify=1 - if TLS client provides a certificate, it is verified, this settings allow you sip clients . This setting allows your sip client without certificate to talk to SER. SER with this setting acting as TLS client send his certificate (Mutual authen tication is possible). Status TLS client side verification ids written into select framwork.
SSL vs TLS
...
authentication is possible). Lots of information including verification status is written into @tls select. See iptel.org tls module page.
By mean of the @tls select you can i.e. authenticate clients with client certificate. To make in larger scale you need mapping between CN and ser UID.
@tls.peer.verified is very useful in conjuction with Require=0 and Verify=1 setting. This way you check if the client presented his certificate and it was verified.
Require=1 and Verify=1 is the strongest setting that forces to provide client certificate. If it is not presented, connection fails.
SSL vs TLS
No Format |
---|
modparam("tls", "tls_method", "TLSv1")
#modparam("tls", "tls_method", "SSLv23")
|
TLSv1 is RFC3261 compliant setting but SSLv23 is better for extended compatibility. If you are sure that you neighbors are set to TLSv1 use TLSv1. TLSv1 client can make connection to SSLv23 server but SSLv23 cannot talk to TLSv1 server. Dont' forget that a new TLS connecetion from opposite site can be established during the call.
Eyebeam is TLSv1 Capable but i.e. Linksys SPA 942 need SSLv23.
...
Sample config
Sample config without registrion authentication and with tls routing to domainB (not necessary for enabling TLS for clients)
...
- Invalid TLS version: though TLS 1.0 should be used according to the SIP RFC, SSL 2/3
- certificate verification. CA list often doesn't include the necessary certs.
- Common name of the server certificate does not match DNS name of the server
...