[
https://issues.apache.org/jira/browse/HTTPCLIENT-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-2055.
-------------------------------------------
Resolution: Duplicate
> 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]
