SIP TLS TRUNK between 2 asterisk server

hello

i have been lately trying to define a sip trunk with type registration from one asterisk server to another one on TLS. still did not figure out how to do it.

But I was able before to define a sip trunk with type registration from one asterisk server to another one on UDP. It was simple.

The problem i faced in the first approach is that: every sip endpoint needs a client certificate for sure. the sip trunk of type registration acts as if it is an endpoint as we all know. And an endpoint needs a certificate to authenticate to the server.

So if we have two asterisk servers: AST1 and AST2.
Then i am trying to define a sip trunk of type registration at AST1. Then i need at AST2 to define an endpoint which has the same username as the sip trunk at AST1, so this sip trunk would register to it.(sip trunk at AST1 must register at AST2 )

Because the transport is of type TLS, then sip trunk at AST1 needs the client certificates generated by AST2, which i have but did not figure out how to pass it to the sip trunk at AST1. There is no parameters at pjsip.conf at AST1 that allows me to set a path for a certificate for an endpoint.

AM I WRONG?

if i am not wrong and then there is no way to do so, then i would try to tell AST2 to not ask for the verification of the certificates of this specific endpint! but then again the only option is to ask for certificates of all users or not.

AM I WRONG? or there is such a paramter?

if i am not wrong again. then i am down with two options left:

1st option is to define a peer trunk, but i dont prefer it because with peer sip trunk there is no security at all since there is no authentication or nothing. it only sends and receives to a given ip address.

2nd option is to do define a UDP register trunk, this could be done but i need to define another transport section of type udp. but i am concerned that if the calls from endpoints on AST1 to AST2 which should be going through TLS, would then be passing through this trunk on UDP and thus leading to losing the encryption and security of TLS.

There is confused terminology here. I suspect you are using FreePBX terminology and FreePBX concepts. “type=registration trunk” means nothing for Asterisk.

One key thing to note is that client and server roles in SIP only exist within a single transaction and both can be either client or server.

Also, the server mode TLS configuration is associated with the transport. In fact, if you are accepting registration, it cannot be the AOR, as you need the authenticated encrypted connection before you can tell who is trying to register.

If you need to have different TLS identities, for different peers, you will need different transports, and different port numbers, for each one.

what i mean by of type registration trunk is type = registration
because there is type=peer. which is not my case.

that is what i thought it is . but i am supposing that i might be wrong! but as you say then i am not wrong.

no i dont want different identites. i just need to register a trunk from AST1 to AST2 on TLS.

type=peer relates to a deprecated driver. I was assuming that you were using the supported driver. In any case, even with the deprecated driver, you should still use type=peer, even when one side has host=dynamic.

If you only have one TLS identity, that obviously cannot be associated with an endpoint, as there are multiple endpoints in any normal system. You don’t configure the actual certificate of the other party, but just the CA certificate, which is typically the same for everyone.

By deprecated driver you mean sip driver? because no i am using pjsip module!

oh now i got it. no for every asterisk server i generated ca certificate!
every server has its own ca, server, client certificates!

A self signed certificate authority is generally not per-server. It is per-organization. The certificate authority issues certificates for each client or server.

1 Like

The Asterisk scripts that create certificates are possibly confusing, because they do everything on the machine that people like to call the server. That’s actually bad practice. Really, the secret key for Asterisk should never leave the Asterisk machine, and the secret key for the CA should be on an extremely well protected, and ideally not networked, and not permanently powered up machine in head office.

If you use the scripts, you have to arbitrarily choose one Asterisk box as doubling as the CA. In that case, that box is the server in terms of documentation for the scripts, and every other protected SIP agent, whether phone or PABX, is a client, for the purpose of that documentation. The client server asymmetry is not fundamental, but arises from not having a distinct CA box.

1 Like

so yes now i understand that a CA is not per server but it is per organization, but if i generated a ca for every server then would this come with bad consequences?

You’d have to distribute a lot of CA certificates.

i dont have any problem with that.

The only problem is how to define a trunk of type registration on TLS!

could this be done? and how?

Maybe this will help:

First, let’s see the actual configs being used on both servers. All of this is guessing right now. Second, if this isn’t being done with Chan_PJSIP it needs to be scrapped and redone to use Chan_PJSIP. Chan_SIP is dead and shouldn’t be used. Finally, I have a feeling this is being over thought as connecting to Asterisk systems together be it UDP or TLS is not different then connecting an endpoint to Asterisk over TLS.

Again, we need to see some configs to actually see what is being done.

