Summary:	ASTERISK-25659: res_rtp_asterisk: ECDH not negotiated causing DTLS failure occurred on RTP instance
Reporter:	Edwin Vandamme (pay123)	Labels:
Date Opened:	2016-01-05 02:29:39.000-0600	Date Closed:	2016-07-14 09:56:45
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_rtp_asterisk
Versions:	11.22.0 13.9.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	Using the following on the server : CentOS 7.2 2015-11 Asterisk 13.6 2015-10 jansson 2.7 2014-10-02 PJSIP (pjproject) 2.4.5 2015-08-12 sipML5 2.0.2 2015-12 Using the following on the client : CentOS 7.2 KDE desktop Chrome Version 47.0.2526.106 (64-bit)	Attachments:	( 0) asterisk.log ( 1) dtls_centos_step_1.patch ( 2) dtls_centos_step_2.patch ( 3) ecdh.patch ( 4) openssl.spec.patch ( 5) openssl-1.0.1e-ecdh-auto-dtls.patch
Description:	This issue has been on the forum for over a week, but I did not get any feedback, http://forums.asterisk.org/viewtopic.php?f=1&t=96461&sid=528c724d236a38e60e868817462c6f26, so I have now escalated this as a bug report. Using the described environment, I get the following error in my Asterisk log : res_rtp_asterisk.c: DTLS failure occurred on RTP instance '0x7fe8c8024178' due to reason 'missing tmp ecdh key', terminating res_rtp_asterisk.c: RTP Read error: Unspecified. Hanging up. An earlier bug report listed this as a problem on FireFox : ASTERISK-25265 It is said to be fixed in 13.6 WebRTC is not yet in production on my system, due to the constant changes, but in earlier tests everything worked fine. As far as I can tell, it all started when Chrome forced the usage of https over http. Dialing from a WebRTC peer to Asterisks works just fine. For various reasons I use sip.conf, not pjsip.conf. Certificates used are propper certificates, not self signed versions. I attached (asterisk.log) part of the Asterisk log file with "sip debug on", start of call till failure.
Comments:	By: Asterisk Team (asteriskteam) 2016-01-05 02:29:41.507-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Edwin Vandamme (pay123) 2016-01-05 02:56:54.431-0600 Asterisk log of the issue with sip debug information. By: Joshua C. Colp (jcolp) 2016-01-05 06:16:24.623-0600 What version of OpenSSL is in use, does it have ECDH Auto support? does it have prime256v1 ec key support? Without these then OpenSSL won't generate an ecdh key and you will see exactly what you're seeing. "openssl version" will show the version "openssl ecparam -list_curves" will list the ECDH curves. "prime256v1" being the required one. I know of others using Chrome 47 (there's been other issues reported while using it) so it does appear to be working for others. By: Edwin Vandamme (pay123) 2016-01-05 07:58:37.283-0600 Joshua, As requested : OpenSSL version :  OpenSSL 1.0.1e-fips 11 Feb 2013 OpenSSL ecparam :  secp384r1 : NIST/SECG curve over a 384 bit prime field  secp521r1 : NIST/SECG curve over a 521 bit prime field  prime256v1: X9.62/SECG curve over a 256 bit prime field Looks OK from what you are saying. Is there an order that can be set for the curves ? By: Joshua C. Colp (jcolp) 2016-01-05 08:02:35.710-0600 Unless one can be set in OpenSSL - nope. The code either requests automatic ecdh support (if available) or explicitly the prime256v1 curve otherwise. The rest is up to OpenSSL. By: Edwin Vandamme (pay123) 2016-01-05 08:14:47.557-0600 Joshua, Just to make sure I also tried on a Windows 8 with Chrome, but to no avail. Could it be in the generation of the certificate request ? Create CSR and key file. (line is displayed weird but I supose you can make sense of it) {noformat} openssl req -new -newkey rsa:4096 -nodes -out ${KFN}/${KNM}.csr -keyout ${KFN}/${KNM}.key -subj "/C=${CO}/ST=${ST}/L=${LO}/O=${OR}/OU=${OU}/CN=${CN}/emailAddress=${EM}" {noformat} ${} values are the corresponding parameter values. By: Joshua C. Colp (jcolp) 2016-01-05 08:19:53.981-0600 I have not touched WebRTC in months so I do not recall, and the changes to add ecdh came from the community so I did not dive deeply into things for it. By: Edwin Vandamme (pay123) 2016-01-05 10:02:29.808-0600 Any suggestions as where to look? As Google search only led me to the original FireFox bug report. I am pretty capable at coding, but never dived into the Asteriks project, so if you point me into the right direction I might be able to trace down the issue at hand. By: Joshua C. Colp (jcolp) 2016-01-05 11:12:41.074-0600 The res_rtp_asterisk.c file in res contains the DTLS handling code, for ecdh support there is only a tiny part that tells OpenSSL to enable it. By: Edwin Vandamme (pay123) 2016-01-05 13:56:35.085-0600 Found the problem, only need to discuss the propper solution. ./configure detects and sets "#define HAVE_OPENSSL_ECDH_AUTO 1" So I tried and activate the code that would have been used if this was not set and presto it works right away. What would be the propper procedure to fix this ? Looks like the setting is not propperly detected. By: Joshua C. Colp (jcolp) 2016-01-05 14:02:46.428-0600 There is logic in configure.ac which determines whether the underlying function is available. It assumes that if the function is available from OpenSSL then it can be used. As to why the OpenSSL function isn't working in your case I have no idea. I'd focus on that instead, as it should be. By: Edwin Vandamme (pay123) 2016-01-05 14:21:17.331-0600 I agree, this needs some more investigation. I will look into this and report back here. To me it is a grey area as to wether this is an Asterisk bug or an OpenSSL bug at the moment, so I am not sure if you can close the bug report or not. For now at least people with the same problem can easily fix it. By: Joshua C. Colp (jcolp) 2016-01-05 19:02:47.719-0600 I'm leaving this in feedback until your further investigation yields anything. By: Edwin Vandamme (pay123) 2016-01-10 07:12:37.796-0600 I have been looking at a lot of information in order to figure out what is actually happening and the following is a step by step walk through my thinking process, so apologies for any mistakes. 1) Test connection to see what cipher is being used with and without the previous suggested code modification. {quote}openssl s_client -connect __MYDOMAIN__:8089{quote} Both instances secp521r1 curve is selected not prime256v1, so this might not be a proper test but may tell us that secp521r1 is the prefered curve for SSL_CTX_set_ecdh_auto. To find out what curves are supported : {quote}openssl ecparam -list_curves{quote} This lists : {quote} secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field {quote} So from the earlier tests we might conclude that the order set in openssl is not important SSL_CTX_set_ecdh_auto seems to select the most stringent curve. 2) There are known limitations on RedHat EL and CentOS with openssl as RedHat is very restrictive as it comes down to openssl, which makes sense to guarantee best security and this is also the reason I would prefer to stick to this openssl version.. 3) However, rebuilding openssl from source did not fix the problem. 4) The cipher can be set for Asterisk with tlscipher= in sip.conf, but that does not allow you to set the curve being used, so that is not an option. 5) So what if the curve order or the available curves could be set in Asterisk ? Prior to executing SSL_CTX_set_ecdh_auto a curve list can be set as follows : {quote}SSL_CTX_set1_curves_list(rtp->ssl_ctx, "P-256\:P-521\:P-384");{quote} or as P-256 is the one required just : {quote}SSL_CTX_set1_curves_list(rtp->ssl_ctx, "P-256");{quote} Unfortunately this function does not exist in ssl.h for RedHat/CentOS, probably for security reasons, so I regard this as a no go in case the same issue arises on other systems. The function exists in the openssl.org source code. In any event, I do feel this defies the use of SSL_CTX_set_ecdh_auto. 6) Another option would be to test SSL_CTX_set_ecdh_auto and fallback to SSL_CTX_set_tmp_ecdh on communication failure, though this might overcomplicate the code. 7) The only solution I can see that will fit all installations is to forget about SSL_CTX_set_ecdh_auto altogether, yes I know that is the recommended solution. There is the possibility to set the usage in sip.conf, but why overcomplicate the configuration as there are already too many issues with webRTC to begin with. (Patch included if you feel this is the best solution) As a final remark, I wish to point out that I have little experience in these openssl matters, so I might be completely in the wrong ballpark regarding the above, in which case I gladly stand corrected. By: Alex Villacís Lasso (a_villacis) 2016-01-19 17:09:25.757-0600 Confirming. This also happens on asterisk-11.21.0, and disabling the call to SSL_CTX_set_ecdh_auto() and using the fallback instead fixes SIP.js answering the call from Asterisk under Firefox 43 on Fedora 23. By: Edwin Vandamme (pay123) 2016-01-20 14:33:00.684-0600 For information purposes : the same issue exists in version 13.7.0. By: Sylvester Kuisis (gl1tchh) 2016-02-29 20:10:43.746-0600 For information purposes: the same issue exists in version 13.7.2. The patch included here resolves it. By: Richard Mudgett (rmudgett) 2016-04-27 09:48:28.416-0500 The [^ecdh.patch] is not marked as a contribution so it cannot go into Asterisk. By: Alexander Traud (traud) 2016-06-22 08:09:09.128-0500 CentOS 7 has added the symbol {{SSL_CTX_set_ecdh_auto}} in the header file {{openssl/ssl.h}} of their package {{openssl-devel}}. Therefore, the configure script of Asterisk detects this symbol to be available. It looks like, the CentOS team has backported that feature from the official OpenSSL 1.0.2 to their OpenSSL 1.0.1. Edwin, one approach would be to file a support request (or bug report) with the CentOS team, how/when their {{SSL_CTX_set_ecdh_auto}} should be used. Whether it needs any additional initialization or what. Alternatively, please, find the source code of their OpenSSL port. Then, I have a look what magic the CentOS team did. Yet, I was not able to find the code, to investigate deeper. Anyway, to get this issue fixed here in Asterisk, I adopted the approach of [~sarumjanuch], who copied my existing (and working) PFS code from {{main/tcptls.c}} (see his attachment {{res_rtp_asterisk.patch}} in ASTERISK-25265. For up-to-date changes, see the [added link|https://gerrit.asterisk.org/3066] to the review-board Gerrit, {{dtls_centos_step_1.patch}}, and {{dtls_centos_step_2.patch}}. Those patches were tested with Google Chrome 51.0 and Mozilla Firefox 47.0. I tested with ECDHE-only cipher-suites. With DHE-only cipher-suites. With DHE-only cipher-suites without DH parameters. Both directions: Web browser as caller and callee. Furthermore, that original code for TLS was in Asterisk 13 since day one. Asterisk 13 is a production release since October 2014. By the way, [~urbaniak] reported this issue with CentOS 7 back in August 2015 already. Unfortunately, he did not create a new issue or re-opened ASTERISK-25265. His report got missed. Therefore with that CentOS issue, please, let us continue here in this issue report. By: Edwin Vandamme (pay123) 2016-06-22 14:48:09.352-0500 Alexander, I have been using Asterisk 13 from day one as I upgraded from 12. The problem only popped up after 13.6 . Though shortly before that CentOS upgraded from 7.1 to 7.2 (that would have been 201511) If I remember correctly I did switch back to 13.5 and that did not have a problem with CentOS 7.2. I did try installing OpenSSL (not the centOS version) on CentOS 7.2 from source and that showed the same problem. All this led me to believe the problem lies with Asterisk. In hindsight I rather think it has to do with the picking order of the required cipher. I believe recently there was something released to set the available ciphers, so that might fix the problem, but I need to dive into it again to be 100% sure. So I will try and : 1) get the CentOS code for OpenSSL, so you can have a look at it. 2) verify if the cipher can be set. 3) verify if the latest Chrome 51.0.2704.84 (64-bit) might fix the problem (in case the browser selects the cipher) As my systems are still not in production (don't you hate that), I have the means to do some testing on a real life environment instead of a test environment. By: Edwin Vandamme (pay123) 2016-06-24 02:32:25.484-0500 1) CentOS sources are available from : http://vault.centos.org/7.2.1511/os/Source/SPackages/ 2) Looking into that. 3) Chrome 51.0.2704.84 (64-bit) did not fix the problem. By: Alexander Traud (traud) 2016-06-27 07:27:56.187-0500 Since June 2015, Firefox requires PFS based cipher suites for DTLS. Asterisk 13.6.0 added support for PFS because its DTLS part should have allowed PFS since day one, in October 2012. By this change, one additional symbol of OpenSSL is used, because with PFS not just the ‘Cipher Suite’ but an ‘Elliptic Curve’ must be negotiated as well. A web browser lists his Elliptic Curves, for example: - Google Chrome 51.0 sends {{0x001d, secp256r1, secp384r1}} - Mozilla Firefox 47.0 sends {{secp256r1, secp384r1, secp521r1}} Asterisk (actually OpenSSL within Asterisk) goes for the first supported curve. Therefore, {{secp256r1}} in any case. The symbol {{SSL_CTX_set_ecdh_auto}} is available only with newer versions of OpenSSL but offers the possibility to auto-negotiate. Therefore the author -- who added PFS for DTLS ([~mwduncan]) -- changed the configure script of Asterisk to detect whether that auto-negotiate symbol is present in your OpenSSL or not. That change of Asterisk 13.6.0 was of no issue on Ubuntu 14.04 LTS or Ubuntu 16.04 LTS. Even CentOS 6 is of no issue. This is an interoperability issue with CentOS 7. The CentOS team backported {{SSL_CTX_set_ecdh_auto}} from OpenSSL 1.0.2 to their OpenSSL 1.0.1. However, that backport does not work as expected. Or stated differently: A change in Asterisk 13.6.0 _revealed_ an issue on CentOS 7. If you want to workaround that from a configuration file, you have to go for {{dtlscipher=AES128-SHA}}. The list of cipher-suites on the HTTP (Secure WebSocket) layer do not matter because that is TLS. It is just the DTLS layer, which has this issue. However with that solution, you disable PFS and therefore loose compatibility with Mozilla Firefox. That source code and [this patch list|https://git.centos.org/tree/rpms!openssl!/5fee79a733e7bcfa468ae8f400bad40a1002c8c5/SOURCES] confirms that the CentOS team backported that feature. However, it does not work as expected. I was not able to find the difference/cause on the first glance, therefore please, file a bug report with CentOS. By the way, could you please test Mozilla Firefox? Perhaps it is this first unsupported Elliptic Curve which causes this issue in that backport. I looked through the backport but did not see why it fails. However, a more concrete analysis would take much longer. If you could debug your OpenSSL and determine which Elliptic Curve is returned by {{tls1_shared_curve}} within OpenSSL -- that might help the CentOS team to find the cause. I hope this clarifies the situation. When there are any further questions, please, do not hesitate to ask. As a workaround, I modified my TLS-PFS patch for DTLS. That change is exactly your proposed solution (6) from January. That solves the issue with is specific to CentOS 7. By: Edwin Vandamme (pay123) 2016-06-28 09:09:04.970-0500 Alexander, Thanks for the clarification, it all makes a lot of sence. However I did install OpenSSL from source and I still had the issue, this made me think the issue was Asterisk related. For now I will stick to my patch, but I will make some time to investigate further as soon as possible. I will try Firefox withouth the patch and look into this Chrome curve issue. By: Edwin Vandamme (pay123) 2016-06-28 14:17:40.732-0500 Alexander, Firefox 45.2.0 has the same problem, it is also fixed with my patch. By: Alexander Traud (traud) 2016-06-28 14:36:06.411-0500 I did not understand which OpenSSL you tried – if you do not want to face this issue, you have to go for not for the CentOS 7 variant but an unpatched OpenSSL 1.0.1 or unpatched/vanilla OpenSSL 1.0.2 or the (patched) variant of CentOS 6. By the way, did you try my patch(es)? You have to apply both, one (step 1) by one (step 2). That implements your proposed solution 6. By: Edwin Vandamme (pay123) 2016-06-29 03:29:20.999-0500 I tried the source from https://www.openssl.org/, at the time that would have been version 1.0.2e. To make sure I did not make a mistake during installing this version, I will set up a test environment to try this again. This is not the kind of thing I like to try on an intended production server. In case this works, I will file a bug report at CentOS. Yes I tried your patches, but I have the same error. As my test PC also uses CentOS 7.2, I verified Chrome on a Windows PC and that has the same issues. There is an OpenSSL upgrade (v1.0.1e-51) for CentOS. For some reason this version also displays "OpenSSL 1.0.1e-fips 11 Feb 2013", though file date is May 9 2016. Unfortunately, no fix for the problem. By: Alexander Traud (traud) 2016-06-29 05:01:55.966-0500 Some distributions stick with one OpenSSL version and patch for the latest updates. By the this, the displayed date/version do not change. Anyway, if you go for my patch and (on the command line interface of Asterisk) change {{core set verbose 2}}, do you see {{DTLS ECDH initialized (automatic)}} while you call your web browser? By: Edwin Vandamme (pay123) 2016-06-29 12:45:55.190-0500 I expected that would be the reason for the OpenSSL version, makes it harder to detect problems in a specific version but then each to their own. As for your patch, this is displayed in the console : {quote}Connected to Asterisk 13.9.1 currently running on server (pid = 43787) call-01*CLI> core set verbose 2 Console verbose was OFF and is now 2.  == WebSocket connection from '1.2.3.4:37637' for protocol 'sip' accepted using version '13'  == WebSocket connection from '1.2.3.4:37638' for protocol 'sip' accepted using version '13'  == DTLS ECDH initialized (automatic), faster PFS cipher-suites enabled  == Using SIP RTP TOS bits 184  == Using SIP RTP CoS mark 5  == DTLS ECDH initialized (automatic), faster PFS cipher-suites enabled  == Using SIP RTP TOS bits 184  == Using SIP RTP CoS mark 5 {quote} This is in the normal logs : {quote}[Jun 29 17:40:04] VERBOSE[44757][C-00000002] pbx.c: Executing [C@C-Node:77] Dial("SIP/1-00000000", "SIP/id-to-call,20,gm(SIP/1-00000000-1)U(H-CALLED^SIP/1-00000000^1018^/files/moh.wav)") in new stack [Jun 29 17:40:04] VERBOSE[44757][C-00000002] res_rtp_asterisk.c: DTLS ECDH initialized (automatic), faster PFS cipher-suites enabled [Jun 29 17:40:04] VERBOSE[44757][C-00000002] netsock2.c: Using SIP RTP TOS bits 184 [Jun 29 17:40:04] VERBOSE[44757][C-00000002] netsock2.c: Using SIP RTP CoS mark 5 [Jun 29 17:40:04] VERBOSE[44757][C-00000002] app_dial.c: Called SIP/id-to-call [Jun 29 17:40:04] VERBOSE[44757][C-00000002] res_musiconhold.c: Started music on hold, class 'SIP/1-00000000-1', on channel 'SIP/1-00000000' [Jun 29 17:40:04] VERBOSE[44757][C-00000002] app_dial.c: SIP/id-to-call-00000001 is ringing [Jun 29 17:40:04] ERROR[44757][C-00000002] res_rtp_asterisk.c: DTLS failure occurred on RTP instance '0x7fc05c017e98' due to reason 'missing tmp ecdh key', terminating [Jun 29 17:40:04] WARNING[44757][C-00000002] res_rtp_asterisk.c: RTP Read error: Unspecified.  Hanging up. [Jun 29 17:40:04] VERBOSE[44757][C-00000002] app_dial.c: No one is available to answer at this time (1:0/0/0) [Jun 29 17:40:04] VERBOSE[44757][C-00000002] res_musiconhold.c: Stopped music on hold on SIP/1-00000000 {quote} By: Edwin Vandamme (pay123) 2016-06-29 15:38:04.737-0500 I managed to install a test environment and installed OpenSSL from source as follows : - yum remove openssl (remove the CentOS OpenSSL version) - curl -O https://www.openssl.org/source/openssl-1.0.2h.tar.gz (download latest version) - Compile and install the extracted tar with the following script : {code}#!/bin/bash # Variables. SN="${0##*/}"                                               # Script name. SD="${0:0:${#0}-${#SN}}"                                    # Script location. # Compile new version. ---------------------------------------------------------- cd ${SD} OD=$(ls -d openssl*/) cd ${SD}${OD} make clean ./config --prefix=/usr/local --openssldir=/usr/local/openssl make make test make install {code} - reboot - openssl version ==> OpenSSL 1.0.2h  3 May 2016 (check OpenSSL version) - Recompile and install Asterisk 13.9.1 - Perform the test and again the DTLS error. All I can think off is that some CentOS code is left behind after the removal and/or the OpenSSL installation does not write all the files to the "CentOS locations". By: Edwin Vandamme (pay123) 2016-07-01 14:07:51.169-0500 Clearly there are some leftovers from CentOS, but I am not 100% sure that by now I removed everything correctly. There still is the folder /usr/lib64/openssl/engines, wich apears to have old libraries in it. In any case, I had to change the line : {code}./config --prefix=/usr/local --openssldir=/usr/local/openssl{code} to : {code}./config --prefix=/usr --openssldir=/usr/include/openssl{code} Next I rebooted and recompiled Asterisk. The RTP error has gone, but now I have the following error : {color:red}*chan_sip.c: Got SIP response 603 "Failed to get local SDP" back from...*{color} I assume there still is a conflict between the CentOS OpenSSL en the openssl.org OpenSSL, as soon as I figured that one out I am ready to escalate this to CentOS or RedHat. By: Alexander Traud (traud) 2016-07-05 07:46:32.289-0500 Instead of replacing OpenSSL systemwide, I would go for a custom OpenSSL just for Asterisk. Examples for this are shown in ASTERISK-24815 and ASTERISK-25043. Furthermore, I recommend to insert {{SSLeay()}} and {{OPENSSL_VERSION_NUMBER}} somewhere in the code of Asterisk. That makes sure, you picked the right library version and the headers match the source code. Anyway, I installed CentOS Linux 7 (1511) and analyzed this issue in depth. The team of Red Hat [backported|https://bugzilla.redhat.com/show_bug.cgi?id=1080128] {{SSL_CTX_set_ecdh_auto}}. With OpenSSL 1.0.2, the source code for TLS and DTLS got merged. Therefore in OpenSSL 1.0.1, that backport is incomplete and works for TLS only. It does not work for DTLS. The OpenSSL internal method {{dtls1_send_server_key_exchange}} (thanks to [{{ERR_func_error_string}}|https://www.openssl.org/docs/manmaster/crypto/ERR_error_string.html]) does not contain any auto code and raises the mentioned error. Since OpenSSL 1.0.2, {{ssl3_send_server_key_exchange}} manages both TLS and DTLS. I changed my patch to cope with that situation. Please, see the newly attached {{dtls_centos_step_2.patch}}. Technically, it does not do anything different than your patch because in CentOS Linux 7, {{SSL_CTX_set_ecdh_auto}} does nothing in DTLS. Or stated differently: Your patch and my patch avoid that error. Anyway, I submitted {{dtls_centos_step_2.patch}} as solution for code review. That issue should be fixed with Asterisk 13.11.0 then. Until then, please, apply {{_step_1.patch}} and then {{_step_2.patch}}. I created {{openssl-1.0.1e-ecdh-auto-dtls.patch}}, to enable {{SSL_CTX_set_ecdh_auto}} even for DTLS in CentOS Linux. However, that change is not required in production code, because all known WebRTC clients use/offer {{secp256r1}}. Therefore, just for completeness until this is fixed in RHEL and then in CentOS Linux itself: {noformat}sudo yum install patch rpm-build mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros wget vault.centos.org/7.2.1511/updates/Source/SPackages/openssl-1.0.1e-51.el7_2.5.src.rpm rpm -ivh ./openssl-1.0.1e-51.el7_2.5.src.rpm wget issues.asterisk.org/jira/secure/attachment/54082/openssl-1.0.1e-ecdh-auto-dtls.patch mv ./openssl-1.0.1e-ecdh-auto-dtls.patch ~/rpmbuild/SOURCES/ cd ~/rpmbuild/SPECS/ wget issues.asterisk.org/jira/secure/attachment/54083/openssl.spec.patch patch -p0 <./openssl.spec.patch rpmbuild -ba ./openssl.spec cd ~/rpmbuild/RPMS/`uname -i`/ sudo rpm -ivh --force ./openssl-libs-1.0.1e-51.el7.centos.5.x86_64.rpm{noformat}Because of [another bug|https://bugzilla.redhat.com/show_bug.cgi?id=1335097], you have to change the date/time of your computer to 5/5/2016 before you build the libraries. Before you go for those steps, please, double-check if not a newer OpenSSL [for 7.2.1511|http://vault.centos.org/7.2.1511/updates/Source/SPackages/] or even a [newer CentOS Linux|http://vault.centos.org/] is available in the meantime. Otherwise you overwrite your OpenSSL with an older version. Thanks to [this|http://bradthemad.org/tech/notes/patching_rpms.php] and [that|https://wiki.centos.org/TipsAndTricks/UsingNetatalk] guides. By: Edwin Vandamme (pay123) 2016-07-05 14:01:07.291-0500 Thanks for investigating further, it would have taken me a lot longer to get my head around this issue due to inexperience with the finer details of OpenSSL. I will study your suggestions and the links suplied, though it might take a while as a need to get a few other things sorted ASAP. My main concern is to get this fixed for the community, for my purpose it is currently fixed, though I like a neat solution (my fix is not). By: Alexander Traud (traud) 2016-07-06 10:38:45.587-0500 Edwin, I am not sure, I got your concern. The attached Asterisk patch retains functionality for non-CentOS users, avoids that error for CentOS  users, and leverages auto-negotiation when CentOS is fixed. Do you see any outstanding issue with that patch? That is your proposed solution 6 from January. Actually, you do not have to do anything because you patched/fixed that issue yourself already. Those patches are just to create a working out-of-the-box experience. By: Edwin Vandamme (pay123) 2016-07-07 01:39:26.593-0500 Alexander, sorry for the confusion. I meant actually get it fixed by RedHat or CentOS in the end. I will check out your latest patches and get back to you on the results. By: Edwin Vandamme (pay123) 2016-07-07 02:21:35.158-0500 At time of writing it is still CentOS 7.2 (1511) with the earlier mentioned openssl upgrade v1.0.1e-51. After installing _step_1.patch and then _step_2.patch I get the following error in the Asterisk log. {color:red}chan_sip.c: Got SIP response 603 "Failed to get local SDP" back from 11.22.33.44:38731{color} I did not install the OpenSSL patch as I tried the patches on my production system and I am trying the out-of-the-box experience. {code} [Jul  7 06:52:50] VERBOSE[60744][C-00000002] pbx.c: Executing [C@C-Node:77] Dial("SIP/1-00000000", "SIP/id-to-call,20,gm(SIP/1-00000000-1)U(H-CALLED^SIP/1-00000000^1020^/files/moh.wav)") in new stack [Jul  7 06:52:50] VERBOSE[60744][C-00000002] res_rtp_asterisk.c: DTLS ECDH initialized (automatic), faster PFS enabled [Jul  7 06:52:50] VERBOSE[60744][C-00000002] netsock2.c: Using SIP RTP TOS bits 184 [Jul  7 06:52:50] VERBOSE[60744][C-00000002] netsock2.c: Using SIP RTP CoS mark 5 [Jul  7 06:52:50] VERBOSE[60744][C-00000002] app_dial.c: Called SIP/id-to-call [Jul  7 06:52:50] VERBOSE[60744][C-00000002] res_musiconhold.c: Started music on hold, class 'SIP/1-00000000-1', on channel 'SIP/1-00000000' [Jul  7 06:52:51] VERBOSE[60744][C-00000002] app_dial.c: SIP/id-to-call-00000001 is ringing [Jul  7 06:52:51] VERBOSE[60733][C-00000002] chan_sip.c: Got SIP response 603 "Failed to get local SDP" back from 11.22.33.44:38731 [Jul  7 06:52:51] VERBOSE[60744][C-00000002] app_dial.c: SIP/id-to-call-00000001 is busy [Jul  7 06:52:51] VERBOSE[60744][C-00000002] app_dial.c: Everyone is busy/congested at this time (1:1/0/0) [Jul  7 06:52:51] VERBOSE[60744][C-00000002] res_musiconhold.c: Stopped music on hold on SIP/1-00000000 {code} By: Edwin Vandamme (pay123) 2016-07-07 02:41:44.262-0500 Alexander, strike the above comment. I removed everything and reapplied the patches and *now everything works* as it should. No idea what went wrong, I assume human error where I mixed up one of the versions that I have on the system. By: Alexander Traud (traud) 2016-07-07 05:36:25.400-0500 When it comes about fixing this upstream, I [filed that patch|https://bugzilla.redhat.com/show_bug.cgi?id=1352941] with Red Hat and mentioned you as reporter. If I understand correctly, if an OpenSSL issue is fixed there, the change moves down to CentOS Lunix one day. However, please, double-check. Consequently, everything is done from your and my side. Now, those changes have to be integrated by the project maintainers and released. Even that is on track already. By: Edwin Vandamme (pay123) 2016-07-07 05:42:48.641-0500 Thanks for reporting this at RedHat. This will indeed filter down to CentOS. I will keep an eye on this and report back when an unmodified Asterisk 13.9.1 works with the latest OpenSSL on CentOS. In the mean time I will keep using your patch and keep upgrading Asterisk. I asume your patch will go into 13.11.0.