Condividi tramite

Certificati digitali e SSL

  • Articolo

Si applica a: Exchange Server 2013

Secure Sockets Layer (SSL) è un metodo per proteggere le comunicazioni tra un client e un server. Per Exchange Server 2013, ssl viene usato per proteggere le comunicazioni tra il server e i client. I client consistono nei telefoni cellulari e nei computer interni o esterni alla rete di un'organizzazione.

Per impostazione predefinita, quando si installa Exchange 2013, le comunicazioni client vengono crittografate tramite SSL quando si usano Outlook Web App, Exchange ActiveSync e Outlook Via Internet.

SSL richiede l'uso di certificati digitali. Questo argomento riepiloga i diversi tipi di certificati digitali e le informazioni su come configurare Exchange 2013 per l'uso di questi tipi di certificati digitali.

Panoramica dei certificati digitali

I certificati digitali sono file elettronici che funzionano come password in linea in grado di verificare l'identità di un utente o di un computer. Vengono usati per creare il canale crittografato SSL usato per le comunicazioni client. Un certificato è un'istruzione digitale rilasciata da un'autorità di certificazione (CA) che verifica l'identità del titolare del certificato e consente alle parti di comunicare in modo sicuro usando la crittografia.

I certificati digitali ese guano le operazioni seguenti:

  • Autenticano che i loro titolari (persone, siti Web e persino risorse di rete come i router) sono veramente chi o cosa dichiarano di essere.

  • Proteggono i dati scambiati online da furti o manomissioni.

I certificati digitali possono essere rilasciati da un'autorità di certificazione di terze parti attendibile o da un'infrastruttura a chiave pubblica (PKI) di Windows tramite Servizi certificati oppure possono essere autofirmati. Ogni tipo di certificato presenta vantaggi e svantaggi. Ogni tipo di certificato digitale è a prova di manomissione e non può essere contraffatto.

I certificati possono essere rilasciati per diversi usi. Questi usi includono l'autenticazione utente Web, l'autenticazione del server Web, S/MIME (Secure/Multipurpose Internet Mail Extensions), Internet Protocol security (IPsec), Transport Layer Security (TLS) e la firma del codice.

Un certificato contiene una chiave pubblica e la associa all'identità della persona, del computer o del servizio che possiede la chiave privata corrispondente. Le chiavi pubbliche e private vengono usate dal client e dal server per crittografare i dati prima che vengano trasmessi. Per utenti, computer e servizi basati su Windows, viene stabilita l'attendibilità in una CA quando è presente una copia del certificato radice nell'archivio certificati radice attendibile e il certificato contiene un percorso di certificazione valido. Affinché il certificato sia valido, il certificato non deve essere stato revocato e il periodo di validità non deve essere scaduto.

Tipi di certificati

Esistono tre tipi principali di certificati digitali: certificati autofirmati, certificati generati da PKI Windows e certificati di terze parti.

Certificati autofirmati

Quando si installa Exchange 2013, viene configurato automaticamente un certificato autofirma nei server Cassette postali. Un certificato autofirmo viene firmato dall'applicazione che l'ha creato. L'oggetto e il nome del certificato corrispondono. L'autorità di certificazione e l'oggetto sono definiti nel certificato. Questo certificato autofirma viene usato per crittografare le comunicazioni tra il server Accesso client e il server Cassette postali. Il server Accesso client considera automaticamente attendibile il certificato autofirmati nel server Cassette postali, quindi non è necessario alcun certificato di terze parti nel server Cassette postali. Quando si installa Exchange 2013, viene creato anche un certificato autofirma nel server Accesso client. Questo certificato autofirmato consentirà ad alcuni protocolli client di usare SSL per le comunicazioni. Exchange ActiveSync e Outlook Web App sono in grado di stabilire una connessione SSL tramite un certificato autofirmato. Outlook Via Internet non funziona con un certificato autofirma nel server Accesso client. I certificati autofirmati devono essere copiati manualmente nell'archivio certificati radice attendibile nel computer client o nel dispositivo mobile. Quando un client si connette a un server tramite SSL e il server presenta un certificato autofirmata, al client verrà richiesto di verificare che il certificato sia stato emesso da un'autorità attendibile. Il client deve considerare esplicitamente attendibile l'autorità emittente. Se il client conferma l'attendibilità, le comunicazioni SSL possono continuare.

Nota

