Il 1 ° novembre sta arrivando - Il tuo server Exchange è pronto?

1 novembre 2015: nuove regole entrano in vigore

I tuoi amici su SSL.com vorrebbero farti sapere questo inizio Novembre 1st, 2015, alcuni cambiamenti molto importanti riguardo a ciò che può essere coperto Certificati SSL stanno entrando in vigore:

• I nuovi certificati contenenti nomi interni non verranno più emessi da alcuna autorità di certificazione seguendo le linee guida CA / Browser Forum (vale a dire, tutti quelli rispettabili)
  
  Tieni presente che da qualche tempo SSL.com non rilascia certificati intranet a nomi interni con date di scadenza oltre il 1 ° novembre 2015 e quindi i clienti di SSL.com non dovrebbero riscontrare problemi immediati, tuttavia, ti consigliamo vivamente di ricontrollare i tuoi certificati per i potenziali modi in cui queste decisioni potrebbero avere un impatto su di te.
• I certificati esistenti contenenti nomi interni non verranno nuovamente emessi dopo il 1 ° novembre 2015.
  
  Ancora una volta, SSL.com ha lavorato per assicurarti che non avrai problemi a causa di ciò, tuttavia, di seguito abbiamo presentato uno scenario peggiore per la tua modifica.
• I certificati esistenti contenenti nomi interni verranno REVOCATI AUTOMATICAMENTE il 1 ° novembre 2016.
  
  Questa è una politica generale, poiché alcune architetture di sicurezza potrebbero avere certificati legacy già esistenti che non rispettano queste regole.

Questi cambiamenti significano che la posta elettronica, il primo e ancora più utile strumento di Internet, può essere influenzata negativamente dalle modifiche, in particolare se si utilizza Exchange Server di Microsoft (che la ricerca di mercato suggerisce è il 63% di tutti voi). Pertanto, la tua architettura di sicurezza potrebbe iniziare ad essere influenzata a partire dal prossimo giorno di Ognissanti.

Sei pronto?

Cosa intendi quando dici "nomi interni"?

La definizione più semplice di un nome interno è qualsiasi identificatore di rete che sia parte di una rete privata ed non raggiungibile utilizzando un nome che utilizza un dominio di primo livello (TLD) o un indirizzo IP univoco. Di conseguenza, qualsiasi ID di rete registrato pubblicamente presso un'autorità centrale come l'ICAAN sarà utilizzabile nei certificati

Nei giorni precedenti e più semplici di Internet un'architettura DNS interna doveva solo preoccuparsi di evitare un insieme limitato di TLD, quindi la intranet di AwfulBigCo.com poteva supportare non solo ABC.nyc ed ABC.londra ma 1600.pennsylvania.ave, mail ed Gandalf. Per di più, alcuni intervalli di indirizzi IPv4 e IPv6 vengono messi da parte per un utilizzo puramente locale: questi intervalli riservati includono "192.168. *. *" per il routing e 10. *. *. * per le reti locali. Proteggere intranet con certificati SSL è ovviamente una buona idea e, fino alla nuova sentenza, qualsiasi amministratore di rete potrebbe richiedere e ricevere un certificato che include uno di questi.

Dal 1 novembre 2015 non sarà più così - non verranno più emessi certificati - o, soprattutto, rilasciato RE - che contengono nomi interni. Queste nuove regole sono progettate sia per migliorare la sicurezza sia per consentire un uso corretto dei nuovi nomi di dominio di primo livello (ad esempio, sia .london che .nyc sono ora TLD pubblici). Tuttavia, richiedono a qualsiasi utente di Exchange di esaminare attentamente la propria configurazione di rete e di sicurezza e apportare modifiche per riconoscere queste nuove regole. Poiché molti progetti di sicurezza di Exchange hanno storicamente utilizzato nomi interni, ciò potrebbe causare seri problemi con il servizio di posta quando e quando i certificati scadono, poiché non è possibile emettere nuovi certificati con nomi interni per sostituire quelli esistenti, peggio ancora, qualsiasi certificato multidominio contenente anche un solo nome interno fallirà al rinnovo, esponendo potenzialmente il tuo traffico di posta a exploit dannosi.

In caso contrario, si potrebbe avere un impatto negativo sul traffico di posta, sulla propria attività e / o sulla propria reputazione.

Sembra dire.

Potrebbe benissimo essere - dipende davvero da quanto sei preparato. Questo potrebbe essere un problema molto facile da perdere e le conseguenze potrebbero essere assolutamente fatali per la tua attività - if non riesci ad agire in anticipo.

Vedi, il fornitore di certificati di AwfulBigCo ha eseguito la richiesta oltre i propri robot, ha rilevato quei nomi interni e (secondo le regole del forum CA / B) ha rifiutato il rinnovo.

