Как исправить Firefox 59, больше не принимающий мой самозаверяющий сертификат SSL на виртуальном хосте .dev

10044
kontur

В моей локальной среде Apache у меня есть сайт, для разработки которого требуется SSL, поэтому я использую самозаверяющий сертификат. До сих пор локальный сайт хорошо работал в Firefox и Chrome, но после обновления Firefox до версии 59 сегодня я не могу заставить его принять исключение безопасности (в Chrome самоподписанный сертификат продолжает работать).

Firefox дает мне эту дополнительную информацию на заблокированной странице:

... использует недействительный сертификат безопасности. Сертификат не является доверенным, потому что он самоподписан. Код ошибки: SEC_ERROR_UNKNOWN_ISSUER

Здесь нет возможности разрешить исключение, как раньше, но я перешел к настройкам Firefox в разделе «Сертификаты», затем на вкладке «Сервер» я добавил исключение для локального домена. Затем сертификат будет указан в правильном имени локального сервера, в деталях указаны параметры моего сертификата, выданные и выданные одинаковыми с допустимым периодом времени.

Кто-нибудь испытывает подобные проблемы с FF 59 или может иметь представление, что попытаться заставить самозаверяющий сертификат снова работать локально?

Редактировать: я не вижу упоминаний об этом в примечаниях к выпуску FF 59, но что-то в новой версии заставляет все мои локальные виртуальные хосты на доменах * .dev автоматически пытаться установить соединение https (то есть все http запросы на * .dev автоматически отправляются на https URL). Возможно, что-то в этом поведении также является причиной этих проблем для моих реальных виртуальных хостов https.

10
Я предполагаю, что теперь вам нужен CA для самозаверяющего сертификата, потому что Firefox постепенно ужесточал требования в течение последних нескольких выпусков. Однако в Let's Encrypt больше нет причин использовать самозаверяющие сертификаты. Simon Greenwood 6 лет назад 0
Я не хочу догадываться, но я думаю, что @SimonGreenwood прав. Но обычно Firefox просто устанавливает новые параметры по умолчанию и позволяет редактировать настройки. Проверьте настройки конфиденциальности. 6 лет назад 0
@ Broco Во всяком случае это в настройках безопасности, а не в настройках конфиденциальности. Как указано выше, я даже добавил исключение безопасности, но Firefox по-прежнему настаивает на невозможности проверки сертификата, потому что, очевидно, эмитент неизвестен. kontur 6 лет назад 0
@kontur для меня ссылка о: предпочтения # конфиденциальность, чтобы установить как конфиденциальность, так и настройки безопасности, поэтому я сказал приватность. Подумайте о том, чтобы опубликовать это как ошибку. 6 лет назад 0
`.dev` (несколько) новый рДВУ, принадлежащий Google. Смотрите мой другой комментарий ниже и https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/ Patrick Mevzek 6 лет назад 0

3 ответа на вопрос

9
kontur

Я до сих пор не совсем понимаю, как все это точно совмещается, но, как указано в этом ответе, .dev домены теперь являются официальными TLD. Таким образом, кажется, что браузеры вызывают некоторое поведение HSTS и устанавливают соединения https. Похоже, что для этих TLD мой самозаверяющий сертификат больше не был принят в Firefox. Изменение виртуальных хостов для использования .testрешило проблему без необходимости что-либо менять в моих самозаверяющих сертификатах.

Стоит отметить, что в Firefox мои виртуальные хосты, не поддерживающие SSL, также работали с сегодняшней версии 59, потому что поведение HSTS, по-видимому, заставляло SSL работать на виртуальных хостах, которые я не настроил для обслуживания через SSL. В Chrome это все еще работало, но в любом случае можно с уверенностью сказать, что отказ от теперь официально используемого .devдомена верхнего уровня разрешит многие головные боли.

Да, `.dev` является действительным TLD, так как некоторое время ** НЕ ** использует его для именования ваших внутренних ресурсов. То же самое для любого другого имени: не используйте имя, которое, по вашему мнению, больше не будет использовать никто. Либо используйте тестовые имена, указанные в RFC2606, либо просто зарегистрируйте истинное доменное имя в любом месте и используйте поддомен, такой как `int.example.com` или` dev.example.com`, чтобы суффиксировать все ваши внутренние имена. Тогда у вас никогда не возникнет коллизий или проблем (если вы помните о необходимости продления доменного имени каждый год!) Patrick Mevzek 6 лет назад 1
Смотрите https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/ Patrick Mevzek 6 лет назад 2
Спасибо за ссылку. Указанные сроки не совсем совпадают, но, возможно, автор говорил о предварительных версиях разработки и т.п. Учитывая то, что я знаю сейчас, действительно трудно понять, почему производители браузеров не добавили бы дополнительную информацию об отладке, в частности, в отношении ошибки SSL на доменах `.dev`. Если вы не знаете, что это TLD, вы не сможете сделать вывод, что это проблема. kontur 6 лет назад 1
8
Andy Mercer

Существует простой способ обойти это.

  1. Идти к about:config
  2. Поиск "network.stricttransportsecurity.preloadlist".
  3. Установите это false.

ВНИМАНИЕ: Это полностью отключит HSTS . Взгляните на комментарии к этому ответу, чтобы обсудить недостатки этого метода. Я лично думаю, что выгода перевешивает риск, но вы несете ответственность за свою безопасность.

enter image description here

Это очень плохая идея, поскольку этот параметр будет применяться ко всем веб-сайтам, которые вы посещаете, а не только к своим собственным. Вы понижаете свою безопасность. Patrick Mevzek 6 лет назад 1
Я не согласен. HSTS является относительно новым. За последние 20 лет у нас все было в порядке, поэтому говорить о том, что его отключение очень вредно для безопасности, преувеличено. Во-вторых, даже если это плохая идея, на самом деле нет другого варианта, если я хочу, чтобы мои серверы разработки продолжали работать, которые не влекут за собой действительно длительных изменений в моей среде разработки. Andy Mercer 6 лет назад 0
Таким образом, с тем же рассуждением мы не должны использовать что-то, изобретенное за последние 20 лет? Это просто фиктивный аргумент. RFC на HSTS - 6 лет назад. Вы намеренно отключаете меры безопасности, что никогда не является хорошей идеей. Ошибка заключается в использовании неправильных имен, вы должны вместо этого вкладывать энергию в решение этой проблемы, поскольку она является реальной. В противном случае он снова укусит вас, а отключение настроек безопасности откроет вас для других атак. Patrick Mevzek 6 лет назад 0
Во-первых, ничто из того, что я сказал, не означает, что мы не должны использовать вещи, изобретенные за последние 20 лет. Во-вторых, `.dev` для локальной среды не является" неправильным именем ". Это была типичная практика в течение долгого времени. Лишь недавно `.dev` был добавлен в качестве TLD. Я не собираюсь менять свои настройки, потому что ICANN решила пойти на захват денег. Andy Mercer 6 лет назад 0
Подобное решение: https://security.stackexchange.com/a/154176 влияет как минимум на один сайт, а не на все. Patrick Mevzek 6 лет назад 0
`.dev` - неправильное имя, это не то, что нужно обсуждать, а просто факт. Вы не должны просто придумывать имя и надеяться, что столкновения не будет. Они случатся. Так что плохой выбор с самого начала, извините. Типичный выбор не делает его хорошим выбором по умолчанию. А если вы против, тогда просто поддерживайте локальный авторизованный сервер для `.dev`. В любом случае, это опять-таки неправильное решение, но, очевидно, я перестану здесь спорить, так как это бесполезно, поскольку вы не понимаете основную проблему, которая у вас есть. Patrick Mevzek 6 лет назад 0
«У нас все было хорошо без него в течение последних 20 лет», так как HSTS собирается включить HTTPS по умолчанию для защиты от понижения и перехвата файлов cookie, вы просто говорите, что у вас все в порядке без HTTPS, следовательно, TLS с прошлых 20 лет. Мне страшно слышать это от разработчика. Тем не мение... Patrick Mevzek 6 лет назад 0
Насколько снисходительно, насколько я знаю, это будет звучать, когда вы станете старше, вы поймете, что такие вещи, как «лучшая практика» и «неправильный», являются гибкими и со временем меняются. То, что люди считают «неправильным» прямо сейчас, не считалось неправильным в течение многих лет и, возможно, не повторится в будущем. Что касается этого конкретного обсуждения, мы просто должны согласиться не согласиться. Andy Mercer 6 лет назад 0
Столкновение - это столкновение - это столкновение. Вчера, сегодня и завтра. Непонимание того, что DNS является глобальным, и, следовательно, вы не должны просто взломать имя, которое, по вашему мнению, никто не будет использовать, является фатальным недостатком. Интересный ярлык, возможно, поначалу думает, что он начинает быстрее, но, очевидно, он кусает вас на более позднем этапе, как вы только что обнаружили. Итак, насколько это может показаться снисходительным: в следующий раз в своей профессиональной карьере старайтесь избегать явных столкновений. Это будет хорошо для вас и для Интернета во всем мире. Patrick Mevzek 6 лет назад 0
Я думаю, что @AndyMercer не одинок в использовании .dev для локальной разработки. Я просто откатил свой FF до версии 58, потому что я просто не могу сейчас поменять все свои локальные сайты разработчиков. George 6 лет назад 0
@Pieter тот факт, что определенное количество людей делает ошибку, не превращает автоматически в хорошую практику ... `.dev` существует уже много лет, в какой-то момент люди должны начать замечать: это только с изменениями на HSTS, что люди пострадали. К сожалению, такой плохой выбор действительно был сделан. К тому же это также показывает, что во всех примерах в строке и постах здесь следует обязательно использовать имена, на которые ссылаются в RFC2606, поскольку они гарантированно не вызовут коллизий в будущем. ** Любое ** другое имя может столкнуться в будущем, ICANN ** откроет новые рДВУ ... Patrick Mevzek 6 лет назад 0
@PatrickMevzek> все примеры в строке и постах здесь должны обязательно использовать имена, на которые ссылаются в RFC2606, поскольку они гарантированно не создадут коллизии в будущем. Это не оставляет много места для игры с .test, .example, .invalid и .localhost. Думаю, нам нужно проявить больше творчества и сделать что-то вроде .localdev, которое ** может ** открыть ICANN, но надеюсь, что это будет в далеком будущем :) George 6 лет назад 0
@Pieter, пожалуйста, прочитайте мой комментарий выше: зарегистрируйте любое доменное имя в любом TLD, который вы пожелаете, и тогда у вас есть пожизненный (или на срок, за который вы его платите) способ сделать любое внутреннее наименование по вашему желанию, потому что у вас есть ** обеспечил ** имя, зарегистрировав его глобально, вместо того, чтобы просто выбрать его произвольно и надеяться, что никто другой не сделает то же самое ... Имена в RFC никогда не будут открыты ICANN. Patrick Mevzek 6 лет назад 0
Спасибо за это исправление, прекрасно работает в Firefox 59.0.1 (и Firefox Dev Edition 60). Наши текущие проекты `.dev` будут в конечном итоге перенесены в другой суффикс TLD, но пока это помогает не остановить локальное развитие. Jake Bathman 6 лет назад 1
Спасибо за ответ. Это может сработать, но негативные последствия этого решения, кажется, перевешивают позитивные. kontur 6 лет назад 0
Нет, не может об этом. Это работает. Что касается проблем безопасности, это зависит от вашего рабочего процесса и ситуации, поэтому я и говорю, чтобы прочитать эти комментарии. Andy Mercer 6 лет назад 0
-2
Gerard H. Pille

