Come risolvere Firefox 59 non accetta più il mio certificato SSL autofirmato su .dev virtualhost

20

Nel mio ambiente Apache locale ho un sito che richiede SSL per lo sviluppo, quindi ho usato un certificato autofirmato. Fino ad ora il sito locale ha funzionato bene in Firefox e Chrome, ma dopo l'aggiornamento di Firefox alla versione 59 oggi non riesco ad accettare l'eccezione di sicurezza (su Chrome il certificato autofirmato continua a funzionare).

Firefox mi fornisce queste informazioni aggiuntive nella pagina bloccata:

... utilizza un certificato di sicurezza non valido. Il certificato non è attendibile perché è autofirmato. Codice errore: SEC_ERROR_UNKNOWN_ISSUER

Non esiste alcuna opzione per consentire l'eccezione qui come una volta, ma sono andato alle Preferenze di Firefox in Certificati, quindi nella scheda "Server" ho aggiunto un'eccezione per il dominio locale. Il certificato viene quindi elencato nel nome del server locale corretto, i dettagli mostrano che le mie impostazioni del certificato di Emesso da ed Emesso sono le stesse, con un periodo di validità valido.

Qualcuno ha problemi simili con FF 59 o potrebbe avere la minima idea di cosa provare a far funzionare di nuovo il certificato autofirmato localmente?