Per impostazione predefinita, il certificato digitale installato nel server o nei server Cassette postali è un certificato autofirmato. Non è necessario sostituire il certificato autofirma nei server Cassette postali dell'organizzazione con un certificato di terze parti attendibile. Il server Accesso client considera automaticamente attendibile il certificato autofirmati nel server Cassette postali e non sono necessarie altre configurazioni per i certificati nel server Cassette postali.

Spesso le organizzazioni di piccole dimensioni decidono di non usare un certificato di terze parti o di non installare la propria infrastruttura a chiave pubblica per rilasciare i propri certificati. Questa decisione potrebbe essere presa perché tali soluzioni sono troppo costose, perché gli amministratori non dispongono dell'esperienza e delle conoscenze necessarie per creare la propria gerarchia di certificati o per entrambi i motivi. Il costo è minimo e la configurazione è semplice quando si usano certificati autofirmati. Tuttavia, è molto più difficile stabilire un'infrastruttura per la gestione del ciclo di vita dei certificati, il rinnovo, la gestione dell'attendibilità e la revoca quando si usano certificati autofirmati.

Certificati dell'infrastruttura a chiave pubblica di Windows

Il secondo tipo di certificato è un certificato generato da PKI di Windows. Un'infrastruttura a chiave pubblica è un sistema di certificati digitali, autorità di certificazione e autorità di registrazione che verificano e autenticano la validità di ogni parte coinvolta in una transazione elettronica usando la crittografia a chiave pubblica. Quando si implementa un'infrastruttura PKI in un'organizzazione che usa Active Directory, si fornisce un'infrastruttura per la gestione del ciclo di vita dei certificati, il rinnovo, la gestione dell'attendibilità e la revoca. Tuttavia, la distribuzione di server e infrastruttura per la creazione e la gestione dei certificati generati da PKI di Windows comporta alcuni costi aggiuntivi.

I servizi certificati sono necessari per distribuire un'infrastruttura a chiave pubblica di Windows e possono essere installati tramite Installazione applicazioni in Pannello di controllo. È possibile installare Servizi certificati su qualsiasi server nel dominio.

Se si ottengono certificati da una CA Windows aggiunta al dominio, è possibile usare la CA per richiedere o firmare i certificati da rilasciare ai propri server o computer nella rete. Ciò consente di utilizzare una PKI, simile all'utilizzo di un fornitore di certificati di terze parti ma meno costosa. Questi certificati PKI non possono essere distribuiti pubblicamente, come possono essere altri tipi di certificati. Tuttavia, quando una CA PKI firma il certificato del richiedente usando la chiave privata, il richiedente viene verificato. La chiave pubblica di questa CA è parte del certificato. Un server che ha questo certificato nell'archivio certificati radice attendibili può utilizzare la chiave pubblica per decrittografare il certificato del richiedente e autenticarlo.

I passaggi per la distribuzione di un certificato generato da PKI sono simili a quelli necessari per la distribuzione di un certificato autofirma. È comunque necessario installare una copia del certificato radice attendibile dall'infrastruttura a chiave pubblica all'archivio certificati radice attendibile dei computer o dei dispositivi mobili che si vuole essere in grado di stabilire una connessione SSL a Microsoft Exchange.

Un'infrastruttura a chiave pubblica windows consente alle organizzazioni di pubblicare i propri certificati. I client possono richiedere e ricevere certificati da un'infrastruttura a chiave pubblica di Windows nella rete interna. L'infrastruttura a chiave pubblica di Windows può rinnovare o revocare i certificati.

Certificati di terze parti attendibili

I certificati di terze parti o commerciali sono certificati generati da una CA commerciale o di terze parti e quindi acquistati per l'uso nei server di rete. Un problema con i certificati autofirmati e basati su PKI è che, poiché il certificato non è automaticamente attendibile dal computer client o dal dispositivo mobile, è necessario assicurarsi di importare il certificato nell'archivio certificati radice attendibile nei computer client e nei dispositivi. I certificati di terze parti o commerciali non presentano questo problema. La maggior parte dei certificati CA commerciali sono già attendibili perché il certificato si trova già nell'archivio certificati radice attendibili. Poiché l'autorità di certificazione è attendibile, anche il certificato è attendibile. L'uso di certificati di terze parti semplifica notevolmente la distribuzione.

Per le organizzazioni di grandi dimensioni o le organizzazioni che devono distribuire pubblicamente i certificati, la soluzione migliore consiste nell'usare un certificato di terze parti o commerciale, anche se esiste un costo associato al certificato. I certificati commerciali potrebbero non essere la soluzione migliore per le organizzazioni di piccole e medie dimensioni e si potrebbe decidere di usare una delle altre opzioni di certificato disponibili.

Scelta di un tipo di certificato

Quando si sceglie il tipo di certificato da installare, è necessario considerare diversi aspetti. Un certificato deve essere firmato per essere valido. Può essere autofirma o firmata da un'autorità di certificazione. Un certificato autofirma presenta limitazioni. Ad esempio, non tutti i dispositivi mobili consentono a un utente di installare un certificato digitale nell'archivio certificati radice attendibile. La possibilità di installare i certificati in un dispositivo mobile dipende dal produttore del dispositivo mobile e dal provider di servizi mobili. Alcuni produttori e provider di servizi mobili disabilitano l'accesso all'archivio certificati radice attendibile. In questo caso, né un certificato autofirmato né un certificato da una CA PKI Windows possono essere installati nel dispositivo mobile.

Certificati di Exchange predefiniti

Per impostazione predefinita, Exchange installa un certificato autofirmato sia nel server Accesso client che nel server Cassette postali in modo che tutte le comunicazioni di rete siano crittografate. Per crittografare tutte le comunicazioni di rete è necessario che ogni server Exchange disponga di un certificato X.509 che può usare. È consigliabile sostituire questo certificato autofirmati nel server Accesso client con uno che sia automaticamente considerato attendibile dai client.

"Autofirmata" significa che un certificato è stato creato e firmato solo dal server Exchange stesso. Poiché non è stato creato e firmato da una CA generalmente attendibile, il certificato autofirma predefinito non verrà considerato attendibile da alcun software, ad eccezione di altri server Exchange nella stessa organizzazione. Il certificato predefinito è abilitato per tutti i servizi di Exchange. Ha un nome alternativo soggetto (SAN) che corrisponde al nome del server di Exchange in cui è installato. Include anche un elenco di NOMI SAN che includono sia il nome del server che il nome di dominio completo (FQDN) del server.

Anche se altri server Exchange nell'organizzazione di Exchange considerano attendibile questo certificato automaticamente, i client come Web browser, client Outlook, telefoni cellulari e altri client di posta elettronica oltre ai server di posta elettronica esterni non lo considerano automaticamente attendibile. È pertanto consigliabile sostituire questo certificato con un certificato di terze parti attendibile nei server Accesso client di Exchange. Se si dispone di un'infrastruttura PKI interna personalizzata e tutti i client considerano attendibile tale entità, è anche possibile usare i certificati rilasciati manualmente.

Requisiti dei certificati per servizio

I certificati vengono usati per diversi elementi in Exchange. La maggior parte dei clienti usa anche i certificati in più di un server Exchange. In generale, minore è il numero di certificati disponibili, più semplice diventa la gestione dei certificati.

IIS

Tutti i servizi exchange seguenti usano lo stesso certificato in un determinato server Accesso client di Exchange:

  • Outlook Web App

  • Centro amministrativo di Exchange (EAC)

  • Servizi Web Exchange

  • Exchange ActiveSync

  • Outlook via Internet

  • Individuazione automatica

  • Distribuzione della Rubrica di Outlook

Poiché un solo certificato può essere associato a un sito Web e poiché tutti questi servizi sono offerti in un singolo sito Web per impostazione predefinita, tutti i nomi usati dai client di questi servizi devono essere inclusi nel certificato o essere inclusi in un nome jolly nel certificato.

POP/IMAP

I certificati usati per POP o IMAP possono essere specificati separatamente dal certificato usato per IIS. Tuttavia, per semplificare l'amministrazione, è consigliabile includere il nome del servizio POP o IMAP nel certificato IIS e usare un singolo certificato per tutti questi servizi.

SMTP

È possibile usare un certificato separato per ogni connettore di ricezione configurato. Il certificato deve includere il nome usato dai client SMTP (o da altri server SMTP) per raggiungere tale connettore. Per semplificare la gestione dei certificati, è consigliabile includere tutti i nomi per i quali è necessario supportare il traffico TLS in un singolo certificato.

Certificati digitali e proxy

Il proxy è il metodo con cui un server invia connessioni client a un altro server. Nel caso di Exchange 2013, ciò si verifica quando il server Accesso client esegue il proxy di una richiesta client in ingresso al server Cassette postali che contiene la copia attiva della cassetta postale del client.

Quando i server accesso client inviano richieste proxy, SSL viene usato per la crittografia, ma non per l'autenticazione. Il certificato autofirmati nel server Cassette postali crittografa il traffico tra il server Accesso client e il server Cassette postali.

