# TLS Transport - The certificate is untrusted with Microsoft Teams **URL:** \ **Category:** Asterisk SIP\ **Created:** [August 30, 2023, 8:17pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434 "2023-08-30T20:17:15Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [August 30, 2023, 8:17pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/1 "2023-08-30T20:17:15Z")
Dear Community, I’ve been struggling trying to **re** -connect an Asterisk Server with Microsoft Teams, Re-connect since i already made a two-way connection with SIP OPTIONS and Calls, Currently, i have the following settings: _Note: **${value}** is not shown due privacy purposes._ Endpoint: ```auto ParameterName : ParameterValue =================================================================================================== 100rel : yes accept_multiple_sdp_answers : true accountcode : acl : aggregate_mwi : true allow : (g729|alaw|ulaw) allow_overlap : true allow_subscribe : false allow_transfer : true allow_unauthenticated_options : false aors : AOR_MSTEAMS1, AOR_MSTEAMS2, AOR_MSTEAMS3 asymmetric_rtp_codec : false auth : bind_rtp_to_media_address : false bundle : false call_group : callerid : callerid_privacy : allowed_passed_screen callerid_tag : codec_prefs_incoming_answer : prefer:pending, operation:intersect, keep:all, transcode:allow codec_prefs_incoming_offer : prefer:pending, operation:intersect, keep:all, transcode:allow codec_prefs_outgoing_answer : prefer:pending, operation:intersect, keep:all, transcode:allow codec_prefs_outgoing_offer : prefer:pending, operation:union, keep:all, transcode:allow connected_line_method : invite contact_acl : context : IN_MSTEAMS cos_audio : 0 cos_video : 0 device_state_busy_at : 0 direct_media : false direct_media_glare_mitigation : none direct_media_method : invite disable_direct_media_on_nat : false dtls_auto_generate_cert : No dtls_ca_file : dtls_ca_path : dtls_cert_file : dtls_cipher : dtls_fingerprint : SHA-256 dtls_private_key : dtls_rekey : 0 dtls_setup : active dtls_verify : No dtmf_mode : rfc4733 fax_detect : true fax_detect_timeout : 0 follow_early_media_fork : true force_avp : false force_rport : true from_domain : ${domain} from_user : g726_non_standard : false geoloc_incoming_call_profile : geoloc_outgoing_call_profile : ice_support : false identify_by : ip,username,header,auth_username ignore_183_without_sdp : true inband_progress : true incoming_call_offer_pref : local incoming_mwi_mailbox : language : es mailboxes : max_audio_streams : 1 max_video_streams : 1 media_address : media_encryption : sdes media_encryption_optimistic : false media_use_received_transport : false message_context : moh_passthrough : true moh_suggest : default mwi_from_user : mwi_subscribe_replaces_unsolicited : no named_call_group : named_pickup_group : notify_early_inuse_ringing : false one_touch_recording : false outbound_auth : outbound_proxy : outgoing_call_offer_pref : remote_merge pickup_group : preferred_codec_only : false record_off_feature : record_on_feature : refer_blind_progress : false rewrite_contact : false rpid_immediate : false rtcp_mux : false rtp_engine : asterisk rtp_ipv6 : false rtp_keepalive : 0 rtp_symmetric : false rtp_timeout : 0 rtp_timeout_hold : 0 sdp_owner : ${owner} sdp_session : ${session} send_connected_line : yes send_diversion : true send_history_info : false send_pai : false send_rpid : false set_var : srtp_tag_32 : false stir_shaken : off stir_shaken_profile : sub_min_expiry : 0 subscribe_context : suppress_q850_reason_headers : false t38_bind_udptl_to_media_address : false t38_udptl : true t38_udptl_ec : none t38_udptl_ipv6 : false t38_udptl_maxdatagram : 0 t38_udptl_nat : false timers : yes timers_min_se : 90 timers_sess_expires : 1800 tone_zone : cl tos_audio : 0 tos_video : 0 transport : transport_tls trust_connected_line : yes trust_id_inbound : true trust_id_outbound : true use_avpf : false use_ptime : false user_eq_phone : false voicemail_extension : webrtc : no ``` Transport: ```auto ParameterName : ParameterValue ======================================================================================================================================= allow_reload : false allow_wildcard_certs : Yes async_operations : 1 bind : 0.0.0.0:5061 ca_list_file : /etc/asterisk/certs/CA.pem ca_list_path : cert_file : /etc/asterisk/certs/wildcard.crt cipher : ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES128-SHA256 cos : 0 domain : external_media_address : ${domain} external_signaling_address : ${domain} external_signaling_port : 5061 local_net : net1/255.255.255.0 local_net : net2/255.255.255.0 local_net : net3/255.255.255.224 local_net : net4/255.255.255.224 method : tlsv1_2 password : priv_key_file : /etc/asterisk/certs/private.key protocol : tls require_client_cert : No symmetric_transport : false tos : 0 verify_client : No verify_server : No websocket_write_timeout : 100 ``` SIP OPTIONS: ```auto <--- Transmitting SIP request (497 bytes) to TLS:52.114.132.46:5061 ---> OPTIONS sip:sip.pstnhub.microsoft.com SIP/2.0 Via: SIP/2.0/TLS ${domain}:5061;rport;branch=z9hG4bKPj411abb45-1454-44e2-9ee2-9e2859e43395;alias From: Contact: Call-ID: 3f1e2668-7ff1-4bd7-98f7-0f9d04a9c73f CSeq: 38224 OPTIONS Max-Forwards: 10 User-Agent: ${user-agent} Content-Length: 0 ``` Im not sure if the following notification is related to this unreachability: > NOTICE[4674]: res\_pjsip/pjsip\_transport\_events.c:179 verify\_log\_result: Transport ‘transport\_tls’ to remote ‘[sip.pstnhub.microsoft.com](http://sip.pstnhub.microsoft.com)’ - **The certificate is untrusted** My certificate provider is LeaderSSL that works with Sectigo, wildcard.crt file contains only the “STAR” certificate that provides LeaderSSL CA.pem contains all intermediate CA values of the wildcard service, > AAACertificateServices.crt > SectigoRSAOrganizationValidationSecureServerCA.crt > USERTrustRSAAAACA.crt Also, I have downloaded the [CA](https://www.digicert.com/kb/digicert-root-certificates.htm) that MS Teams is using and added it to Centos 9: **DigiCert Global Root G2** > /etc/pki/ca-trust/source/anchors/${DigiCertCA.pem} then, I applied the CA changes to the O.S. with: > update-ca-trust **I’m aware** that Asterisk is not “supported” by default as a valid SBC for MS Teams, so, i followed [this guide](https://www.ayonik.de/blog/item/90-microsoft-teams-direct-routing-with-asterisk-pbx) and modified what values were out of date, everything was working fine until today with no changes made whatsoever, so i believe that MS Teams is updating something or banned my server directly, my logs shows unavailability at 12:00 UTC in multiple attempts (Available - Unavailable). Any suggestions are greatly appreciated Warm Regards ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [August 30, 2023, 8:40pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/2 "2023-08-30T20:40:07Z")
> [@Diego.Espinoza](#): > > ```auto > ca_list_file : /etc/asterisk/certs/CA.pem > ca_list_path : > > ``` You don’t appear to have the signing certificate for Microsoft. ---
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [August 30, 2023, 8:47pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/3 "2023-08-30T20:47:19Z")
Dear David, Do you mean that, i can mention multiple CAs there? > pjsip.conf ```auto `[transport_tls]` `ca_list_file = /etc/asterisk/certs/CA.pem` ``` Im not sure how to mention “external” CA’s in the configuration I’ve tried separating them with comma, but i got a exception handler for the transport > `ca_list_file = /etc/asterisk/certs/CA.pem, /etc/asterisk/certs/MSTeamsCA.pem` Warm Regards ---
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [August 30, 2023, 8:51pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/4 "2023-08-30T20:51:09Z")
Ive tried moving my CA’s to > /etc/asterisk/certs/CA/ With 400 asterisk:asterisk And mentioning only: > ca\_list\_path = /etc/asterisk/certs/CA/ [transport\_tls] > ;ca\_list\_file = /etc/asterisk/certs/CA.pem > ca\_list\_path = /etc/asterisk/certs/CA/ But im getting the same message, and the trunks stay unavailable ---
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [August 30, 2023, 10:14pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/5 "2023-08-30T22:14:35Z")
I have an update, After installing a Baltimore CA adviced by microsoft the Untrusted message disappeared, instead i receive: > res\_pjsip/pjsip\_transport\_events.c:179 verify\_log\_result: Transport ‘transport\_tls’ to remote ‘[sip.pstnhub.microsoft.com](http://sip.pstnhub.microsoft.com)’ - OK Now im raising a case to MS Teams if they have “blocked” my server instance, or to understand what is out of MSTeams standard. ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [August 30, 2023, 11:22pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/6 "2023-08-30T23:22:52Z")
I believe you concatenate the PEM files physically for the file method, and you have to rename them based on a hash, see [man 3 openssl-rehash](https://www.openssl.org/docs/man3.0/man1/openssl-rehash.html), for the directory one ---
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [September 3, 2023, 3:29pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/7 "2023-09-03T15:29:24Z")
Dear @david551, Hope you’re fine, I have concatenated three CA certificates in the same file, ```auto BEGIN CERTIFICATE CA 1 (Asterisk Server Domain) END CERTIFICATE ``` ```auto BEGIN CERTIFICATE CA 2 (MS Teams - Baltimore) END CERTIFICATE ``` ```auto BEGIN CERTIFICATE CA 3 (MS Teams - Digicert) END CERTIFICATE ``` MS Teams is replying “properly” as i have seen in the Asterisk CLI > res\_pjsip/pjsip\_transport\_events.c:179 verify\_log\_result: Transport ‘transport\_tls’ to remote ‘[sip.pstnhub.microsoft.com](http://sip.pstnhub.microsoft.com)’ - OK But their replies, at network level, aren’t shown like the options packet captured at the start of this thread, Im using `pjsip set logger on` and `pjsip set logger host sip.pstnhub.microsoft.com` The thing that i see is CLI Prompt when using pjsip logger is: > \<— Transmitting SIP request (502 bytes) to TLS:52.114.132.46:5061 —\> > OPTIONS sip:sip.pstnhub.microsoft.com:5061 SIP/2.0 > Via: SIP/2.0/TLS ${DOMAIN}:5061;rport;branch=z9hG4bKPjf2181e3f-caed-465b-a852-2d8cedcafd44;alias > From: sip:MSTEAMS@{DOMAIN};tag=98d9cc6f-e726-4be1-a833-387583f0a024 > To: sip:sip.pstnhub.microsoft.com > Contact: sip:MSTEAMS@${DOMAIN}:5061;transport=TLS\> > Call-ID: 7851ceee-2a84-4ab7-9b73-5ed0cbdd0783 > CSeq: 30600 OPTIONS > Max-Forwards: 10 > User-Agent: ${User Agent} > Content-Length: 0 > res\_pjsip/pjsip\_transport\_events.c:179 verify\_log\_result: Transport ‘transport\_tls’ to remote ‘[sip.pstnhub.microsoft.com](http://sip.pstnhub.microsoft.com)’ - OK But, I should receive something like: > \<— **Receiving** SIP request (502 bytes) from TLS:52.114.132.46:5061 —\> By the way, MSTeams is able to send calls to Asterisk and there is audio in both directions. But from Asterisk to MSTeams, the Endpoint shows as unavailable, i tried sending calls ignoring QUALIFY/OPTIONS, Should i debug encription related issues? Or is Asterisk CLI (pjsip logger) unable to capture encripted packets. If further details are required please let me know. Warm Regards ---
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [September 3, 2023, 3:34pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/8 "2023-09-03T15:34:23Z")
Also, Is there a way to remove the user portion of SIP OPTIONS: FROM and/or CONTACT headers? Leaving only the “FQDN”: i.e.: ```auto From: sip:MSTEAMS@{DOMAIN};tag=98d9cc6f-e726-4be1-a833-387583f0a024 Contact: sip:MSTEAMS@${DOMAIN}:5061;transport=TLS> ``` ```auto From: sip:{DOMAIN};tag=98d9cc6f-e726-4be1-a833-387583f0a024 Contact: sip:${DOMAIN}:5061;transport=TLS> ``` Any advices are going to be appreciated Warm Regards ---
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [September 5, 2023, 11:50am UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/9 "2023-09-05T11:50:09Z")
Is it expected to qualify an endpoint as Unavailable after receiving this CLI message? > res\_pjsip/pjsip\_transport\_events.c:179 verify\_log\_result: Transport ‘transport\_tls’ to remote ‘[sip.pstnhub.microsoft.com](http://sip.pstnhub.microsoft.com)’ - OK Its like remote side ended connection or i have an internal asterisk problem. Any ideas or advices will be greatly appreciated Warm Regards ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [September 5, 2023, 11:58am UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/10 "2023-09-05T11:58:26Z")
I would say that message indicates that there was no problem at the point where it was issued. I think the device state will be UNAVAILABLE until OPTIONS produces a response. ---
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [September 5, 2023, 12:13pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/11 "2023-09-05T12:13:26Z")
So, CA’s is “valid” as per CLI reply via TLS, But no 200 OK is being replied from remote side right? Thats why Asterisk interprets this behavior as “Unavailable” ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [September 5, 2023, 12:30pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/12 "2023-09-05T12:30:12Z")
There is no requirement that the reply be 200 OK. Even method not implemented should be good enough. ---
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [September 5, 2023, 12:50pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/13 "2023-09-05T12:50:08Z")
@david551 Maybe i need some TLS Debugging, I just saw a [Teams article](https://learn.microsoft.com/en-us/microsoftteams/troubleshoot/phone-system/direct-routing/sip-options-tls-certificate-issues), that describes a step by step process of what happens when an SBC (Asterisk) starts a connection to a SIP Proxy (Teams), > The SIP proxy checks the connection request. > > - If the request is not valid, the TLS connection is closed and the SIP proxy does not receive SIP options from the SBC. > - If the request is valid, the TLS connection is established, and the SBC uses it to send SIP options to the SIP proxy. Do you know when “TLS Negotiation” is sucessful? Im seeing many “TLS” packets at network level with ```auto Client Hello to Teams Server Hello to Asterisk Certificate, Key Exchange to Teams Change Cypher Spec to Asterisk ``` Then 2 TCP Packets, ```auto FIN, ACK Flag to Teams RST, ACK to Asterisk ``` Maybe Teams doesn’t like SIP OPTIONS format and is resseting the TLS encription, if so, it could be the user portion of FROM and CONTACT headers, I couldn’t find a way to remove them from pjsip.conf, 2 days ago i posted a example of what i tried to send in OPTIONS to Teams, Maybe a source code modification can remove the user portion in OPTIONS method? Any suggestions are greatly appreciated ---
**Author:** ![Pooh](https://avatars.discourse-cdn.com/v4/letter/p/f05b48/32.png) [@Pooh](https://community.asterisk.org/u/Pooh)\ **Post date:** [September 5, 2023, 12:50pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/14 "2023-09-05T12:50:33Z")
To the best of my knowledge (which admittedly is around 2 years old on this topic now) it is not possible to connect Asterisk directly to MS Teams without using something like Kamailio in the middle to fiddle certain headers to Microsoft’s liking. Basically, MS only supports certain approved systems with MS Teams, and if whatever you connect to it (in this case Asterisk) doesn’t look sufficiently like one of those, then Teams won’t play with you. I’d be very interested to know if anyone thinks it _is_ possible to plug Asterisk directly into MS Teams, but given Microsoft’s historical attitude to standards and inter-operability, I suspect what I learned 2 years ago is still true. Antony. ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [September 5, 2023, 12:54pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/15 "2023-09-05T12:54:51Z")
I am aware that people have done patches to Asterisk to adjust things accordingly, but noone has ever contributed them to the project. ---
**Author:** ![Diego.Espinoza](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/diego.espinoza/32/3811_2.png) [@Diego.Espinoza](https://community.asterisk.org/u/Diego.Espinoza)\ **Post date:** [September 5, 2023, 1:18pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/16 "2023-09-05T13:18:20Z")
I will try to modify SIP OPTIONS from source… Not sure what im into, but i have to give it a try, If somebody knows what source code files provision OPTIONS method, i surely appreciate the file names, Also, Thanks for mentioning Kamailio, if i can’t progress with Asterisk itself, ill have to give Kamailio a try, Warm Regards ---
**Author:** ![system](https://global.discourse-cdn.com/asterisk/original/2X/4/475d0c889911cfb84ac4881ad6df8b523e3f9105.png) [@system](https://community.asterisk.org/u/system)\ **Post date:** [October 5, 2023, 1:19pm UTC](https://community.asterisk.org/t/tls-transport-the-certificate-is-untrusted-with-microsoft-teams/98434/17 "2023-10-05T13:19:22Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.