Description of problem: wildcard certificates no longer works with the latest fetchmail release Oct 22 12:10:45 hostname fetchmail[2466085]: Server CommonName mismatch: * != 10.10.10.10 Version-Release number of selected component (if applicable): fetchmail-6.4.1 How reproducible: always Steps to Reproduce: 1. install wildcard certificate on secure pop/imap 2. 3. Actual results: fails to validate Expected results: was working before Additional info:
--- x509_name_match.c.old 2019-10-22 12:18:49.611117949 -0400 +++ x509_name_match.c 2019-10-22 12:19:06.392382026 -0400 @@ -20,11 +20,11 @@ /* disallow wildcards in certificates for domain literals * (10.9.8.7-like) */ if (strspn(p1+(*p1 == '*' ? 1 : 0), dom) == strlen(p1)) - wildcard_ok = 0; + wildcard_ok = 1; /* disallow wildcards for domain literals */ if (strspn(p2, dom) == strlen(p2)) - wildcard_ok = 0; + wildcard_ok = 1; /* If we decided above that wildcarding is still OK, * try a wildcard match first - providing that
This is only a quick fix : --- x509_name_match.c.old 2019-10-22 12:18:49.611117949 -0400 +++ x509_name_match.c 2019-10-22 13:45:20.304228116 -0400 @@ -17,6 +17,9 @@ if (p1[0] == '\0') return 0; + if (p1[0] == '*') + return 1; + /* disallow wildcards in certificates for domain literals * (10.9.8.7-like) */ if (strspn(p1+(*p1 == '*' ? 1 : 0), dom) == strlen(p1)) Is there a RFC or something that prevents using wildcard certificates for no domains ? In my use case, I'm using a dynamic IP address with SSL so I used a '*' certificate ... this works in previous fetchmail releases but this new version strictly forbids the use of '*' unless it's '*.domain.com' but in the case of IP addresses, this is more or dynamic IP addresses this is not usable . I wouldn't like to create a different SSL certificate each time that IP changes but if that's the proper way of doing it, perhaps a dynamic DNS entry would be better here.
--- x509_name_match.c.old 2019-10-22 12:18:49.611117949 -0400 +++ x509_name_match.c 2019-10-22 14:05:44.462396094 -0400 @@ -17,6 +17,9 @@ if (p1[0] == '\0') return 0; + if (p1[0] == '*' && strlen(p1) == 1) + return 1; + /* disallow wildcards in certificates for domain literals * (10.9.8.7-like) */ if (strspn(p1+(*p1 == '*' ? 1 : 0), dom) == strlen(p1))
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. A wildcard must not match at top level 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.
Well it's a self signed certificate for a static IP with no CNAME/FQDN ... I guess it's time to change all those self-signed certificates using wildcards for static IPs ! Thanks for the RCFs information.
David, I'd guessed as much, so if it's under your control, you can assign proper names for your LAN... or use other --ssl... options. /etc/hosts, dnsmasq and other means exist for local name mapping. You can probably (haven't tried it) also cheat and just list 10.10.10.10 as one of the subject alternative names in your self-signed certificate. Remember to distribute and install the CA root certificate as a trusted store to all clients.
Matthias, thank you very much for your comments!
I'm leaving this here as it's my unofficial and ugly patch to allow wildcard "*" certificate: --- x509_name_match.c.old 2019-10-22 12:18:49.611117949 -0400 +++ x509_name_match.c 2019-10-22 14:05:44.462396094 -0400 @@ -17,6 +17,9 @@ if (p1[0] == '\0') return 0; + if (p1[0] == '*' && strlen(p1) == 1) + return 1; + /* disallow wildcards in certificates for domain literals * (10.9.8.7-like) */ if (strspn(p1+(*p1 == '*' ? 1 : 0), dom) == strlen(p1)) I do not recommend using it and you should update your certificates to use a *.domain.com wildcard certificates instead .
I am not sure what purpose it served to repeat a patch that was in a previous comment, and that is also unfit for public consumption. At any rate, I suggest that David's patches be ignored, as the manual page documents quite a few options that permit altering if and how fetchmail checks if it's talking to the right server. Several --ssl options and aka come to mind.