[SR-Users] Using wildcard certificates for Kamailio server

Mark Boyce mark at darkorigins.com
Fri Aug 7 11:02:48 CEST 2020


Hi

(At a quick read) That RFC restriction is crazy!

As Daniel says, you can code whatever you want on the Kamailio end.  

My thoughts are drifting towards the phone/users end, and wondering about them rejecting a wildcard certificate on the server because their developer has implemented to the letter of the RFC.

However there’s also talk of DNS there and no talk of subject-name vs alternatives.  So I’m wondering if this would pass the RFC rules;

IP: 1.2.3.4 which resolves to server42.sip.myserver.com <http://sip.myserver.com/>

SIP Domain: customer1.pbxhost.com <http://customer1.sip.mysever.com/>

Certificate;
Subject Name : server42.sip.myserver.com <http://sip.myserver.com/>
Alternative Name : *.pbxhost.com

Which means DNS can fully match the FQDN in the certificates subject name, and everything else is covered by the alternative name

...maybe?


Mark

> On 7 Aug 2020, at 09:08, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> Hello,
> 
> I was not aware of this constraint and I used wildcard certificates so far with Kamailio and all was ok.
> 
> If you want to be strict on this RFC, then you can do additional checks in the config file, because the validation of tls certificate is performed by libssl and it returns ok for wildcard certificates. There might be options for libssl to disable wildcard matching, but I haven't looked for.
> 
> Cheers,
> Daniel
> On 06.08.20 14:37, Leonid Fainshtein wrote:
>> Hello,
>> Is it permitted to use the wildcard TLS certificates for Kamailio server?
>> In reality, it works (tested with v.5.4) but the RFC-5922 disables the wildcard certificates usage:
>> 
>> "Implementations MUST match the values in their entirety:
>>          Implementations MUST NOT match suffixes.  For example,
>>          "foo.example.com <http://foo.example.com/>" does not match "example.com <http://example.com/>".
>> 
>>          Implementations MUST NOT match any form of wildcard, such as a
>>          leading "." or "*." with any other DNS label or sequence of
>>          labels.  For example, "*.example.com <http://example.com/>" matches only
>>          "*.example.com <http://example.com/>" but not "foo.example.com <http://foo.example.com/>".  Similarly,
>>          ".example.com <http://example.com/>" matches only ".example.com <http://example.com/>", and does not match
>>          "foo.example.com <http://foo.example.com/>".
>> (Ref.:https://tools.ietf.org/html/rfc5922#section-7.2 <https://tools.ietf.org/html/rfc5922#section-7.2>)
>> To be honest, I don't understand why this restriction is good for...
>> Is somebody aware of a newer RFC that removes this limitation?
>> 
>> Best regards,
>> Leonid Fainshtein
>> 
>> 
>> 
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>_______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200807/dcbc6ddf/attachment.htm>


More information about the sr-users mailing list