Re: wildcard certificates no longer works with the latest fetchmail release => works as intended.

Matthias Andree <[email protected]> Fri, 25 Oct 2019 18:41:48 +0200
Newsgroups	gmane.mail.fetchmail.user
Message-ID	<[email protected]>
Am 23.10.19 um 11:31 schrieb Vitezslav Crhonek:
> Hello Matthias,
>
> It's been discovered that wildcard certificates don't work
> with fetchmail-6.4.1. I wasn't able to find out when the change
> happened and whether it is intentional. Please look at [1] for
> more detailed info.
>
> Best regards,
> Vitezslav Crhonek
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1764291

Hi Vitezslav,

that report assumes that a dotted-quad notation of an IP address could
be matched by a top-level catch-all wildcard, "*", which is invalid.

I've commented on the bug and recommend to close report as either "works
as intended" or "invalid" or similar depending on your policies and
conventions.
My comment included for reference below.

Cheers,
Matthias

/This is intended behaviour and not a bug. The change was made between
v6.3.17 and v6.3.18 (Git commit 480b13c7 alias RELEASE_6-3-18~55) and is
documented:/

> /+# SECURITY IMPROVEMENTS TO DEFANG X.509 CERTIFICATE ABUSE//
> //+* Fetchmail now only accepts wildcard certificate common names and
> subject//
> //+  alternative names if they start with "*.". Previous versions
> would accept//
> //+  wildcards even if no period followed immediately.//
> //+* Fetchmail now disallows wildcards in certificates to match domain
> literals//
> //+  (such as 10.9.8.7), or wildcards in domain literals
> ("*.168.23.23").//
> //+  The test is overly picky and triggers if the pattern (after
> skipping the//
> //+  initial wildcard "*") or domain consist solely of digits and dots
> and matches//
> //+  more than needed.//
> //+//
> /

/This brings the TLS/X.509v3 certificate checks in line with RFC-5280
and more specifically RFC-7817 (A. Melnikov, Isode Ltd, "Updated
Transport Layer Security (TLS) Server Identity Check Procedure for
Email-Related Protocols" section 3, item #5 on page 4 and protects
against abusive/invalid certificates as in this case, and no CA is
permitted to sign such a certificate in the first place. //
/

 1. /A wildcard must not match at top level/
 2. /A domain literal such as 10.9.8.7 is not a DNS or domain name that 
    a text subject alternative name or subject common name wildcard
    could ever match.//
    /



>
>
> _______________________________________________
> Fetchmail-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

_______________________________________________
Fetchmail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-users
signature.asc (application/pgp-signature, 833 B)