[HTTPCLIENT-2055] Verification of certificates containing wildcard SANs fails for non-public domains

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 4.5.9, 4.5.11
• Assignee: Unassigned
• Reporter: Wolfgang Schell
• Created: 04/Mar/20 16:31
• Updated: 04/Mar/20 16:40
• Resolved: 04/Mar/20 16:40

Description

This case is very similar to HTTPCLIENT-1997:

Using a certificate containing wildcard domain names as subject alternative name (SAN) for non-public domains (i.e. something like a .mycorp TLD) fails in some versions of HttpClient:

 

The following (JUnit 4) test case demonstrates the issue:

package org.apache.http.conn.ssl;

import static org.junit.Assert.fail;
import java.util.ArrayList;
import java.util.List;
import org.apache.http.conn.util.PublicSuffixMatcher;
import org.apache.http.conn.util.PublicSuffixMatcherLoader;
import org.junit.Test;


public class CertificateTest {
    @Test
    public void testSubjectAlternativeNames_WithWildcards() throws Exception {
        List<SubjectName> subjectAlts = new ArrayList<>();
        PublicSuffixMatcher publicSuffixMatcher = PublicSuffixMatcherLoader.getDefault();

        // assume a certificate with multiple SANs, some of which might contain wildcards
        String host = "my-service-http.apps.system.mycorp";
        subjectAlts.add(SubjectName.DNS("apps.system.mycorp"));
        subjectAlts.add(SubjectName.DNS("*.apps.system.mycorp"));
        try {
            DefaultHostnameVerifier.matchDNSName(host, subjectAlts, publicSuffixMatcher);
        }
        catch (Exception e) {
            fail("verification failed: " + e.getMessage());
        }
    }
} 

 

Here is the result for various HttpClient versions:

4.5.9: fail
4.5.10: success (fix by HTTPCLIENT-1997)
4.5.11: fail (broken by HTTPCLIENT-2030)
 

With the 4.5.11 code base I'm wondering why DefaultHostnameVerifier.matchDNSName() would assume that this is a ICANN (i.e. public) domain.

Passing DomainType.UNKNOWN instead of DomainType.ICANN to matchIdentityStrict() solves this issue (but I'm not sure if that has other issue elsewhere in the code).

 A workaround is to add the private domain name mycorp to resource /mozilla/public-suffix-list.txt on the classpath (the default version of which is provided by HttpClient). This is tricky to solve, though, as one has to make sure to have the modified version in the classpath before httpclient-<version>.jar.

Note also that this workaround only works when adding the domain name in the public ICANN section which stresses the point above: why would we assume that the provided domain name is a public DNS name?

 

Issue Links

• duplicates: HTTPCLIENT-2047 Regression in default HTTP Client construction for non-public hostnames