Proxy e certificati inversi

Molte distribuzioni di Exchange usano proxy inversi per pubblicare i servizi exchange su Internet. I proxy inversi possono essere configurati per terminare la crittografia SSL, esaminare il traffico in chiaro nel server e quindi aprire un nuovo canale di crittografia SSL dai server proxy inversi ai server Exchange sottostanti. Questa operazione è nota come bridging SSL. Un altro modo per configurare i server proxy inversi consiste nel consentire alle connessioni SSL di passare direttamente ai server Exchange dietro i server proxy inversi. Con entrambi i modelli di distribuzione, i client su Internet si connettono al server proxy inverso usando un nome host per l'accesso a Exchange, ad esempio mail.contoso.com. Il server proxy inverso si connette quindi a Exchange usando un nome host diverso, ad esempio il nome del computer del server Accesso client di Exchange. Non è necessario includere il nome del computer del server Accesso client di Exchange nel certificato perché i server proxy inversi più comuni sono in grado di corrispondere al nome host originale usato dal client al nome host interno del server Accesso client di Exchange.

SSL e dns diviso

Split DNS è una tecnologia che consente di configurare indirizzi IP diversi per lo stesso nome host, a seconda della provenienza della richiesta DNS di origine. È anche noto come "split-horizon DNS", "split-view DNS" o "split-brain DNS". DNS diviso consente di ridurre il numero di nomi host che è necessario gestire per Exchange consentendo ai client di connettersi a Exchange tramite lo stesso nome host sia da Internet che dalla rete intranet. Split DNS consente alle richieste provenienti dalla Intranet di ricevere un indirizzo IP diverso rispetto alle richieste provenienti da Internet.

Il DNS diviso in genere non è necessario in una distribuzione di Exchange di piccole dimensioni perché gli utenti possono accedere allo stesso endpoint DNS, sia che provengano dalla Intranet o da Internet. Tuttavia, con distribuzioni di dimensioni maggiori, questa configurazione comporta un carico troppo elevato sul server proxy Internet in uscita e sul server proxy inverso. Per le distribuzioni di dimensioni maggiori, configurare dns diviso in modo che, ad esempio, gli utenti esterni accengano a mail.contoso.com e gli utenti interni accinga a internal.contoso.com. L'uso del DNS diviso per questa configurazione garantisce che gli utenti non dovranno ricordare di usare nomi host diversi a seconda della posizione in cui si trovano.

Windows PowerShell remoto

L'autenticazione Kerberos e la crittografia Kerberos vengono usate per l'accesso remoto Windows PowerShell, sia dall'interfaccia di amministrazione di Exchange che da Exchange Management Shell. Pertanto, non sarà necessario configurare i certificati SSL per l'uso con Windows PowerShell remoti.

Procedure consigliate per i certificati digitali

Sebbene la configurazione dei certificati digitali dell'organizzazione varia in base alle esigenze specifiche, sono state illustrate procedure consigliate per consentire di scegliere la configurazione dei certificati digitali migliore.

Procedura consigliata: Usare un certificato di terze parti attendibile

Per impedire ai client di ricevere errori relativi ai certificati non attendibili, il certificato usato dal server Exchange deve essere emesso da un utente attendibile del client. Anche se la maggior parte dei client può essere configurata per considerare attendibile qualsiasi certificato o autorità di certificazione, è più semplice usare un certificato di terze parti attendibile nel server Exchange. Questo perché la maggior parte dei client considera già attendibili i certificati radice. Esistono diversi emittenti di certificati di terze parti che offrono certificati configurati in modo specifico per Exchange. È possibile usare EAC per generare richieste di certificato che funzionano con la maggior parte degli emittenti di certificati.

Come selezionare un'autorità di certificazione

Un'autorità di certificazione (CA) è una società che rilascia e garantisce la validità dei certificati. Il software client (ad esempio, browser come Microsoft Internet Explorer o sistemi operativi come Windows o Mac OS) include un elenco predefinito di CA attendibili. Questo elenco può in genere essere configurato per aggiungere e rimuovere CA, ma tale configurazione è spesso complessa. Quando si seleziona una CA da cui acquistare i certificati, usare i criteri seguenti:

  • Verificare che la CA sia attendibile dal software client (sistemi operativi, browser e telefoni cellulari) che si connetterà ai server Exchange.

  • Scegliere un'autorità di certificazione che supporti i "certificati di comunicazione unificata" per l'uso con il server Exchange.

  • Assicurarsi che la CA supporti i tipi di certificati che verranno usati. Prendere in considerazione l'uso di certificati SAN (Subject Alternative Name). Non tutte le autorità di certificazione supportano i certificati SAN e altre CA non supportano tutti i nomi host necessari.

  • Assicurarsi che la licenza acquistata per i certificati consenta di inserire il certificato nel numero di server che si intende usare. Alcune CA consentono di inserire un certificato in un solo server.

  • Confrontare i prezzi dei certificati tra ca.

