CA Issued Certificates / TLS + SRTP

Home » Asterisk Users » CA Issued Certificates / TLS + SRTP
Asterisk Users 5 Comments

On 30/01/12 17:12, Stuart Elvish wrote:
> Hi all,
>
> Firstly, apologies if the answer to this question should be obvious.
>
> I have just started working with SRTP and had a self-signed
> certificate working perfectly. I have now purchased a CA signed
> certificate but can’t get it to work properly with Asterisk. I think I
> have a configuration error.

No, you’ve found a bug – I just posted an update about this issue
yesterday, predicting people would get stuck on this issue:

http://lists.digium.com/pipermail/asterisk-users/2012-January/269856.html

> The certificate is a GeoTrust Rapid SSL certificate. I have received
> the my server specific crt file and also an intermediate certificate.

Intermediate certificates work for some user agents (e.g. my Polycom).
There has been speculation that they won’t work with some older UAs

Ultimately, most of the budget priced certificates are signed with an
intermediate cert, and OpenSSL supports it, so there is no reason
Asterisk shouldn’t support this.

> I am not sure of the following and would greatly appreciate if someone
> could give me some guidance:
> * Can I specify the intermediate and .crt files separately in the
> sip.conf file? (I am thinking of a process similar to Apache where you
> specify three different files; server specific certificate, chain file
> and key file.)

No, for OpenSSL-based code (such as Asterisk), it works like this:

http://lists.sip-router.org/pipermail/sr-users/2012-January/071771.html

However, Asterisk needs to be patched first, as in bug 17727

> * Should the intermediate and server specific certificates be combined
> into one certificate file?

Yes, in the correct order

Currently, Asterisk expects the key and cert together in the same file:
I think that is bad, but that is the way it is:

https://issues.asterisk.org/jira/browse/ASTERISK-19267

> * And, is it necessary to use both my server specific certificate and
> the intermediate certificate on the telephones or will the telephones
> only require the server specific certificate?

The phones should already have the root certificate for Geotrust, you
should not deploy intermediate roots into the phones if you can avoid it

5 thoughts on - CA Issued Certificates / TLS + SRTP

  • Hi Daniel,
    Thank you very much for your responses! At least I only wasted 5 hours
    on the chained certificate issue.
    I have some responses / questions below.

    You asked a question as to what people have experience with. When I
    googled, the only response I found was this one which said Comodo
    didn’t work with Microsoft:
    http://pbxinaflash.com/forum/showthread.php?t=11001

    I quickly did a search using SSL shopper when I wanted to purchase a
    “real” certificate and they said all 8 certificates they had on record
    for a single domain were chained. I think this is a new requirement of
    256 bit encryption so as you pointed out (and if I read the Rapid SSL
    page properly), we aren’t going to get away from it.

    I will give this a shot later on tonight…

    If I understand this correctly (and the other emails you sent), the
    Polycom does not need any preloaded certificates / keys, it will ask
    the CA and then evaluate the certificate provided by Asterisk during
    TLS setup; is that correct?

    Kind Regards
    Stuart

  • By `preloaded’, I mean you should not have to load any certificates or
    key pairs manually into the phones

    The phones should have the default CA certs that come in the firmware

    Most recent Polycom phones also have a client certificate and private
    key built in. This allows you to secure the provisioning process.

    Some of the older Polycoms went end-of-life, some don’t have client
    certs built in, so you’ll have to research all that carefully on their
    support site. E.g. the IP 300, IP 430 and IP 500 are too old for proper
    TLS, while the IP321, IP 450 and IP550 are good

  • Thanks for the clarification. I have looked at Polycom’s website and
    saw which phones have the latest firmware (or at least a firmware that
    supports TLS) available.

    Didn’t get around to the testing with the chained certificate but will
    try again this evening.

  • One thing that frustrates people about Polycom is the very limited list
    of root CAs they support – it was probably OK when they first started
    doing SSL, but things have changed a lot now

    The latest phones (e.g. IP321) have more memory than those they replace
    (e.g. IP320) and so they should be able to handle a larger list of built
    in root CAs (which Polycom can distribute through the firmware update).
    The obvious ones that are missing are the budget CAs:

    – CaCert.org (all certs are free)
    – startssl.com (which has some free certs)
    – GoDaddy

    These budget CAs are now supported by the various Linux distributions
    and Android phones, so they are clearly above a certain threshold of
    stability

    Polycom phones should also be able to handle 4096 bit certs with the
    extra memory, but that appears to need remediation in the firmware (I
    tried installing a custom 4096 bit cert and it didn’t accept it)

    If anyone is registered with Polycom as a reseller, they can quote these
    issue numbers:

    EXT-3192 GoDaddy root CA cert
    https://jira.polycom.com:8443/browse/EXT-3192

    EXT-3193 CACert root CA cert
    https://jira.polycom.com:8443/browse/EXT-3193

    EXT-3238 Support for 4096 bit keys
    https://jira.polycom.com:8443/browse/EXT-3238

    As in most commercial enterprises, the more customers who request fixes
    on these issues, the higher it will go on their priority list