I’m curious if anyone is using letsencrypt, I’ve been playing with it and I have things sorta working but I’ve been unable to get my hardphone to register unless I turn off ‘Only Accept Trusted Certificates’ which is frustrating.
[transport-tls]
type=transport
protocol=tls
bind=192.168.85.2:5061
local_net=127.0.01/24
local_net=192.168.69.0/24
local_net=192.168.70.0/24
local_net=192.168.85.0/24
local_net=192.168.86.0/24
cert_file=/etc/letsencrypt/live/hostname/fullchain.pem
priv_key_file=/etc/letsencrypt/live/hostname/privkey.pem
external_media_address=<IP>
external_signaling_address=<IP>
external_signaling_port = 5061
method=tlsv1
[endpoint-common](!)
type=endpoint
context=internal
disallow=all
allow=ulaw
;force_avp=yes
use_avpf=yes ; Determines whether res_pjsip will use and enforce usage of
media_encryption=dtls ; Determines whether res_pjsip will use and enforce
dtls_verify=yes ; Verify that the provided peer certificate is valid (default:
dtls_rekey=0 ; Interval at which to renegotiate the TLS session and rekey
dtls_cert_file=/etc/letsencrypt/live/server/fullchain.pem
dtls_private_key=/etc/letsencrypt/live/server/privkey.pem
dtls_ca_file=/etc/letsencrypt/lets-encrypt-x3-cross-signed.pem
dtls_setup=actpass
ice_support=yes ;This is specific to clients that support NAT traversal
media_use_received_transport=yes
direct_media=no
I'm using the pjsip_wizard with the following configuration:
[endpoint-tls](!)
type=wizard
transport=transport-tls
endpoint/use_avpf=yes ; Determines whether res_pjsip will use and enforce usage of
endpoint/media_encryption=dtls ; Determines whether res_pjsip will use and enforce
endpoint/dtls_verify=yes ; Verify that the provided peer certificate is valid (default:
endpoint/dtls_rekey=0 ; Interval at which to renegotiate the TLS session and rekey
endpoint/dtls_cert_file=/etc/letsencrypt/live/server/fullchain.pem
endpoint/dtls_private_key=/etc/letsencrypt/live/server/privkey.pem
endpoint/dtls_ca_file=/etc/letsencrypt/lets-encrypt-x3-cross-signed.pem
endpoint/dtls_setup=actpass
endpoint/ice_support=yes ;This is specific to clients that support NAT traversal
endpoint/media_use_received_transport=yes
endpoint/direct_media=no
aor/max_contacts=2
[7012kiniston](endpoint-tls)
type = wizard
accepts_auth = yes
accepts_registrations = yes
has_phoneprov = yes
transport = transport-tls
has_hint = yes
hint_exten = 7012
inbound_auth/username = 7012kiniston
inbound_auth/password = <PASSWORD>
endpoint/allow = ulaw,g722
endpoint/context = internal
phoneprov/MAC = 001565744d10
phoneprov/LABEL = 7012
phoneprov/PROFILE = yealink
phoneprov/FIRMWARE = T41v36.80.0.95.rom
I have not, but am interested to know how this goes.
This may or may not help you, but I use Let’s Encrypt (certbot) for nginx and apache. In order to get the Let’s Encrypt certificate to validate (when tested with SSL Labs) with apache, I had to add the cert.pem, privkey.pem, and chain.pem. For nginx I used the usual fullchain.pem and privkey.pem, but required an acme challenge to be present. This is because Let’s Encrypt is still new-ish and requires a third-party cross-signing. This may be part of your problem. They mention that they’re not yet trusted in all browsers, but that may extend to other technology as well.
Our intermediate is signed by ISRG Root X1. However, since we are a very new certificate authority, ISRG Root X1 is not yet trusted in most browsers. In order to be broadly trusted right away, our intermediate is also cross-signed by another certificate authority, IdenTrust, whose root is already trusted in all major browsers. Specifically, IdenTrust has cross-signed our intermediate using their DST Root CA X3.
Have you considered creating your own CA for this. You have the problem of deploying the CA certificate to any soft phone hosts, but, once that is done , it will be a lot more secure than a free commercial CA.
Very few people need to authenticate third party SIP clients, and therefore need to use pre-installed intermediate and root certificate chains. LetsEncrypt is an intermediate certificate.
Given how weak its authentication appears to be (and has to be for a free, non crowd, CA), I’m surprised that it is enable by default in browsers. I would have rather more confidence in cacert.org, but, being non-commercial, it isn’t included in Windows certificate packs. To be honest, I would expect any site that was security critical to disable LetsEncrypt (or its parent certificate) and not install CACERT, along with disabling most of the other certificates handed out with Windows.
Thanks for your feedback David, using Asterisk’s “ast_tls_cert” script I was able to get a working self signed cert. However, my challenge is when Asterisk is accessed over WSS using WebRTC client (in javascript code). The WSS connections fails silently even though the HTTPS has passed, until the WSS URL to Asterisk is explicitly accessed through the browser and ignoring the browser security warning.
This is the reason, why I am looking opting out from self signing, excerpt if there is a work around to this
I have deployed Let’s Encrypt with Asterisk. Several key points:
By default, Asterisk’s system user cannot access /etc/letsencrypt/live. I solved this by copying (and chowning) the needed files into /etc/asterisk/... in my cron script that also takes care of refeshing the certs. This was actually the hardest part to figure out, because if Asterisk fails to open the cert/privkey file, it will report a generic certificate error and not a file access problem.
You should use fullchain.pem as the tlscertfile, some clients may not trust Let’s Encrypt’s root cert yet.
Some clients may not support Subject Alternative Names in certificates. I strongly suggest that the server name your clients use is the Common Name, i.e. the first domain specified when using certbot.
Thanks, was just trying to figure this out myself, your tip about permissions was helpful! Although I just changed the permissions on the LE directory instead: