Condividi tramite

Modifiche alla verifica del certificato del server TLS del browser Microsoft Edge

  • Articolo

Nota

Microsoft Edge for Business è ora disponibile nella versione stabile di Edge 116. Altre informazioni sulla nuova esperienza lavorativa dedicata con sicurezza, produttività, gestibilità e intelligenza artificiale di livello aziendale nativo integrate.

Quando Microsoft Edge stabilisce connessioni a un server HTTPS, Edge verifica che il server abbia presentato un certificato emesso da un'entità attendibile dal browser. Questa relazione di trust viene stabilita tramite un elenco di attendibilità del certificato e il componente responsabile dell'esecuzione dei controlli viene chiamato verificatore del certificato.

Nelle versioni precedenti di Microsoft Edge, sia l'elenco di attendibilità del certificato predefinito che la logica di verifica del certificato sono stati forniti dalla piattaforma del sistema operativo sottostante.

Per i dispositivi gestiti, a partire da Microsoft Edge 112 in Windows e macOS, sia l'elenco di attendibilità dei certificati predefinito che il verificatore di certificati vengono forniti da e forniti con il browser. Questo approccio separa l'elenco e il verificatore dall'archivio radice del sistema operativo host per il comportamento di verifica predefinito. Per altre informazioni sulla tempistica della modifica, vedere la sequenza temporale di implementazione e le linee guida per i test.

Anche dopo la modifica, oltre a considerare attendibili le radici predefinite fornite con Microsoft Edge, il browser esegue una query sulla piattaforma sottostante per le radici installate in locale e/o per le aziende installate in locale. Di conseguenza, gli scenari in cui un utente o un'organizzazione ha installato più radici nell'archivio radice del sistema operativo host devono continuare a funzionare.

Questa modifica significa che la logica di verifica del certificato funziona in modo coerente in Microsoft Edge in Windows e macOS. In una versione futura da determinare, l'implementazione si applicherà anche a Linux e Android. A causa dei criteri di Apple App Store, l'archivio radice e il verificatore di certificati forniti da Apple continuano a essere usati in iOS e iPadOS.

Origine elenco di attendibilità del certificato predefinito

L'archivio radice fornito con Microsoft Edge in Windows e macOS proviene dall'elenco di attendibilità dei certificati (CTL) definito dal programma Microsoft Trusted Root Certificate Program. Questo programma di certificati radice definisce l'elenco fornito con Microsoft Windows. Di conseguenza, i clienti dovrebbero aspettarsi di non visualizzare modifiche visibili all'utente.

In macOS, se un certificato emesso da un certificato radice considerato attendibile dalla piattaforma ma non dal programma certificato radice attendibile di Microsoft, il certificato non è più attendibile. Questa mancanza di attendibilità non è prevista come una situazione comune, poiché la maggior parte dei server garantisce già che i certificati TLS usati siano considerati attendibili da Microsoft Windows.

Gli aggiornamenti vengono rilasciati in base alla frequenza documentata nelle note sulla versione per il programma Radice attendibile Microsoft.

Linee guida per la sequenza temporale di implementazione e i test

A partire da Microsoft Edge 109, sono disponibili un criterio aziendale (MicrosoftRootStoreEnabled) e un flag in edge://flags ("Microsoft Root Store") per controllare quando vengono usati l'archivio radice predefinito e il verificatore di certificati.

I dispositivi che non sono gestiti dall'azienda hanno iniziato a ricevere la funzionalità tramite un'implementazione delle funzionalità controllata (CFR) in Microsoft Edge 109 e hanno raggiunto il 100% dei dispositivi non gestiti in Edge 111. Per altre informazioni, vedere Configurazioni e sperimentazione di Microsoft Edge, che spiega come funzionano i CFR in Microsoft Edge. Per i dispositivi gestiti dall'organizzazione, l'implementazione fornita dalla piattaforma esistente è stata usata tramite Microsoft Edge 111.

A partire da Microsoft Edge 112, l'impostazione predefinita è stata modificata per tutti i dispositivi Windows e macOS, inclusi quelli gestiti dall'organizzazione, per usare l'implementazione del verificatore e l'elenco CTL fornito con il browser. I criteri MicrosoftRootStoreEnabled continuano a essere disponibili in questa versione per consentire alle aziende di ripristinare il comportamento precedente in caso di problemi imprevisti e segnalare i problemi a Microsoft.

Microsoft consiglia alle aziende che dispongono di proxy di break-and-inspect o di altri scenari che coinvolgono certificati server TLS emessi da radici non presenti in Microsoft CTL di identificare e segnalare in modo proattivo eventuali problemi di compatibilità a Microsoft.

In Microsoft Edge 115 il supporto per i criteri MicrosoftRootStoreEnabled viene rimosso.

Differenze note del comportamento dei certificati attendibili in locale in Windows

Conformità RFC 5280 più restrittiva

Il nuovo verificatore di certificati predefinito è più rigoroso nell'applicazione dei requisiti RFC 5280 rispetto al vecchio verificatore basato su piattaforma.

Esempi di conformità RFC 5280 più rigorosa includono:

  1. I parametri dell'algoritmo per gli algoritmi ECDSA devono essere assenti. Il verificatore precedente ignora i parametri mentre il nuovo rifiuta il certificato. Per altre informazioni, vedere Problema di Chromium 1453441 per altri dettagli.
  2. I vincoli di nome che specificano un indirizzo IP devono contenere otto ottetti per gli indirizzi IPv4 e 32 ottetti per gli indirizzi IPv6. Se il certificato specifica un indirizzo IP vuoto, è necessario rilasciare nuovamente il certificato e omettere completamente il vincolo del nome dell'indirizzo IP.
  3. I vincoli di nome con un elenco "escluso" vuoto non sono validi. Il visualizzatore di certificati di Windows mostra questo elenco come Excluded=None all'interno dei Name Constraints dettagli. Per altre informazioni, vedere Problema di Chromium 1457348 per altri dettagli. Anziché specificare un elenco vuoto, ometterlo completamente.

Differenze note del comportamento di controllo delle revoche in Windows

Oltre ai requisiti RFC 5280 più rigorosi, il nuovo verificatore non supporta gli URI CRL (Certificate Revocation List) basati su LDAP.

Se l'organizzazione abilita il criterio RequireOnlineRevocationChecksForLocalAnchors e i CRL non sono validi per RFC 5280, l'ambiente potrebbe iniziare a visualizzare ERR_CERT_NO_REVOCATION_MECHANISM e/o ERR_CERT_UNABLE_TO_CHECK_REVOCATION errori.

Se si verifica ERR_CERT_NO_REVOCATION_MECHANISM, è necessario verificare che il CRL in corrispondenza dell'URI specificato dal certificato restituisca una risposta con codifica DER (non con codifica PEM).

Vedere anche