Modifica: non vedo alcuna menzione di questo nelle note di rilascio di FF 59 ma qualcosa nella nuova versione fa sì che tutti i miei host virtuali locali su domini * .dev provino automaticamente a stabilire una connessione https (vale a dire, tutti http le richieste per * .dev vengono inviate automaticamente all'URL https). Forse qualcosa su questo comportamento è anche ciò che sta causando questi problemi per i miei host virtuali https reali.

ssl ssl-certificate firefox

— kontur
fonte

1

La mia ipotesi è che ora hai bisogno di una CA per un certificato autofirmato perché Firefox ha gradualmente aumentato i requisiti nelle ultime versioni. Tuttavia, con Let's Encrypt non c'è motivo di utilizzare più i certificati autofirmati.

— Simon Greenwood,

Non voglio indovinare, ma penso che @SimonGreenwood abbia ragione. Ma di solito Firefox imposta semplicemente le nuove opzioni come predefinite e consente di modificare le impostazioni. Controlla le tue impostazioni sulla privacy.

@Broco Se non altro nelle impostazioni di sicurezza, non nelle impostazioni sulla privacy. Come detto sopra, ho anche aggiunto un'eccezione di sicurezza, ma Firefox insiste ancora sul fatto di non essere in grado di convalidare il certificato, perché ovviamente l'emittente è sconosciuto.

— 1818

@kontur per me il link riguarda: preferenze # privacy per impostare le impostazioni di privacy e sicurezza, ecco perché ho detto privacy. Valuta di pubblicarlo come un bug.

2

@SimonGreenwood Ci sono molte ragioni per non usare crittografiamo su una connessione locale. Uno non vorrebbe istituire encrpyt.

— Jon,

15

Non sono ancora del tutto chiaro su come tutto si combini esattamente, ma come sottolineato in questa risposta i .dev domini sono ora TLD ufficiali. Come tale, sembra che i browser impongano un qualche tipo di comportamento HSTS e imposti connessioni https. Per quei TLD sembra che il mio certificato autofirmato non sia più stato accettato in Firefox. La modifica dei miei host virtuali per l'uso ha .testrisolto il problema senza dover modificare nulla nei miei certificati autofirmati.

Vale la pena notare che in Firefox anche i miei host virtuali non SSL hanno funzionato dalla versione 59 di oggi, perché il comportamento HSTS sembrava forzare SSL su host virtuali che non avevo impostato come servizio tramite SSL. Su Chrome funzionava ancora, ma in entrambi i casi è sicuro dire che abbandonare il .devTLD ora ufficialmente usato risolverà molti mal di testa.

— kontur
fonte

1

Sì, .devè un TLD valido da qualche tempo, quindi NON usarlo per nominare le risorse interne. Lo stesso per qualsiasi altro nome: non usare nessun nome che pensi che nessun altro userà. Utilizzare i nomi dei test a cui si fa riferimento in RFC2606 o semplicemente registrare un vero nome di dominio ovunque e utilizzare un sottodominio simile int.example.como dev.example.comper aggiungere il suffisso a tutti i nomi interni. Non avrai mai collisioni o problemi (purché ti ricordi di rinnovare il nome di dominio ogni anno!)

— Patrick Mevzek,

2

Vedi ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts

— Patrick Mevzek

1

Grazie per il link Le linee temporali qui menzionate non si allineano, ma forse l'autore ha parlato di anteprime di sviluppo o simili. Dato quello che so ora, è davvero difficile capire perché i fornitori di browser non aggiungano ulteriori informazioni di debug, in particolare per quanto riguarda l'errore SSL sui .devdomini. A meno che tu non sappia che è un TLD, non c'è alcuna possibilità di dedurre che questo sia il problema.

— Kontur,

12

C'è un modo semplice per aggirare questo.

Vai a about:config
Cerca "network.stricttransportsecurity.preloadlist".
Impostalo su false.

ATTENZIONE: questo disabiliterà completamente HSTS . Dai un'occhiata ai commenti su questa risposta per alcune discussioni sugli aspetti negativi di questo metodo. Personalmente ritengo che il vantaggio superi il rischio, ma tu sei responsabile della tua sicurezza.

— Andy Mercer
fonte

4

Questa è una pessima idea in quanto questa impostazione si applica a tutti i siti Web visitati non solo ai tuoi. Stai abbassando la tua sicurezza.

— Patrick Mevzek,

Non sono d'accordo. HSTS è relativamente nuovo. Siamo stati bene senza di essa negli ultimi 20 anni, quindi dire che disabilitarlo è molto male per la sicurezza è esagerato. In secondo luogo, anche se è una cattiva idea, non c'è davvero alcuna altra opzione se voglio che i miei server di sviluppo continuino a funzionare, che non comportino cambiamenti molto lunghi nel mio ambiente di sviluppo.

— Andy Mercer,

1

Una soluzione come questa: security.stackexchange.com/a/154176 almeno ha un impatto su un solo sito, non tutti.

— Patrick Mevzek,

1

Per quanto condiscendente sappia che suonerà, man mano che invecchi, ti renderai conto che cose come "best practice" e "wrong" sono flessibili e cambiano nel tempo. Ciò che la gente considera "sbagliato" in questo momento, non è stato considerato sbagliato per molti anni e potrebbe non esserlo di nuovo in futuro. Per quanto riguarda questa discussione specifica, dovremo solo concordare di non essere d'accordo.

— Andy Mercer,

1

Grazie per questa correzione, funziona benissimo per me in Firefox 59.0.1 (e Firefox Dev Edition 60). I nostri .devprogetti attuali verranno infine spostati su un altro suffisso TLD, ma per ora questo non aiuta a fermare lo sviluppo locale.

— Jake Bathman,

4

Impostazione security.enterprise_roots.enabledalla truesulla about:configpagina di risolto questo per me e ha permesso il mio certificato auto-firmato per il lavoro durante lo sviluppo.

C'è un po 'di discussione sui meriti di questo essere attivo di default qui:
Impostare security.enterprise_roots.enabled su true per impostazione predefinita .

Sebbene lo scopo di questo flag sia di consentire a Firefox di utilizzare l'archivio radice della CA a livello di computer come fonte valida per le autorità di certificazione, ciò ha risolto la situazione per il mio caso d'uso in cui ho un certificato multi-dominio autofirmato che utilizzo localmente per i test (subjectAltName's) . Anche dopo aver aggiunto il certificato all'elenco dei certificati di Firefox, non è stato fino a quando non ho attivato questo che ha permesso il caricamento del sito locale.

— Sean Aitken
fonte

Grazie, ha funzionato!

— informatik01

0

Ha avuto lo stesso problema sul browser web basilisk . Ho provato a cambiare le impostazioni del proxy di rete o a modificare i flag "network.stricttransportsecurity.preloadlist" o "security.enterprise_roots.enabled" ... ma non ho risolto il pulsante mancante per aggiungere il certificato per il sito Web bloccato. Solo questo ha superato:

Vai a about:support.
Fai clic Open Directorysul tuo profilo del browser.
Chiudi completamente il browser.
Modifica il file " SiteSecurityServiceState.txt " nella directory sopra.
Trova e rimuovi l'intera riga che contiene il sito HSTS bloccato.
Salvare il file e riaprire il browser su quel sito.

— Noam Manos
fonte

-3

Sono andato per "Let's Encrypt"

https://letsencrypt.org/

Valido solo per 3 mesi alla volta, ma l'aggiornamento può essere automatizzato.

Come puoi vedere nelle osservazioni, c'è un problema. I nostri domini di sviluppo e test sono chiamati dev-www.example.com e test-www.example.com. Usiamo il certificato jolly dalla produzione.

— Gerard H. Pille
fonte

5

Facciamo crittografare fare affidamento sul server e dominio che sono disponibili al pubblico? Sto cercando opzioni per utilizzare SSL su host virtuali locali.

— 1818

Sì, non funziona per le persone che stanno sviluppando a livello locale.

— Andy Mercer,

la domanda riguarda LOCAL DEV

@Pieter è lo stesso di "sviluppo locale"? Perché è quello che facciamo.

— Gerard H. Pille,

1

@ GerardH.Pille Puoi generare crittografiamo Let's certificati solo se il server è accessibile da Internet. Per il mio sviluppo locale, questo non è il caso, quindi non è praticabile. Si prega di avvisare se c'è qualcosa che mi manca.

— Kontur,