Correct keys loading at Asterisk startup

After I created the keys /etc/asterisk/keys according to the instructions in the wiki - when starting Asterisk, I get two errors:

NOTICE[1] res_crypto.c: Key 'asterisk' is not expected size.
WARNING[1] res_crypto.c: Key load PRIVATE 'ca' failed

When starting Asterisk, I specified the -i key. If I understand correctly, then when loading Asterisk, the keys that lie in this directory are automatically loaded. Why is this not happening? And then where do I specify the password for my key? And why does he swear at the asterisk key size?

I didn’t find any examples or answers to these questions in the documentation. I didn’t find a similar problem on the forum either, where there would be answers.

Although not well documented, the -i option appears to be there in case you have password protected private keys, so as to make sure you get a change to supply the passwords.

Most systems only have one private key.

The only directory I am aware of that gets scanned by the crypto system it the CA certificates one that one should not contain any keys. Note these are not the CA involved in signing Asterisk’s certificate, but rather the ones that might have been used to sign those of clients.

Nowhere does the tutorial imply that asterisk knows anything about /etc/asterisk/keys. The examples all show specific files in that directory being referenced. The files don’t have to be there.

I still don’t understand it yet.

  1. By default, the key directory is defined as /var/lib/asterisk/keys. User public keys are placed there, right?
  2. The CA certificate can be located anywhere and it is connected in transport?
  3. The Asterisk certificate can also be located anywhere and is also connected in transport?
  4. Why is the -i key used?
  5. Why is keys init necessary if there is no automatic loading of private keys at startup without specifying a password?

Asterisk has no need to know user public keys. They might be there, if you follow the process described, during the process of generating user certificates (although that whole process violates good security practice, as the Asterisk machine should never hold private keys - doing it on one machine is trading convenience against security).

I suspect, in general it isn’t used, as people want their Asterisk machines to restart, after a power failure, or major crash, without human intervention.

Asterisk has no need to know user public keys.

What exactly do you mean by “user” here? Asterisk certainly does need access to the public keys, in order to authenticate any calls that require them. This is necessary for IAX2 calls that use RSA authentication.

I was not aware that IAX didn’t use PKI.

I was referring to SIP devices using TLS to connect to Asterisk. Asterisk only needs to know the certificate (and therefore the public key) for the root CA used to sign the certificate chain being used by the remote device (or, if that device doesn’t provide a complete chain, one for a signer that was used in the chain supplied).

What I was getting at is that Asterisk provides a script for manufacturing PKI information, based on a corporate CA (it assumes a corporate root CA, but could be adapted for an intermediate one). That script results in both leaf certificates and leaf private keys being on the Asterisk machine, but none of these are needed at run time, and having leaf private keys there, at any time, is bad practice.

I was not aware that IAX didn’t use PKI.

It uses PKs… maybe not PKI per se. It’s keypairs on each end, generated using astkeygen.

Historically keypairs were never useful for IAX2 because until a couple years ago, encryption was only supported with MD5 authentication, not RSA authentication (yes, you read that right). Fortunately, RSA authentication is useful now.

If you want PK mangement you still need to roll your own, e.g. https://github.com/InterLinked1/phreakscript/blob/master/apps/app_keyprefetch.c

I don’t actually use that anymore, these days I just pull all the public keys once an hour so I can have a public key proactively, before a peer even calls me the first time, so it doesn’t have to fall back to MD5 auth.

The private key is also needed, for IAX2, since you need to be able to provide your private key at runtime for the IAX2 handshake, and the other peer will authenticate using your public key.

You always need your own private key if you want to authenticate yourself using public keys.

This isn’t for authenticating yourself per se, it’s to be able to engage in the handshake such that another peer can identify you. So it’s the same type of process as in normal PK usage, really. I guess your comment “having leaf private keys there, at any time, is bad practice.” was about something more specific - in some protocols you can get away with not storing the SK but not in this case here.

I’m talking about asterisk/ast_tls_cert at master · asterisk/asterisk · GitHub when used in client mode. This is the underlying tool when FreePBX users say they are using a self signed certificate, although the working certificates aren’t self signed. This uses directories which indicates that it is expected to be run on the Asterisk machine, when it really should be run on a machine with an air gap from the internet.

So, as I understand it, IAX does not use SSL/TLS, it applies RSA encryption directly. So you set up a public/private key pair for each end, and copy each end’s public key to the other end. Each end loads its private key via the “outkey=” option, and any number of public keys from other ends via the “inkeys=” option.

Hard for me to check, as Debian doesn’t seem to include any IAX-speaking software in its standard repo any more.

I’m talking about asterisk/ast_tls_cert at master · asterisk/asterisk · GitHub when used in client mode

Okay, I see. IAX2 doesn’t use that. Keys are generated using astkeygen, it’s separate from anything you might do for SIP with TLS.

Hard for me to check, as Debian doesn’t seem to include any IAX-speaking software in its standard repo any more.

chan_iax2 is the IAX speaking software, most of the other implementations based on libiax are obsolete, since libiax is itself obsolete. Your comment is accurate though. You can apply the outkey dynamically at runtime, but inkeys need to be specified in advance.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.