[SR-Users] TLS Certificate Verification Issue
Kamal Palei
palei.kamal at gmail.com
Fri Oct 26 11:39:48 CEST 2012
Dear Klaus
I am little bit new to linux debugging. Please let me know below stuff.
1. Whats the extension of core file.
2. Will the core files be generated in /home/user path or some other
default path
3. Do I need to recompile Kamailio source with -g option , or by default it
is compiled with -g option
4. I hope we need to run "ulimit" before we start the program or it is not
required.
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.
Best Regards
kamal
On Thu, Oct 25, 2012 at 8:01 PM, Klaus Darilion <
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>>>
>> 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>
>> >
>>
>> 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>
>> >
>>
>> 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:**__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>>
>> 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/20121026/28727b9d/attachment.htm>
More information about the sr-users
mailing list