Unless they are referring to type=registration, which does mean something in Asterisk. The registration section is part of a Chan_PJSIP and used for outbound authentication. So if this is using Chan_PJSIP and AST1 needs to register to AST2, AST1’s trunk will have a type=registration section.

1 Like

AST1 of ip address 192.168.133.100
AST2 of ip address 192.168.133.99

AST1 pjsip.conf:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0


[transport-tls]
type=transport
protocol=tls
bind=192.168.133.100:5061
cert_file=/etc/asterisk/keys/asterisk.crt
priv_key_file=/etc/asterisk/keys/asterisk.key
ca_list_file=/etc/asterisk/keys/ca.crt
ca_list_path=/etc/asterisk/keys
method=tlsv1_2
require_client_cert=yes
verify_client=yes
verify_server=yes

;;this is the trunk to the AST2
[12345]
type=registration
outbound_auth=12345
server_uri=sip:192.168.133.99
client_uri=sip:12345@192.168.133.99
retry_interval=60


[12345]
type=auth
auth_type=userpass
password=12345
username=12345

[12345]
type=endpoint
context=phones
transport=transport-tls
disallow=all
allow=gsm,alaw,ulaw,g723
outbound_auth=12345
aors=12345

[12345]
type=aor
max_contacts=1
contact=sip:12345@192.168.133.99:5061
remove_existing=no

AST1 extensions.conf:

[phones]
exten => _01X.,1,set(CALLERID(num)=12345)
same  =>       n,dial(PJSIP/${EXTEN:2:}@12345)
same  =>       n,HANGUP()

AST2 pjsip.conf:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0


[transport-tls]
type=transport
protocol=tls
bind=192.168.133.99:5061
cert_file=/etc/asterisk/keys/asterisk.crt
priv_key_file=/etc/asterisk/keys/asterisk.key
ca_list_file=/etc/asterisk/keys/ca.crt
ca_list_path=/etc/asterisk/keys
method=tlsv1_2
require_client_cert=yes
verify_client=yes
verify_server=yes

;====================template
[endpoint-basic](!)
type=endpoint
context=phones
disallow=all
allow=alaw,ulaw,gsm
device_state_busy_at=1
direct_media=no
dtmf_mode=rfc4733

[auth-userpass](!)
type=auth
auth_type=userpass

[aor-single-reg](!)
type=aor
max_contacts=1
remove_existing=yes

;==============EXTENSION 12345
[12345](endpoint-basic)
transport=transport-tls
;media_encryption=sdes
auth=auth12345
aors=12345

[auth12345](auth-userpass)
password=12345
username=12345

[12345](aor-single-reg)

AST2 extensions.conf:

exten => _X.,1,NoOp(${EXTEN:0:5})
same =>      n,Dial(PJSIP/${EXTEN},25)
same =>      n,Hangup()

Now i am trying to make a call from a sip account on AST1 to a sip account on AST2, but the call is not delivered. whereas when i switch the trunk to udp on port 5060, then the call goes fine!

You know both IP addresses. You should not be using registration.

1 Like

registration gives me better security.
i prefer it with registration!

How does it give you better security?

1 Like

There is a common misunderstanding that registration is about security; it is not.

1 Like

No, registration does not give better security. With registration, if I hack or have your user/pass I can now register freely. With IP Auth, I would need to do a lot more to get around things. Spoofing an IP requires a lot more work.

So what is the actual problem you are having? Problems with registering to AST2 from AST1? If so, show the debugs from both sides. You need to keep in mind the TLS cert on AST1 is for the devices connect to AST1.

When you are registering AST1 to AST2 you have to treat AST1 like any other endpoint. Since AST2 is providing the TLS, you just program the AST2 endpoint (on AST1) to connect to it over TLS but don’t need cert details on AST1.

Again, need to see debugs and see what is actually happening.

1 Like

Hello guys thanks for all the help,
When i said registration gives better security i was talking about the tls certificates which for sure do that.

The actual problem that i am having is that i dont know where to pass the certificates that for the sip trunk since it needs the certs from AST2, because the sip trunk at AST1 acts as if it is an endpoint at AST2, as you implied earlier.

So where should i put these certificates at AST1? And how to tell the system that the certificates are there!

But then you said it does not need certs!
I dont get it!

Registration doesn’t mean certificates.

You need to understand how public key infrastructure works. Looking for solutions you don’t understand is asking for trouble when it comes to security. If I provide detailed descriptions, as well as my not having tested them, it would encourage you to rely on them without understanding them.

The real thing about Enigma, in WWII wasn’t that the Enigma machine was weak but that operators were lax, presumably because they didn’t understand the reasons for the correct procedures.

1 Like