Maven 3.0.5 отказывается наш обновленный сертификат нексус

Question

При запуске Maven 3.0.5 наш (недавно поменяны местами, Apache прокси размещенного) HTTPS сертификата для Nexus отвергается с ошибкой:

hostname in certificate didn't match: <new.domain.com> != <*.old.domain.com> OR ..

Это не происходит с (например, 3.0.3), и я заметил, что исправление для 3.0.5 похоже на мою проблему: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0253

Я просмотрел сертификат через Chrome и т. д., и это кажется прекрасным. Запуск maven в debug (-X) не дает мне больше информации.

(Я знаю, что это пограничная подкладка к вопросу Apache/Nexus). Также - это SSL-сертификат подстановки, используемый несколькими другими службами, также проксированный тем же экземпляром Apache.

Любые идеи?

Answer 1

Ok. Задача решена.

После прочтения на Apache HTTPS и виртуальных хостов вместе с курсом краха в HTTP-прокси я получил его.

Проще говоря: Apache не может поддерживать несколько виртуальных хостов с различными сертификатами SSL. Это связано с тем, что Host -header, используемый для запроса прокси-сервера, зашифрован, поэтому мы находимся в ситуации с курицей или яйцом.

У нас был настроен Apache так, как мы хотели перенаправить из нашего старого домена в новый. В этой ситуации Apache просто использует сертификат, настроенный для первого виртуального хоста: https://wiki.apache.org/httpd/NameBasedSSLVHosts

Так почему же Chrome получил правильный сертификат? Хорошо - похоже, что Chrome (и Apache) поддерживает расширение TLS, которое отправляет имя хоста, не зашифрованное в Client Hello (например, первое сообщение SSL). Следовательно, Apache знает, какой виртуальный хост (например, сертификат) отправляет обратно.

Проблема решена.

Теперь мы создадим новые доменные имена виртуальных хостов 1-го, а наши старые перенаправляем последним. Это позволит клиентам с расширением TLS работать на 100%, тем временем это позволит другим клиентам работать в нашем новом домене.