Procedura consigliata: Usare i certificati SAN

A seconda di come si configurano i nomi di servizio nella distribuzione di Exchange, il server Exchange potrebbe richiedere un certificato in grado di rappresentare più nomi di dominio. Anche se un certificato con caratteri jolly, ad esempio uno per *.contoso.com, può risolvere questo problema, molti clienti non sono a proprio agio con le implicazioni di sicurezza della gestione di un certificato che può essere usato per qualsiasi sottodominio. Un'alternativa più sicura consiste nell'elencare ognuno dei domini necessari come SAN nel certificato. Per impostazione predefinita, questo approccio viene usato quando le richieste di certificato vengono generate da Exchange.

Procedura consigliata: Usare la procedura guidata per i certificati di Exchange per richiedere i certificati

In Exchange sono disponibili molti servizi che usano i certificati. Un errore comune durante la richiesta di certificati consiste nell'effettuare la richiesta senza includere il set corretto di nomi di servizio. La procedura guidata del certificato nell'interfaccia di amministrazione di Exchange consente di includere l'elenco corretto di nomi nella richiesta di certificato. La procedura guidata consente di specificare i servizi con cui il certificato deve funzionare e, in base ai servizi selezionati, include i nomi che è necessario avere nel certificato in modo che possa essere usato con tali servizi. Eseguire la procedura guidata per il certificato quando è stato distribuito il set iniziale di server Exchange 2013 e sono stati determinati i nomi host da usare per i diversi servizi per la distribuzione. Idealmente, sarà necessario eseguire la procedura guidata del certificato una sola volta per ogni sito di Active Directory in cui si distribuisce Exchange.

Invece di preoccuparsi di dimenticare un nome host nell'elenco SAN del certificato acquistato, è possibile usare un'autorità di certificazione che offre, senza addebiti, un periodo di tolleranza durante il quale è possibile restituire un certificato e richiedere lo stesso nuovo certificato con alcuni nomi host aggiuntivi.

Procedura consigliata: Usare il minor numero possibile di nomi host

Oltre a usare il minor numero possibile di certificati, è necessario usare anche il minor numero possibile di nomi host. Questa pratica può risparmiare denaro. Molti provider di certificati addebitano una tariffa in base al numero di nomi host aggiunti al certificato.

Il passaggio più importante che è possibile eseguire per ridurre il numero di nomi host necessari e, di conseguenza, la complessità della gestione dei certificati, consiste nel non includere nomi host di singoli server nei nomi alternativi soggetto del certificato.

I nomi host che è necessario includere nei certificati di Exchange sono i nomi host usati dalle applicazioni client per connettersi a Exchange. Di seguito è riportato un elenco di nomi host tipici necessari per una società denominata Contoso:

  • Mail.contoso.com: questo nome host copre la maggior parte delle connessioni a Exchange, tra cui Microsoft Outlook, Outlook Web App, Outlook Via Internet, Rubrica offline, Servizi Web Exchange, POP3, IMAP4, SMTP, Exchange Pannello di controllo e ActiveSync.

  • Autodiscover.contoso.com: questo nome host viene usato dai client che supportano l'individuazione automatica, tra cui Microsoft Office Outlook 2007 e versioni successive, Exchange ActiveSync e client di Servizi Web Exchange.

  • Legacy.contoso.com: questo nome host è necessario in uno scenario di coesistenza con Exchange 2007 ed Exchange 2013. Se sono presenti client con cassette postali in Exchange 2007 ed Exchange 2013, la configurazione di un nome host legacy impedisce agli utenti di dover apprendere un secondo URL durante il processo di aggiornamento.

Informazioni sui certificati con caratteri jolly

Un certificato con caratteri jolly è progettato per supportare un dominio e più sottodomini. Ad esempio, la configurazione di un certificato con caratteri jolly per *.contoso.com comporta un certificato che funzionerà per mail.contoso.com, web.contoso.com e autodiscover.contoso.com.