Uploaded image for project: 'HttpComponents HttpClient'
  1. HttpComponents HttpClient
  2. HTTPCLIENT-2055

Verification of certificates containing wildcard SANs fails for non-public domains

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: 4.5.9, 4.5.11
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      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?

       

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                jetztgradnet Wolfgang Schell
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: