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


20

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

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

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

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

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


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


1
Я предполагаю, что теперь вам нужен CA для самозаверяющего сертификата, потому что Firefox постепенно ужесточал требования в течение последних нескольких выпусков. Однако в Let's Encrypt больше нет причин использовать самозаверяющие сертификаты.
Саймон Гринвуд

Я не хочу догадываться, но я думаю, что @SimonGreenwood прав. Но обычно Firefox просто устанавливает новые параметры по умолчанию и позволяет редактировать настройки. Проверьте настройки конфиденциальности.

@ Broco Во всяком случае это в настройках безопасности, а не в настройках конфиденциальности. Как указано выше, я даже добавил исключение безопасности, но Firefox по-прежнему настаивает на невозможности проверки сертификата, потому что, очевидно, эмитент неизвестен.
kontur

@kontur для меня ссылка о: предпочтения # конфиденциальность, чтобы установить как конфиденциальность, так и настройки безопасности, поэтому я сказал приватность. Попробуйте опубликовать это как ошибку.

2
@SimonGreenwood Есть много причин, чтобы не использовать шифрование на локальном соединении. Один не хотел бы настраивать давайте encrpyt.
Джон

Ответы:


15

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

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


1
Да, .devэто действительный домен верхнего уровня, так что НЕ используйте его для обозначения своих внутренних ресурсов. То же самое для любого другого имени: не используйте имя, которое, по вашему мнению, больше не будет использовать никто. Либо используйте тестовые имена, указанные в RFC2606, либо просто зарегистрируйте истинное доменное имя в любом месте и используйте субдомен, подобный int.example.comили dev.example.comсуффикс всех ваших внутренних имен. Тогда у вас никогда не возникнет коллизий или проблем (если вы помните о необходимости продления доменного имени каждый год!)
Патрик Мевзек,


1
Спасибо за ссылку. Указанные сроки не совсем совпадают, но, возможно, автор говорил о предварительных версиях разработки или тому подобном. Учитывая то, что я знаю сейчас, очень трудно понять, почему производители браузеров не добавили бы дополнительную информацию об отладке, в частности, в отношении ошибки SSL в .devдоменах. Если вы не знаете, что это TLD, вы не сможете сделать вывод, что это проблема.
kontur

12

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

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

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

введите описание изображения здесь


4
Это очень плохая идея, поскольку этот параметр будет применяться ко всем веб-сайтам, которые вы посещаете, а не только к своим собственным. Вы понижаете свою безопасность.
Патрик Мевзек

Я не согласен. HSTS является относительно новым. За последние 20 лет у нас все было в порядке, поэтому говорить о том, что его отключение очень вредно для безопасности, преувеличено. Во-вторых, даже если это плохая идея, на самом деле нет другого варианта, если я хочу, чтобы мои серверы разработки продолжали работать, которые не влекут за собой действительно длительных изменений в моей среде разработки.
Энди Мерсер

1
Такое решение: security.stackexchange.com/a/154176 как минимум влияет на один сайт, а не на все.
Патрик Мевзек

1
Насколько снисходительно, насколько я знаю, это будет звучать, когда вы станете старше, вы поймете, что такие вещи, как «лучшая практика» и «неправильный», являются гибкими и со временем меняются. То, что люди считают «неправильным» сейчас, не считалось неправильным в течение многих лет и, возможно, не повторится в будущем. Что касается этого конкретного обсуждения, мы просто должны согласиться не согласиться.
Энди Мерсер

1
Спасибо за это исправление, прекрасно работает в Firefox 59.0.1 (и Firefox Dev Edition 60). Наши текущие .devпроекты в конечном итоге будут перенесены в другой суффикс TLD, но пока это помогает не остановить местное развитие.
Джейк Батман

4

Установка security.enterprise_roots.enabledдля trueна about:configстранице решить это для меня и позволило моей самостоятельно подписанный сертификат на работу в процессе разработки.

Здесь обсуждаются некоторые достоинства этой возможности по умолчанию:
установите для security.enterprise_roots.enabled значение true по умолчанию .

Хотя этот флаг предназначен для того, чтобы позволить Firefox использовать корневое хранилище ЦС в масштабе всей машины в качестве допустимого источника для центров сертификации, это исправило ситуацию для моего собственного случая использования, когда у меня есть самозаверяющий многодоменный сертификат, который я использую локально для тестирования (subjectAltName's) . Даже после того, как я добавил сертификат в список сертификатов Firefox, до тех пор, пока я не включил его, он разрешил загрузку локального сайта.


Спасибо, это сработало!
informatik01

0

Была такая же проблема в веб-браузере василиска . Я пытался изменить настройки сетевого прокси или изменить флаги «network.stricttransportsecurity.preloadlist» или «security.enterprise_roots.enabled» ... но не удалось найти отсутствующую кнопку для добавления сертификата для заблокированного веб-сайта. Только это сделало это:

  1. Перейти к about:support.
  2. Нажмите Open Directoryна ваш профиль браузера.
  3. Закройте браузер полностью.
  4. Отредактируйте файл " SiteSecurityServiceState.txt " в указанном выше каталоге.
  5. Найдите и удалите всю строку, содержащую заблокированный сайт HSTS.
  6. Сохраните файл и снова откройте браузер на этом сайте.

-3

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

https://letsencrypt.org/

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

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


5
Разве давайте не зашифруем, полагаемся, что сервер и домен общедоступны? Я ищу варианты использования SSL на локальных виртуальных хостах.
kontur

Да, это не работает для людей, которые занимаются местным развитием.
Энди Мерсер

вопрос про LOCAL DEV

@ Питер это то же самое, что "местное развитие"? Потому что это то, что мы делаем.
Джерард Х. Пилле

1
@ GerardH.Pille Вы можете генерировать сертификаты Let's шифровать, только если сервер доступен из Интернета. Для моего местного развития это не так, поэтому это не жизнеспособно. Посоветуйте, пожалуйста, если что-то мне не хватает.
Контур
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.