Questo è un problema. L'UCC NON sarà rinnovato e non solo i servizi che utilizzano i nomi interni con diallow (cioè tutta la posta aziendale ei backup FTP) non saranno più protetti, né gli ALTRI domini inclusi nell'UCC, come il primario e .co. domini uk per AwfulBigCo.

Certo, questo è uno scenario estremamente peggiore, ma crediamo davvero che la piena sicurezza dipenda dalla preparazione esattamente per questo.

Ok, sono legittimo spaventato: cosa devo fare ora?

Se stai usando nomi interni nei tuoi certificati SSL, dovrai prendere misure per risolvere questo problema, e prima è meglio è.

Fondamentalmente, ci sono alcune opzioni che puoi scegliere:

1. Riconfigurare il sistema per utilizzare solo nomi di dominio registrati pubblicamente.
   Questa è probabilmente la soluzione migliore: rende discutibile il problema del nome interno e sarà più semplice da mantenere ed estendere in futuro. Sfortunatamente, questa opzione richiederà probabilmente un lavoro considerevole in anticipo, ma è possibile configurare i server Microsoft Exchange per utilizzare nomi di dominio pubblico completi (e questo CA / Browser Forum white paper fornisce ulteriori informazioni sull'implementazione di FQDN nelle reti Active Directory). L'amministrazione dopo il passaggio sarà quasi certamente più semplice o più semplice di prima (un grande vantaggio per Bob) e in futuro AwfulBigCo sarà in grado di utilizzare certificati pubblicamente attendibili per proteggere tutto il traffico sia internamente che esternamente. Un possibile svantaggio di questo metodo è che può consentire la scoperta di informazioni sull'infrastruttura interna di un'azienda tramite DNS, ma una configurazione intelligente delle zone DNS può aiutare a risolvere questo problema, ad esempio utilizzando sottodomini come nomi di dominio "interni" o separati e limitando la risoluzione di questi al di fuori delle reti aziendali.
2. Registra i nomi interni come FQDN.
   Sfortunatamente, non è un'opzione per quell'indirizzo IP riservato e "Mail" e "Gandalf" ovviamente sono disponibili. (Per amore della sanità mentale di Bob presumiamo che i domini .com e .co.uk siano già registrati in modo sicuro: la sua giornata è già abbastanza dura.)
   Inoltre, anche se abc.scambio è disponibile - e ricorda che .exchange è uno dei nuovi TLD la cui introduzione sta contribuendo a guidare questo cambio di regola - potrebbe essere utilizzato e disponibile solo per un prezzo esorbitante - sono probabilmente disponibili alternative più facili ed economiche.
3. Configurare una CA Enterprise
   Questo è un metodo già utilizzato da entità veramente grandi che hanno bisogno di proteggere principalmente le comunicazioni interne. Una CA aziendale funge da autorità di certificazione aziendale: in sostanza, invece della catena di fiducia che corre fino a una CA esterna, tutti i certificati sono in definitiva protetti da un certificato radice generato internamente, mentre ciò offre una maggiore personalizzazione (e consentirebbe a Bob di mantenere la struttura di denominazione legacy che AwfulBigCo ha in atto) ci sono seri problemi di sicurezza da considerare: un hack in stile Sony potrebbe esporre il certificato radice aziendale e / o la chiave privata, consentendo uno sfruttamento quasi illimitato della rete. Inoltre, i certificati rilasciati internamente NON saranno considerati attendibili altrove: questo è un metodo che protegge le comunicazioni interne ma non può estendere la fiducia oltre le mura della rete aziendale. Infine, la creazione di una CA aziendale non è affatto una soluzione immediata e potrebbe essere molto più difficile delle altre opzioni elencate qui, e quindi praticabile solo per reti molto grandi (o in crescita).
   
   SSL.com è lieto di offrire servizi di consulenza e gestione per aiutarti a negoziare il percorso per la creazione della tua CA aziendale: invia un messaggio a enterpriseca@ssl.com e uno dei nostri amministratori senior ti contatterà presto.
4. Usa certificati autofirmati
   Questa opzione presenta svantaggi simili a quella della CA aziendale, ma non si adatta bene: poiché ogni certificato autofirmato non ha una catena di fiducia al di fuori di se stesso, ogni singolo certificato dovrebbe essere installato su ogni client per evitare messaggi di errore . La gestione su un'ampia rete creerebbe anche una nuova serie di grattacapi per il povero Bob: qualcosa di semplice come gli aggiornamenti automatici del browser potrebbe causare il caos a meno che non venga mantenuta una vigilanza costante su ogni dispositivo.

Come sempre, CONTATTACI su SSL.com in caso di domande. Ricorda: un Internet più sicuro è un Internet migliore.