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 <[email protected]> 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 >> [email protected] <mailto:[email protected]> >> 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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