Я пошел на «Давайте шифровать»

https://letsencrypt.org/

Действителен только в течение 3 месяцев, но обновление может быть автоматизировано.

Как видно из замечаний, здесь есть одна загвоздка. Наши области разработки и тестирования называются dev-www.example.com и test-www.example.com. Мы используем подстановочный сертификат с производства.

Разве давайте не зашифруем, полагаемся, что сервер и домен общедоступны? Я ищу варианты использования SSL на локальных виртуальных хостах. kontur 6 лет назад 2
Да, это не работает для людей, которые занимаются местным развитием. Andy Mercer 6 лет назад 0
вопрос про МЕСТНОЕ РАЗВИТИЕ George 6 лет назад 0
@ Питер это то же самое, что "местное развитие"? Потому что это то, что мы делаем. Gerard H. Pille 6 лет назад 0
@ GerardH.Pille да, конечно. Скажите пожалуйста. George 6 лет назад 0
@ GerardH.Pille Вы можете генерировать сертификаты Let's шифровать, только если сервер доступен из Интернета. Для моего местного развития это не так, поэтому это не жизнеспособно. Пожалуйста, сообщите, если что-то мне не хватает. kontur 6 лет назад 0
Это возможно? https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html Используйте рабочий URL-адрес с префиксом, таким как «test-», «dev-». Gerard H. Pille 6 лет назад 0

Похожие вопросы