6 Aug
2020
6 Aug
'20
3:37 p.m.
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" does not match "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" matches only
"*.example.com" but not "foo.example.com". Similarly,
".example.com" matches only ".example.com", and does not
match
"foo.example.com".
(Ref.: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
7 Aug
7 Aug
11:08 a.m.
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)
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
11:52 a.m.
Hello,
there are some user agents that are logging errors (like pjsip) for wild card certificates
or even not supporting it. But several major operators using it, so it works good with
Kamailio, of course.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Daniel-Constantin
Mierla
Sent: Friday, August 7, 2020 10:08 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; Leonid
Fainshtein <leonid.fainshtein(a)xorcom.com>
Subject: Re: [SR-Users] Using wildcard certificates for Kamailio server
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)
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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
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
12:02 p.m.
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(a)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(a)lists.kamailio.org <mailto:sr-users@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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1:14 p.m.
Mark,
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.
Anyway, I wrote a message to sipcore(a)ietf.org with a suggestion to remove
the restriction despite I am almost sure that the message will be ignored...
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...
Best regards,
Leonid Fainshtein
On Fri, Aug 7, 2020 at 12:02 PM Mark Boyce <mark(a)darkorigins.com> wrote:
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(a)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" does not match "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" matches only
"*.example.com" but not "foo.example.com". Similarly,
".example.com" matches only ".example.com", and does not
match
"foo.example.com".
(Ref.: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
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1570
days inactive
1571
days old
4 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Henning Westerholt -
Leonid Fainshtein -
Mark Boyce