TLS certificates are not read in Docker container

Asterisk Asterisk SIP
1

I am trying to run Asterisk (using pjsip) in a Docker container running on AWS ECS. We are using an SBC and we want to use TLS certificates for both directions. A requirement from the SBC side is that OPTIONS requests are sent and responded to. Sending the requests works with TLS, but it appears that the SBC side does not accept our certificates - we get the following in our ECS logs:

res_pjsip/pjsip_transport_events.c:179 verify_log_result: Transport ‘transport-tls’ to remote ‘sbchost.net’ - OK|
| — | — |
||

pjproject:<?>: SSL 6 [SSL_ERROR_ZERO_RETURN] (Read) ret: 0 len: 4000

When turning off TLS and only using TCP, everything works fine and a connection can be established. In Wireshark, we saw that a Client Hello from the SBC side is never answered, i.e., a TLS handshake is not established in that direction.

Here is our pjsip.conf file - during startup of the container, we pass some environment variables like ${SBC_HOST_1} which we checked and are indeed correctly set.

[global]
type=global
user_agent=Asterisk

[my-sbc1]
type=endpoint
context=sip-incoming-sbc1
disallow=all
allow=ulaw
allow=alaw
allow=g722
aors=my-sbc1
media_encryption=sdes
media_encryption_optimistic=yes
transport=transport-tls
direct_media=no
dtmf_mode=rfc4733
rtp_symmetric=yes

[my-sbc1]
type=aor
contact=sip:${SBC_HOST_1}:${ASSIGNED_PORT}
qualify_frequency=30

[my-sbc1]
type=identify
endpoint=my-sbc1
match=${SBC_HOST_1}
srv_lookups=no

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:${ASSIGNED_PORT}
cert_file=/etc/ssl/asterisk/server.crt
priv_key_file=/etc/ssl/asterisk/server.key
ca_list_file=/etc/ssl/asterisk/Our_Trusted_Certificates.pem
method=tlsv1_2
require_client_cert=no
verify_client=no
verify_server=no
tos=cs3
cos=3
symmetric_transport=yes

Any help is highly appreciated.

2

Update: I have found the error - it turns out that in the file indicated in the ca_list_file variable, one needs the actual certificate chain created from the trusted certificates and the certificate itself, not just the trusted certificates. With that, everything works and the OPTIONS requests from the SBC are answered.

EDIT: I originally claimed that one also needs the private key which is obviously nonsense and will soon edit further to describe more in detail what I mean.

3

That can’t be right. PKI would not work if you had to know the private key for the root CAs, as anyone could forge a certificate.

4

Thank you, you’re right, I do not need the private key and edited my post - when I have more time, I will edit again and explain more thoroughly what I meant.