[SR-Users] TLS Certificate Verification Issue
Kamal Palei
palei.kamal at gmail.com
Mon Oct 29 10:53:16 CET 2012
Dear Klaus
Forgot to write you back otherday. I was able to trace the code that was
crashing. It was trying to free a pointer that was null. I just added a
null check. With this change, I am able to keep Kamailio up for longer
duration, did not see the crash.
Thanks Klaus for your support.
kamal
On Mon, Oct 29, 2012 at 3:14 PM, Klaus Darilion <
klaus.mailinglists at pernau.at> wrote:
> See also: http://www.kamailio.org/**dokuwiki/doku.php/**
> troubleshooting:corefiles<http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:corefiles>
>
>
>
> On 26.10.2012 11:39, Kamal Palei wrote:
>
>> Dear Klaus
>>
>> I am little bit new to linux debugging. Please let me know below stuff.
>>
>> 1. Whats the extension of core file.
>>
> The core file does not have an extension, it is usally just called
> "core.XXXX" with XXX is the process id of the crashed Kamailio process. It
> will reside in the current working directory.
>
>
> 2. Will the core files be generated in /home/user path or some other
>> default path
>>
>
> In the /etc/init.d/kamailio startup file you can configure the core
> pattern to be set before Kamailio is started. Then the core files will use
> the defined naming.
>
> On Debian also activate core dumps by editing /etc/default/kamailio
>
>
> 3. Do I need to recompile Kamailio source with -g option , or by default
>> it is compiled with -g option
>>
>
> From your log file:
>
> 0(9548) ALERT: <core> [main.c:745]: core was generated
>
> You see, your binaries already generate core files. Thus, there is no need
> to rebuild Kamailio.
>
>
> 4. I hope we need to run "ulimit" before we start the program or it is
>> not required.
>>
>
> Usually you run "ulimit -c unlimited" before starting the Kamailio process
> to be sure that the core will not be truncated.
>
>
> My observation is if I run directly kamailio it is crashing, if I run
>> with gdb it is not crashing, not sure why this happens.
>>
>
> Strange. But once you have a core file, you can analyze it and generate
> the backtrace.
>
> Also make sure to not mix openssl libraries - this is often a a problem.
>
> regards
> Klaus
>
>
>> Best Regards
>> kamal
>>
>>
>>
>> On Thu, Oct 25, 2012 at 8:01 PM, Klaus Darilion
>> <klaus.mailinglists at pernau.at <mailto:klaus.mailinglists@**pernau.at<klaus.mailinglists at pernau.at>>>
>> wrote:
>>
>> SIGABRT 6 Core Abort signal from abort(3)
>>
>> This means that there was an error condition detected in the
>> Kamailio code and the abort(3) function was called. As you see in
>> the logs a core file was generated. Find the core file and load it
>> into gdb and execute "backtrace". It will show you were the problem
>> happened and post it here.
>>
>> regards
>> Klaus
>>
>>
>> On 25.10.2012 16:23, Kamal Palei wrote:
>>
>> Dear Klaus
>> The certificate verification I have disabled.
>>
>> Facing a new problem.
>> When there is a connection reset, that time Kamailio is crashing.
>> During crash, I get below logs. Any idea why it is crashing and
>> how can
>> I avoid it.
>>
>> /oot at B2BUA:/usr/local/src/__**scripts# 9(9557) : <core>
>>
>>
>> [mem/q_malloc.c:431]: BUG: qm_free: bad pointer (nil) (out of
>> memory
>> block!) - aborting
>> 0(9548) ALERT: <core> [main.c:742]: child process 9557 exited
>> by a
>> signal 6
>> 0(9548) ALERT: <core> [main.c:745]: core was generated
>> 0(9548) INFO: <core> [main.c:757]: INFO: terminating due to
>> SIGCHLD
>> 6(9554) INFO: <core> [main.c:808]: INFO: signal 15 received
>> 8(9556) INFO: <core> [main.c:808]: INFO: signal 15 received
>> 4(9552) INFO: <core> [main.c:808]: INFO: signal 15 received
>> 5(9553) INFO: <core> [main.c:808]: INFO: signal 15 received
>> 3(9551) INFO: <core> [main.c:808]: INFO: signal 15 received
>> 7(9555) INFO: <core> [main.c:808]: INFO: signal 15 received
>> 1(9549) INFO: <core> [main.c:808]: INFO: signal 15 received
>> 2(9550) INFO: <core> [main.c:808]: INFO: signal 15 received
>> 0(9548) : <core> [mem/q_malloc.c:431]: BUG: qm_free: bad
>> pointer (nil)
>> (out of memory block!) - aborting
>>
>>
>> THANKS
>> kamal
>> /
>> On Thu, Oct 25, 2012 at 7:43 PM, Klaus Darilion
>> <klaus.mailinglists at pernau.at
>> <mailto:klaus.mailinglists@**pernau.at<klaus.mailinglists at pernau.at>
>> >
>> <mailto:klaus.mailinglists at __p**ernau.at <http://pernau.at/>
>>
>> <mailto:klaus.mailinglists@**pernau.at<klaus.mailinglists at pernau.at>>>>
>> wrote:
>>
>> Hi Kamal!
>>
>> Are you familiar with SSL/TLS and certificates? With TLS
>> the trust
>> between TLS server and TLS client is usually via a trusted
>> certification authority (CA). For example, if the
>> intermediate proxy
>> uses a certificate which is issued by CA FOOBAR-XYZ, the
>> you have to
>> configure Kamailio to accept certificates singed by
>> FOOBAR-XYZ. This
>> is done by copying the public root certificate of
>> FOOBAR-XYZ to the
>> Kamailio server and configure Kamailio to use the FOOBAR-XYZ
>> certificate as trusted CA. Of course then you automatically
>> also
>> trust all others certificates issued by FOOBAR-XYZ.
>>
>> To configure the trusted CAs use:
>> http://kamailio.org/docs/____**modules/3.3.x/modules/tls.____**
>> html#ca_list<http://kamailio.org/docs/____modules/3.3.x/modules/tls.____html#ca_list>
>> <http://kamailio.org/docs/__**modules/3.3.x/modules/tls.__**
>> html#ca_list<http://kamailio.org/docs/__modules/3.3.x/modules/tls.__html#ca_list>>
>>
>>
>>
>>
>> <http://kamailio.org/docs/__**modules/3.3.x/modules/tls.__**
>> html#ca_list<http://kamailio.org/docs/__modules/3.3.x/modules/tls.__html#ca_list>
>> <http://kamailio.org/docs/**modules/3.3.x/modules/tls.**
>> html#ca_list<http://kamailio.org/docs/modules/3.3.x/modules/tls.html#ca_list>
>> >>
>>
>> You could also disable the certificate validation with:
>> http://kamailio.org/docs/____**modules/3.3.x/modules/tls.____**
>> html#verify_certificate<http://kamailio.org/docs/____modules/3.3.x/modules/tls.____html#verify_certificate>
>> <http://kamailio.org/docs/__**modules/3.3.x/modules/tls.__**
>> html#verify_certificate<http://kamailio.org/docs/__modules/3.3.x/modules/tls.__html#verify_certificate>>
>>
>>
>>
>>
>> <http://kamailio.org/docs/__**modules/3.3.x/modules/tls.__**
>> html#verify_certificate<http://kamailio.org/docs/__modules/3.3.x/modules/tls.__html#verify_certificate>
>> <http://kamailio.org/docs/**modules/3.3.x/modules/tls.**
>> html#verify_certificate<http://kamailio.org/docs/modules/3.3.x/modules/tls.html#verify_certificate>
>> >>
>>
>> But of course this reduces TLS benefits to encryption-only.
>>
>> regards
>> Klaus
>>
>>
>> On 22.10.2012 13:53, Kamal Palei wrote:
>>
>> Dear All
>> I have modified kamailio,cfg and compiled all the
>> modules with TLS
>> enabled, and able to bring up the kamailio proxy
>> properly.
>>
>> Kamailio proxy will receive the REGISTER message from
>> endpoints
>> in UDP ,
>> and want to send this REGISTER message to another
>> intermediate
>> proxy in
>> TLS. For this purpose, I have added few lines in
>> kamailio.cfg
>> file as below.
>>
>> I have created the certificates, private keys as
>> explained by README
>> file in kamailio-3.1.5/modules/tls/ path.
>>
>> if(is_method("REGISTER"))
>> {
>> t_relay_to("tls:115.114.48.75
>> <http://115.114.48.75>:____443
>>
>> <http://115.114.48.75:443>
>>
>> <http://115.114.48.75:443>");
>>
>> exit();
>> }
>>
>> Looks like this is taking effect. When Kamailio
>> receives REGISTER
>> message it is trying to do handshake with intermediate
>> proxy.
>> I used wireshark to see the handshake messages.
>>
>> 1. From Kamailio proxy, a TCP SYNC message is going to
>> intermediate proxy.
>> 2. intermediate proxy sends SYNC + ACK
>> 3. Kamailio sends CLIENT HELLO
>> 4. intermediate proxy sends SERVER HELLO, CERTIFICATE
>> and SERVER
>> HELLO DONE
>> 5. The Kamailio sends ALERT (Level: Fatal, Description:
>> Unknown CA)
>> ---> IS something going wrong here..............
>> 6. Then Kamailio sends FIN + ACK
>>
>> Can somebody please let me know why the certificate
>> verification
>> fails
>> (I get this log in console).
>> How can I put a work around to avoid certification
>> verification
>> failure.
>>
>> Best Regards
>> kamal
>>
>>
>>
>>
>> ______________________________**_____________________
>>
>>
>> SIP Express Router (SER) and Kamailio (OpenSER) -
>> sr-users
>> mailing list
>> sr-users at lists.sip-router.org
>> <mailto:sr-users at lists.sip-**router.org<sr-users at lists.sip-router.org>
>> >
>> <mailto:sr-users at lists.sip-__**router.org<sr-users at lists.sip-__router.org>
>> <mailto:sr-users at lists.sip-**router.org<sr-users at lists.sip-router.org>
>> >>
>> http://lists.sip-router.org/__**__cgi-bin/mailman/listinfo/sr-**
>> ____users<http://lists.sip-router.org/____cgi-bin/mailman/listinfo/sr-____users>
>> <http://lists.sip-router.org/_**_cgi-bin/mailman/listinfo/sr-_**
>> _users<http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users>
>> >
>> <http://lists.sip-router.org/_**_cgi-bin/mailman/listinfo/sr-_**
>> _users<http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users>
>> <http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**
>> users <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121029/ef77c0ce/attachment-0001.htm>
More information about the sr-users
mailing list