<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Mark,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In my opinion, the Common Name (CM) is ignored when SAN is present. Therefore, according to RFC-5922 the server identity will not be confirmed and the connection must fail.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Anyway, I wrote a message to <span style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><a href="mailto:sipcore@ietf.org">sipcore@ietf.org</a> with a suggestion to remove the restriction despite I am almost sure that the message will be ignored...</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px">But I still try to understand why the smart guys who wrote the RFC had put this limitation. The RFC was also publicly reviewed. I am afraid that I am missing something...</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><br></span></div><div><div dir="ltr" data-smartmail="gmail_signature">Best regards,<br>Leonid Fainshtein<br><br></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 7, 2020 at 12:02 PM Mark Boyce <<a href="mailto:mark@darkorigins.com" target="_blank">mark@darkorigins.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi<div><br></div><div>(At a quick read) That RFC restriction is crazy!</div><div><br></div><div>As Daniel says, you can code whatever you want on the Kamailio end. </div><div><br></div><div>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.</div><div><br></div><div>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;</div><div><br></div><div>IP: 1.2.3.4 which resolves to <a href="http://sip.myserver.com" target="_blank">server42.sip.myserver.com</a></div><div><br></div><div>SIP Domain: <a href="http://customer1.sip.mysever.com" target="_blank">customer1.pbxhost.com</a></div><div><br></div><div>Certificate;</div><div>Subject Name : <a href="http://sip.myserver.com" target="_blank">server42.sip.myserver.com</a><br>Alternative Name : *.<a href="http://pbxhost.com" target="_blank">pbxhost.com</a></div><div><br></div><div>Which means DNS can fully match the FQDN in the certificates subject name, and everything else is covered by the alternative name</div><div><br></div><div>...maybe?</div><div><br></div><div><br></div><div>Mark<br><div><br><blockquote type="cite"><div>On 7 Aug 2020, at 09:08, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>> wrote:</div><br><div>
<div><p>Hello,</p><p>I was not aware of this constraint and I used wildcard
certificates so far with Kamailio and all was ok.</p><p>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.</p><p>Cheers,<br>
Daniel<br>
</p>
<div>On 06.08.20 14:37, Leonid Fainshtein
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hello,<br clear="all">
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Is it permitted
to use the wildcard TLS certificates for Kamailio server?</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In reality, it
works (tested with v.5.4) but the RFC-5922 disables the
wildcard certificates usage:</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">"<span style="font-family:Arial,Helvetica,sans-serif">Implementations
MUST match the values in their entirety:</span></div>
<pre> Implementations MUST NOT match suffixes. For example,
"<a href="http://foo.example.com/" target="_blank">foo.example.com</a>" does not match "<a href="http://example.com/" target="_blank">example.com</a>".
Implementations MUST NOT match any form of wildcard, such as a
leading "." or "*." with any other DNS label or sequence of
labels. For example, "*.<a href="http://example.com/" target="_blank">example.com</a>" matches only
"*.<a href="http://example.com/" target="_blank">example.com</a>" but not "<a href="http://foo.example.com/" target="_blank">foo.example.com</a>". Similarly,
".<a href="http://example.com/" target="_blank">example.com</a>" matches only ".<a href="http://example.com/" target="_blank">example.com</a>", and does not match
"<a href="http://foo.example.com/" target="_blank">foo.example.com</a>".
</pre>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">(Ref.:<a href="https://tools.ietf.org/html/rfc5922#section-7.2" target="_blank">https://tools.ietf.org/html/rfc5922#section-7.2</a>)</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">To be honest, I
don't understand why this restriction is good for...</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Is somebody
aware of a newer RFC that removes this limitation?</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div>
<div dir="ltr">Best regards,<br>
Leonid Fainshtein<br>
<br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Kamailio (SER) - Users Mailing List
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com/" target="_blank">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a>
Funding: <a href="https://www.paypal.me/dcmierla" target="_blank">https://www.paypal.me/dcmierla</a></pre>
</div>
_______________________________________________<br>Kamailio (SER) - Users Mailing List<br><a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br><a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br></div></blockquote></div><br></div></div></blockquote></div>