[
https://issues.apache.org/jira/browse/HTTPCLIENT-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wolfgang Schell updated HTTPCLIENT-2055:
----------------------------------------
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:
{code:java}
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());
}
}
} {code}
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?
was:
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:
{code:java}
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());
}
}
} {code}
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}}.
> Verification of certificates containing wildcard SANs fails for non-public
> domains
> ----------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2055
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2055
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 4.5.9, 4.5.11
> Reporter: Wolfgang Schell
> Priority: Major
>
> 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:
> {code:java}
> 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());
> }
> }
> } {code}
>
> 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?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
