Pages: 1 2 3

Troubleshooting the authentication

If something goes wrong, here are some things to check.

Does your Asterisk support crypto?

RSA is requiring Asterisk to be compiled with the crypto and SSL supports. During the ./configure part of the compilation, the presence of libraries and include files is checked, but if not found you will not have any warning but your Asterisk not compiled with the SSL support. To check if your installation is correct you can verify on the CLI with a:

CLI> module show like crypto
Module                         Description                              Use Count
res_crypto.so                  Cryptographic Digital Signatures         0
1 modules loaded

If the module is not printed, check your compile and your modules.conf file.

Is the key loaded?

Once crypto support is present, the appropriate key should be positioned in the /var/lib/asterisk/keys/ directory, either the .pub or the .key. To see the keys loaded in Asterisk you can issue the following command on the CLI:

CLI> keys show
Key Name           Type     Status           Sum
freeworlddialup    PUBLIC   [Loaded]         5efd552d73309f29212331a75f3c701e
Paris              PRIVATE  [Loaded]         118e9741ca91a2351a0b4f0b1e190be9
iaxtel             PUBLIC   [Loaded]         d919b3ef03eb4dc54c8fee86bfeeada1
3 known RSA keys.

By default, the freeworlddialup and iaxtel are present, here we can see that we also have the private part of the Paris RSA key.

The call is not arriving correctly

If the call is not working, you can suspect an issue with the keys. On the caller, a verbose output will only show you some congestion. To get more information you can turn on the debug at iax level (iax2 set debug). The output is really verbose, but you cansee something like the following when placing a call to the remote site:

Rx-Frame Retry[ No] — OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: AUTHREQ
   Timestamp: 00003ms  SCall: 00002  DCall: 16384 [192.168.16.41:4569]
   AUTHMETHODS     : 4
   CHALLENGE       : 204451330
   USERNAME        : TRUNK-London

Tx-Frame Retry[000] — OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: AUTHREP
   Timestamp: 00030ms  SCall: 16384  DCall: 00002 [192.168.16.41:4569]
   RSA RESULT      : HTzNEcs/qYaQimP21kBAy1KCfGDmVNoYk8go3HnG
kEOwJWvqwX7FzmMJffRHN6E4KeuHrRvppOmHU9c
SmJ7jkhrJNVLW9UBFKhN3933OT3gR9Z8xWcrMh5/
5g1jvvQGk2Zh7gKuBufSKcS9MIrCmglsuTcdY/BtnU
b32gn02Xj4=

Rx-Frame Retry[ No] — OSeqno: 001 ISeqno: 002 Type: IAX     Subclass: ACK
   Timestamp: 00030ms  SCall: 00002  DCall: 16384 [192.168.16.41:4569]
Rx-Frame Retry[ No] — OSeqno: 001 ISeqno: 002 Type: IAX     Subclass: REJECT
   Timestamp: 00015ms  SCall: 00002  DCall: 16384 [192.168.16.41:4569]
   CAUSE           : No authority found
   CAUSE CODE      : 50

First we validate the call is correctly placed to the other party, an authentication is asked for. After the authentication is proposed, we can see a reject and the cause “No authority found”. The public and private parts of the key are not coherent, recheck your keys.

Validating the keys

It could happen the key in the directory is not the good one, even with the good name and extension. The openssl package is proposing a tool to check the keys: dgst. Get both keys on the same host and create a small file on which playing the digest test:

~/tmp# echo "test" > test
~/tmp# openssl dgst -md5 -sign Paris.key -out test.sign test
~/tmp# openssl dgst -verify Paris.pub -signature test.sign test
Verified OK

If the verification fails, the public and private parts are not belonging to the same key; you will probably have to create a new one.

Pages: 1 2 3