Utilizzo dei certificati in Exchange 2007 Server

 

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2008-05-19

In Microsoft Exchange Server 2007 i certificati vengono utilizzati per proteggere numerosi percorsi di comunicazione della posta elettronica. Il presente argomento è inteso come introduzione end-to-end all'utilizzo dei certificati in Exchange 2007. Verranno trattati i seguenti temi:

• Come vengono utilizzati i certificati in Exchange 2007.

• Come determinare quando è opportuno acquistare un certificato rilasciato da un'autorità di certificazione di terze parti pubblica (CA) e quando, invece, è sufficiente usare il certificato predefinito autofirmato.

• Come gli attributi dei certificati vengono utilizzati dai componenti di Exchange 2007 e la relazione tra le proprietà dei certificati e i campi di estensione dei certificati X.509.

• Attendibilità e convalida dei certificati.

• Come creare, importare e abilitare certificati in Exchange 2007.

• Come i componenti di Exchange selezionano i certificati dall'archivio certificati Personale nel computer.

Ciascuna sezione di questo argomento contiene riferimenti e collegamenti alla documentazione relativa ai certificati per Exchange 2007.

Ringraziamenti   La maggior parte di questo contenuto è stata adattata da note interne di Microsoft e dalla documentazione raccolta e messa a disposizione da Stuart Presley, Support Engineer.

Sommario

• Componenti di Exchange 2007 che utilizzano certificati per la crittografia e l'autenticazione di sessioni

• Come determinare quando è necessario utilizzare certificati emessi da CA pubbliche e quando è necessario utilizzare certificati autofirmati

• Concetti relativi agli attributi dei certificati e modalità di utilizzo dei certificati da parte di Exchange 2007

• Attendibilità e convalida dei certificati

• Creazione, importazione e abilitazione di certificati

• Selezione di un certificato

• Ulteriori informazioni

Componenti di Exchange 2007 che utilizzano certificati per la crittografia e l'autenticazione di sessioni

In Exchange 2007 vengono utilizzati certificati X.509 per negoziare canali di trasporto di comunicazioni Transport Layer Security (TLS) e Secure Sockets Layer (SSL) per protocolli quali HTTPS, SMTP, POP e IMAP.

TLS è il protocollo standard di Internet Engineering Task Force (IETF) che assicura la riservatezza e la protezione delle comunicazioni tra due applicazioni attraverso una rete. Tale protocollo consente di crittografare le comunicazioni e consente ai client di autenticare i server oppure, facoltativamente, ai server di autenticare i client. TLS è una versione più sicura del protocollo SSL sul quale si basa lo stesso TLS. SSL è stato precedentemente sviluppato da Netscape. Entrambi i protocolli offrono funzionalità equivalenti e la maggior parte delle implementazioni supporta entrambi i protocolli per assicurare la compatibilità con client di versioni precedenti che supportano soltanto SSL.

Le comunicazioni protette tramite TLS possono essere utilizzate per garantire la riservatezza (crittografia) oppure per sia garantire la riservatezza sia consentire l'autenticazione. I certificati X.509 possono essere autofirmati (ovvero "autoemessi") oppure emessi da un'autorità di certificazione X.509, che può essere un'autorità di certificazione pubblica di terze parti che emette certificati oppure un'infrastruttura a chiave pubblica (PKI, Public Key Infrastructure) distribuita all'interno dell'organizzazione. Salvo diversa indicazione, in questo argomento il termine "autorità di certificazione" (CA, Certification Authority) viene utilizzato per fare riferimento a entrambe le soluzioni. Le CA pubbliche di terze parti sono note semplicemente come CA pubbliche.

I seguenti componenti di Exchange 2007 utilizzano certificati per crittografare o autenticare sessioni:

• SMTP   Vengono utilizzati certificati per la crittografia e l'autenticazione al fine di garantire la protezione dei domini tra organizzazioni partner. I certificati vengono utilizzati per le connessioni con trust diretto tra i server Trasporto Hub e quelli Trasporto Edge. I certificati vengono utilizzati tra server Trasporto Hub per crittografare la sessione SMTP. In Exchange Server 2007, per trust diretto si intende la funzionalità di autenticazione in base alla quale la presenza del certificato nel servizio directory di Active Directory o di Active Directory Application Mode (ADAM) convalida il certificato. Active Directory è considerata un meccanismo di archiviazione attendibile. I certificati vengono utilizzati anche per sessioni TLS opportunistiche tra organizzazioni. Per ulteriori informazioni, vedere Funzionalità TLS e relativa terminologia in Exchange 2007.

• Sincronizzazione EdgeSync   Viene utilizzato un certificato autofirmato, creato da Exchange 2007, per crittografare la sessione di comunicazione LDAP tra l'istanza ADAM sui server Trasporto Edge e i server Active Directory interni, dopo che il servizio Microsoft Exchange EdgeSync ha replicato i dati da Active Directory all'istanza ADAM sul server Trasporto Edge. Un certificato autofirmato viene firmato dal suo stesso autore. Il servizio Microsoft Exchange EdgeSync è il servizio di sincronizzazione dati che replica periodicamente i dati di configurazione da Active Directory a un server Trasporto Edge sottoscritto. Per ulteriori informazioni, vedere Concetti relativi al processo di sincronizzazione EdgeSync.

• POP3 e IMAP4   Vengono utilizzati certificati per autenticare e crittografare la sessione tra i client Post Office Protocol versione 3 (POP3) e Internet Message Access Protocol versione 4rev1 (IMAP4) e i server Exchange. Per ulteriori informazioni, vedere Gestione della protezione POP3 e IMAP4.

• Messaggistica unificata   Vengono utilizzati certificati per crittografare la sessione SMTP con i server Trasporto Hub e il gateway IP di Messaggistica unificata e Microsoft Office Communications Server 2007. Per ulteriori informazioni, vedere Concetti relativi alla protezione VoIP per la messaggistica unificata.

• Individuazione automatica   Vengono utilizzati certificati per crittografare il percorso HTTP tra il client e il server Accesso client. Per ulteriori informazioni, vedere il White PaperServizio di individuazione automatica di Exchange 2007 (informazioni in lingua inglese).

• Applicazioni Accesso client   Vengono utilizzati certificati per crittografare il percorso tra il server Accesso client e vari client HTTP, ad esempio Outlook via Internet, Microsoft Outlook Web Access e i dispositivi che supportano Microsoft Exchange ActiveSync. Per ulteriori informazioni, vedere Gestione della protezione dell'accesso client.

Per ulteriori informazioni su come viene crittografato e autenticato ciascun percorso dati in Exchange 2007, vedere Riferimenti per la protezione dei percorsi dei dati.

Inizio pagina

Come determinare quando è necessario utilizzare certificati emessi da CA pubbliche e quando è necessario utilizzare certificati autofirmati

Lo scopo di questa sezione è di fornire una spiegazione rapida di come vengono utilizzati i certificati in Exchange 2007. Dopo aver letto questa sezione si dovrebbe disporre di un'idea chiara, in base ai componenti di Exchange abilitati e ai client che si intende supportare, del tipo di certificato che è necessario acquistare da una CA pubblica. In questa sezione viene fornito inoltre il contesto generale per il contenuto più tecnico che verrà presentato più avanti.

È importante tenere presente che questa sezione è necessariamente breve in quanto concepita per consentire agli utenti di determinare con rapidità le proprie esigenze complessive per quanto riguarda i certificati in relazione alle CA pubbliche. Allo scopo di fornire informazioni concise sull'uso di tali certificati in Exchange 2007, sono state fatte molte generalizzazioni relative ai certificati e alle tecnologie correlate. Se le nozioni di base illustrate in questa sezione non risultano chiaramente comprensibili, si consiglia di leggere il resto dell'argomento e la documentazione alla quale viene fatto riferimento.

In genere, qualsiasi componente di Exchange 2007 che utilizza l'autenticazione di tipo Kerberos, trust diretto o NTLM può utilizzare per la crittografia un certificato autofirmato. In questo argomento viene fatto riferimento a tali componenti come "componenti interni" di Exchange 2007. Interno si riferisce al fatto che i percorsi dati sono limitati ai server Exchange 2007 e all'interno della rete aziendale definita da Active Directory.

Si consiglia di distribuire un certificato emesso da una CA pubblica ogniqualvolta gli utenti della rete accedono a componenti di Exchange che richiedono l'autenticazione e la crittografia da una sede esterna al firewall aziendale. Ad esempio, tutti i client supportati dal ruolo del server Accesso client, quali Exchange ActiveSync, POP3, IMAP4 e Outlook via Internet, dovrebbero essere protetti da un certificato emesso da una CA pubblica. In questo argomento viene fatto riferimento a tali componenti come "componenti esterni" di Exchange 2007. Esterno si riferisce al fatto che i percorsi dati tra i client e i server Exchange 2007 attraversano il firewall aziendale e si estendono a Internet.

I componenti interni utilizzano certificati autofirmati

Come è stato menzionato in precedenza, numerosi componenti di Exchange 2007 fanno uso di certificati. In genere, tutti i percorsi dati Exchange interni che sono protetti da certificati non richiedono un certificato emesso da una CA pubblica.

L'intero traffico SMTP e di messaggistica unificata interno è protetto da certificati autofirmati che vengono installati nel corso della procedura di installazione di Exchange 2007 Server. Questi certificati devono essere rinnovati annualmente utilizzando il cmdlet New-ExchangeCertificate. Tuttavia, per eseguire i componenti di messaggistica interni di Exchange non è indispensabile disporre di un certificato emesso da una CA pubblica.

Exchange 2007 comprende un insieme di cmdlet che consentono di creare, richiedere e gestire i certificati TLS. Per ulteriori informazioni su questi cmdlet, vedere Cmdlet dei certificati più avanti in questo argomento. Per impostazione predefinita, tali certificati sono autofirmati. Come è stato spiegato in precedenza, un certificato autofirmato è firmato dal suo stesso autore. In Exchange 2007 il certificato autofirmato viene creato dal computer su cui è in esecuzione Microsoft Exchange, utilizzando l'API del certificato (CAPI) sottostante di Windows. I certificati autofirmati in genere sono meno attendibili rispetto a quelli generati da una CA. Si consiglia, pertanto, di utilizzare i certificati autofirmati solo per i seguenti scenari interni:

• Sessioni SMTP tra i server Trasporto Hub: viene utilizzato un certificato soltanto per la crittografia della sessione SMTP. L'autenticazione viene fornita dal protocollo Kerberos.

• Le sessioni SMTP tra i server Trasporto Hub e un server Trasporto Edge: viene utilizzato un certificato per la crittografia della sessione SMTP e per l'autenticazione di trust diretto.

• Sincronizzazione EdgeSync tra i server Trasporto Edge e Active Directory: viene utilizzato un certificato per crittografare la sessione di comunicazione LDAP tra l'istanza ADAM sui server Trasporto Edge e i server Active Directory interni, dopo che il servizio Microsoft Exchange EdgeSync ha replicato i dati da Active Directory all'istanza ADAM sul server Trasporto Edge.

• Comunicazioni di messaggistica unificata: viene utilizzato un certificato per la crittografia del traffico Session Initiation Protocol (SIP) e Realtime Transport Protocol (RTP) tra i server Messaggistica unificata e i gateway IP di messaggistica unificata o centralini IP e i computer che eseguono Office Communications Server 2007. Il certificato viene utilizzato anche per crittografare il traffico SMTP quando vengono inviati messaggi vocali o fax dai server Messaggistica unificata ai server Trasporto Hub.

• Un server Accesso client al quale accedono soltanto i client interni.

L'accesso client a Exchange effettuato dall'esterno richiede certificati emessi da una CA pubblica

I componenti Exchange interni possono fare affidamento su certificati autofirmati perché tali certificati non vengono utilizzati per l'autenticazione. L'autenticazione per la maggioranza dei componenti di Exchange viene fornita dai protocolli Kerberos o NTLM. Nelle comunicazioni tra un server Trasporto Edge e un server Trasporto Hub viene utilizzata l'autenticazione di trust diretto. Tale forma di autenticazione è garantita da un lato da un certificato e dall'altro dalla chiave pubblica del server Trasporto Edge archiviata in Active Directory, che è un archivio attendibile. Peraltro, i certificati autofirmati vengono utilizzati per fornire una chiave temporanea per crittografare i percorsi tra i componenti di Exchange.

Tuttavia, per l'accesso di client esterni da Internet alla rete in cui è ospitato Exchange, è richiesta una convalida di attendibilità mediante certificati di tipo tradizionale. È consigliabile, in questi casi, utilizzare un certificato emesso da una CA per la convalida dell'attendibilità. In effetti, quando è richiesta l'autenticazione mediante certificato, l'utilizzo di un certificato autofirmato è sconsigliato. L'utilizzo di un certificato emesso da una CA pubblica è consigliato nei seguenti casi:

• Accesso client POP3 e IMAP4 a Exchange

• Outlook Web Access

• Outlook via Internet

• Exchange ActiveSync

• Individuazione automatica

• Protezione del dominio

In tutti questi casi si consiglia di utilizzare una CA pubblica che è considerata attendibile per impostazione predefinita da parte di tutti i client.

Utilizzare il cmdlet New-ExchangeCertificate per generare una richiesta di certificato in base alle specifiche della CA pubblica di terze parti che emetterà il certificato.

Per ulteriori informazioni, vedere i seguenti argomenti:

• New-ExchangeCertificate

• Creazione di un certificato o di una richiesta di certificato per TLS

• Lezioni di Exchange 2007 - generazione di un certificato con una CA di terze parti

  Nota

  Il contenuto dei Wiki, dei blog e dei relativi URL è soggetto a modifica senza preavviso.

Il resto di questa sezione fornisce informazioni su come determinare i tipi di certificati pubblici che è necessario acquistare e se occorre acquistare più certificati per garantire la protezione dei client utilizzati dalla propria organizzazione per l'accesso a Exchange 2007.

Determinazione del tipo e del numero di certificati emessi da CA pubbliche per la distribuzione nella propria organizzazione

La selezione del certificato appropriato emesso da una CA pubblica per la propria organizzazione dipende dai seguenti fattori:

• Supporto client dei nomi contenenti caratteri jolly nei certificati   È opportuno porsi le seguenti domande: Quali client verranno supportati? Come è stato accennato in precedenza, "client" in questo contesto si riferisce ai client che accedono a Exchange da Internet.

• Lo spazio dei nomi dell'organizzazione   Come è configurato lo spazio dei nomi Internet Information Services (IIS) esposto a Internet?

• Origine del certificato   Dove si intende ottenere il certificato? La CA pubblica selezionata supporta l'utilizzo di caratteri jolly nei campi Subject o Subject Alternative Name (SAN)? In caso negativo, la CA supporta le SAN?

Questi aspetti verranno esaminati in modo più approfondito nelle seguenti sezioni.

Supporto dei nomi contenenti caratteri jolly nei certificati

I nomi contenenti caratteri jolly possono essere utilizzati nelle estensioni Subject o SAN dei certificati X.509. Per ulteriori informazioni sui nomi contenenti caratteri jolly, vedere "CertificateDomains" in Concetti relativi agli attributi dei certificati e modalità di utilizzo dei certificati da parte di Exchange 2007 più avanti in questo argomento.

Una volta stabiliti i client che verranno supportati dall'organizzazione, è utile determinare se tali client supportano nomi contenenti caratteri jolly nei certificati dei server ai quali si connettono.

Se il client supporta l'utilizzo di nomi contenenti caratteri nel certificato, la pianificazione complessiva relativa ai certificati per l'organizzazione risulterà notevolmente semplificata. Se tutti i client supportano l'utilizzo di nomi contenenti caratteri jolly nei certificati e l'organizzazione usa un solo nome di dominio, per la strategia di distribuzione dei certificati non è necessario prevedere una pianificazione dello spazio dei nomi. In questo caso è possibile creare un singolo certificato che supporti lo spazio dei nomi con un carattere jolly. Ad esempio, se i client che eseguono Outlook Web Access utilizzano mail.contoso.com/owa e i client POP3 utilizzano pop.contoso.com per accedere alla posta elettronica, un singolo certificato con un Subject con carattere jolly *.contoso.com supporterà entrambi i client.

I seguenti client Microsoft supportano i nomi contenenti caratteri jolly nei certificati:

• Outlook

  Nota

  Quando i certificati jolly vengono distribuiti nei server Exchange in cui è in esecuzione il ruolo Accesso client, è necessario configurare le impostazioni del servizio di individuazione automatica perché i client di Outlook 2007 possano connettersi. Per ulteriori informazioni su questo problema e su come risolverlo, vedere Un certificato con caratteri jolly causa problemi di connettività client per Outlook via Internet.

• Internet Explorer (Outlook Web Access)

• Server Trasporto Edge di Exchange (Protezione del dominio)

Se un client supportato dall'organizzazione non supporta l'uso di nomi contenenti caratteri jolly nel certificato server e occorre fornire il supporto per più spazi dei nomi client, è necessario

1. Acquistare un certificato contenente più nomi, ad esempio mail.contoso.com, pop.contoso.com e mobile.contoso.com nell'estensione SAN.

2. Acquistare un certificato per ciascuna entità presente nello spazio dei nomi alla quale il client si connetterà.

Pianificazione per lo spazio dei nomi dell'organizzazione

Tutti i client devono disporre di un URL o di un nome di dominio completo (FQDN, Fully Qualified Domain Name) al quale connettersi. Ogni percorso al quale si connettono i client deve essere associato a un certificato valido contenente il nome host, il nome NetBIOS, il nome di dominio completo (FQDN) o il nome comune dell'host al quale viene eseguita la connessione. La determinazione dell'elenco dei nomi da includere nel certificato è il cosiddetto processo di pianificazione dello spazio dei nomi.

In genere, la pianificazione dello spazio dei nomi per grandi organizzazioni che supportano molti client diversi, che si estendono per più regioni e che gestiscono diversi server è più complessa rispetto alla pianificazione per organizzazioni di dimensioni più piccole.

È necessario disporre di una buona conoscenza della pianificazione dello spazio dei nomi relativa ai certificati per sapere quali nomi host includere nell'estensione SAN del certificato utilizzato al fine di proteggere le connessioni in entrata a Exchange 2007.

Per ulteriori informazioni, vedere Concetti relativi alla pianificazione dello spazio dei nomi per Exchange Server 2007.

Dove ottenere un certificato

Come accennato in precedenza, per l'accesso da parte di client esterni si consiglia di acquistare un certificato da una CA pubblica di terze parti.

Quando si valutano le autorità di certificazione, considerare i seguenti criteri:

• La CA consente l'uso di nomi contenenti caratteri jolly nel certificato? Se i client sono in grado di supportare i nomi contenenti caratteri jolly nel certificato, l'acquisto di un certificato dalla CA che supporti nomi contenenti caratteri jolly rappresenta il metodo più semplice per distribuire client protetti.

• La CA supporta l'estensione SAN? Nei seguenti casi potrebbe essere consigliabile utilizzare un certificato in grado di supportare più nomi nell'estensione SAN:

  • Se è necessario supportare client che non supportano i nomi contenenti caratteri jolly nel certificato.

  • Se si dispone di più percorsi host al quale i client devono connettersi.

  Microsoft collabora con CA pubbliche con l'obiettivo di fornire un certificato Unified Communications. Per un elenco aggiornato di CA che supportano i certificati Unified Communications, vedere l'articolo della Microsoft Knowledge Base 929395, Partner di certificati Unified Communications per Exchange 2007 e Communications Server 2007.

• La CA fornisce un alto livello di verifica dell'autenticità? Alcune CA offrono prezzi molto convenienti, mentre altre pretendono centinaia di dollari all'anno per un certificato. Poiché si conta sull'integrità di questo certificato per autenticare il traffico in entrata dell'organizzazione, si consiglia di non selezionare una CA pubblica esclusivamente in base al prezzo: prima di effettuare una scelta, è consigliabile valutare attentamente i servizi offerti e confrontarli con quelli di altre CA e, inoltre, di verificare la reputazione di ciascuna CA.

Inizio pagina

Concetti relativi agli attributi dei certificati e modalità di utilizzo dei certificati da parte di Exchange 2007

Una conoscenza approfondita dei vari attributi dei certificati consentirà di capire il modo in cui i certificati vengono utilizzati da Exchange. Queste informazioni saranno utili, inoltre, nella pianificazione delle esigenze di certificati nella propria organizzazione di Exchange e per la risoluzione di eventuali problemi.

I certificati X.509 hanno due tipi di attributi.

• I campi del certificato sono attributi all'interno dei dati firmati del certificato X.509 stesso. L'integrità di questi campi è protetta dalla firma e il loro valore non può essere modificato senza apporre nuovamente la firma o senza che il certificato debba essere riemesso.

• Gli attributi dei certificati sono metadati del certificato o della chiave pubblica. Alcune proprietà sono intrinseche del certificato o della chiave privata, ad esempio l'identificazione personale. Tuttavia, molte proprietà possono essere modificate senza che il certificato debba essere nuovamente firmato.

  Ad esempio, il cmdlet Enable-ExchangeCertificate consente di aggiungere servizi alle proprietà dei certificati una volta che questi sono stati creati. È possibile abilitare certificati per l'utilizzo con IIS (Outlook Web Access o Exchange ActiveSync), SMTP (trust diretto o Protezione del dominio), IMAP, POP e Messaggistica unificata. Abilitando un certificato per un determinato servizio si aggiornano le proprietà del certificato. Per ulteriori informazioni, vedere Enable-ExchangeCertificate.

È possibile visualizzare questi attributi eseguendo il cmdlet Get-ExchangeCertificate con l'argomento |FL su un determinato certificato. Se si sta eseguendo Exchange 2007 RTM, per visualizzare tutti i dati degli attributi è necessario eseguire il cmdlet con l'argomento |FL* .

Alcuni campi e proprietà specificati nell'output del cmdlet Get-ExchangeCertificate sono associati ai campi di estensione X.509 che possono essere visualizzati utilizzando Gestione certificati in Microsoft Management Console (MMC). Per ulteriori informazioni su Gestione certificati, vedere Come aggiungere Gestione certificati a MMC (Microsoft Management Console). Per ulteriori informazioni sul cmdlet Get-ExchangeCertificate, vedere Get-ExchangeCertificate.

Campi del certificato

Come descritto in precedenza, i campi del certificato sono attributi all'interno dei dati firmati del certificato X.509 stesso. In questa sezione vengono descritti i campi del certificato che vengono utilizzati dai servizi di Microsoft Exchange e visualizzati nell'output del cmdlet Get-ExchangeCertificate.

Alcuni di questi campi sono anche parametri che è possibile impostare quando si crea un nuovo certificato o una richiesta di certificato con il cmdlet New-ExchangeCertificate. Per ulteriori informazioni sul cmdlet New-ExchangeCertificate vedere New-ExchangeCertificate.

Ogni campo del certificato in questa sezione è elencato in base all'output del cmdlet Get-ExchangeCertificate. Ogni nome di campo del certificato Exchange presente in questa sezione è associato a un nome di estensione del certificato X.509.

Issuer

Questo campo contiene il nome comune dell'autorità di certificazione. Nei certificati autofirmati creati da Exchange durante l'installazione o mediante il cmdlet New-ExchangeCertificate è visualizzato cn=hostname, dove hostname (nome host) è il nome del server locale.

Nei certificati emessi dalle CA in genere è visualizzato il nome comune completo della CA nel campo relativo all'autorità emittente.

Il nome di estensione del certificato X.509 è Issuer.

Per il campo Issuer non è disponibile un parametro corrispondente da poter impostare nel cmdlet New-ExchangeCertificate. Il campo Issuer viene specificato dall'autorità che emette il certificato.

Subject

Questo campo identifica il soggetto del certificato. Subject è una stringa X.500 che in genere rappresenta un singolo nome utilizzato per accedere al servizio che usa il certificato. Quando un certificato viene creato mediante il cmdlet New-ExchangeCertificate, se il soggetto non viene fornito in modo esplicito, Subject sarà il primo valore elencato nel parametro DomainName quando si esegue il cmdlet New-ExchangeCertificate. Possono essere presenti i seguenti campi X.500:

• C = Country (Paese)

• ST = State (Stato)

• L = Location (Posizione)

• O = Organization (Organizzazione)

• OU = Organizational Unit (Unità organizzativa)

• CN = Common Name (Nome comune)

Alcuni di questi campi sono necessari quando si generano richieste per certificati di CA di terze parti. Per una spiegazione dettagliata del campo Subject, vedere Creazione di un certificato o di una richiesta di certificato per TLS.

Se si sta eseguendo Microsoft Internet Security and Acceleration (ISA) Server 2006 in combinazione con Exchange per il bridging, assicurarsi di leggere il post di blog I certificati con più voci SAN possono provocare errori nel caso di pubblicazione Web tramite ISA Server (informazioni in lingua inglese) per ottenere ulteriori informazioni sui nomi di soggetto e sul comportamento di ISA Server.

Quando in Exchange viene generato un certificato autofirmato senza alcun argomento utente, il certificato contiene un nome soggetto CN=hostname (nome host).

Il nome di estensione del certificato X.509 è Subject.

Il campo Subject si imposta specificando il parametro SubjectName nel cmdlet New-ExchangeCertificate.

CertificateDomains

Il campo CertificateDomains identifica tutti nomi di dominio DNS associati al certificato. I nomi di dominio DNS possono essere l'attributo nome comune (cn=) di Subject oppure l'estensione SAN di un certificato. Nell'output del cmdlet Get-ExchangeCertificate è visualizzata l'unione del campo Subject e di eventuali altri domini inclusi nell'estensione SAN.

I valori contenuti nel campo CertificateDomains possono includere il nome host o il nome di dominio completo (FQDN) utilizzato per accedere al server. Per utilizzare un certificato, il nome di dominio completo utilizzato da un client per connettersi al server deve essere presente nel campo CertificateDomains del certificato.

Ad esempio, se un client si connette a un server utilizzando POP3 con mail.fourthcofee.com come nome del server, il certificato associato alle impostazioni POP3 deve contenere mail.fourthcofee.com nel relativo campo CertificateDomains.

Alcuni certificati possono contenere anche nomi con caratteri jolly, ad esempio *.fourthcofee.com. Quest'ultimo è considerato un dominio accettabile. Tuttavia, è necessario tenere presente che alcuni client e dispositivi mobili legacy non supportano i nomi contenenti caratteri jolly nel certificato e di conseguenza potrebbero non supportare domini con caratteri jolly.

Per una spiegazione dettagliata dell'utilizzo delle estensioni SAN e dei nomi contenenti caratteri jolly nei certificati, vedere Creazione di un certificato o di una richiesta di certificato per TLS. Inoltre, il blog del team di Exchange, Lezioni di Exchange 2007 - generazione di un certificato con una CA di terze parti (informazioni in lingua inglese), contiene consigli pratici per creare una richiesta di certificato con più SAN.

L'estensione del certificato X.509 è Subject Alternative Name, tuttavia, come accennato in precedenza, l'output del cmdlet Get-ExchangeCertificate aggiunge anche il valore contenuto nell'estensione di certificato Subject all'elenco dei nomi nel campo CertificateDomains.

Il campo CertificateDomains si imposta specificando i parametri DomainName e Subject nel cmdlet New-ExchangeCertificate.

NotBefore e NotAfter

I valori nei campi NotBefore e NotAfter rappresentano un intervallo di date in cui il certificato è valido per l'utilizzo. Se la data corrente è successiva alla data NotAfter, il certificato è considerato scaduto. Microsoft Exchange è in grado di utilizzare certificati scaduti, tuttavia nei client verranno generati avvisi e nel server verranno registrati eventi appropriati nel registro eventi.

Il nome dell'estensione del certificato X.509 associata al valore NotBefore è Valid from. Il nome dell'estensione del certificato X.509 associata al valore NotAfter è Valid to.

Per i campi NotBefore e NotAfter non sono disponibili parametri corrispondenti impostabili nel cmdlet New-ExchangeCertificate. Questi campi sono definiti dall'autorità che emette il certificato. I certificati autofirmati generati all'installazione di Exchange o mediante il cmdlet New-ExchangeCertificate sono validi per un anno.

CertificateRequest

Questo valore è presente solo nei certificati che si trovano ancora nello stato di richiesta. Le richieste di certificato non sono certificati X.509 validi e pertanto non verranno utilizzate da Exchange.

Il campo CertificateRequest viene abilitato specificando l'opzione di parametro GenerateRequest del cmdlet New-ExchangeCertificate.

Proprietà del certificato

Come spiegato in precedenza, gli attributi dei certificati sono metadati del certificato o della chiave pubblica. Alcune proprietà sono intrinseche del certificato o della chiave privata, come ad esempio l'identificazione personale, tuttavia molte proprietà possono essere modificate senza che il certificato debba essere nuovamente firmato.

Ad eccezione della proprietà Thumbprint, nessuna proprietà del certificato corrisponde a un'estensione di certificato X.509.

In questa sezione vengono descritte le proprietà del certificato.

IsSelfSigned

La proprietà IsSelfSigned indica se un certificato è autofirmato. Un certificato autofirmato in genere è un cosiddetto certificato radice, ovvero un certificato che non ha altri certificati nella catena di certificati. Il certificato autofirmato in Exchange si riferisce in genere ai seguenti tipi di certificato:

• Un certificato generato quando Exchange viene installato in un server in cui non è presente alcun certificato di qualifica

• Un certificato che risulta dall'esecuzione del cmdlet New-ExchangeCertificate.

Quando vengono installati i ruoli del server Trasporto Hub, Trasporto Edge, Messaggistica unificata o Accesso client, durante l'installazione di Exchange viene generato un certificato autofirmato. Se nell'archivio certificati Personale del computer host è presente un certificato valido, verrà utilizzato il certificato esistente e non verrà utilizzato il certificato autofirmato generato all'installazione di Exchange. I valori validi sono True o False.

RootCAType

La proprietà RootCAType identifica il tipo di CA che ha emesso il certificato. Se il parametro IsSelfSigned è impostato su True, il valore della proprietà RootCAType dovrebbe essere None. In caso contrario, il certificato potrebbe dare luogo a risultati imprevisti nel processo di selezione del certificato. Altri valori possibili sono:

• Registry   Una CA radice PKI privata interna è stata installata manualmente nell'archivio certificati.

• ThirdParty   Una CA radice pubblica di terze parti.

• GroupPolicy   Una CA radice PKI privata interna che è stata distribuita con Criteri di gruppo.

• Enterprise   Una CA radice PKI privata interna che è stata distribuita con Active Directory.

• Unknown   Exchange non è in grado di determinare il tipo di certificato installato.

Può essere utile conoscere la modalità con cui il certificato CA radice è stato installato nel computer per diagnosticare eventuali incoerenze nei criteri di attendibilità. Come conseguenza di tali incoerenze è possibile che i certificati vengano convalidati su determinati server e non su altri.

Ad esempio, un valore di Registry indica che un utente ha installato manualmente un certificato in un server. Ciò potrebbe dare luogo a incoerenze se il certificato non è stato installato in altri server dell'organizzazione. Si consiglia, pertanto, di distribuire i certificati in tutti i computer utilizzando Criteri di gruppo o Active Directory.

Services

La proprietà Services identifica i servizi con i quali è possibile utilizzare il certificato. I valori validi sono SMTP, POP, IMAP, UM e IIS.

Il valore nel campo Services viene impostato specificando il parametro Services nel cmdlet Enable-ExchangeCertificate. Per ulteriori informazioni, vedere Enable-ExchangeCertificate.

Status

La proprietà Status identifica se il certificato è valido o meno. Il campo Status è utilissimo durante la risoluzione di problemi relativi ai certificati. Se il valore Status per un determinato certificato non è Valid, il certificato non verrà utilizzato dal server Exchange per i servizi. I valori per la proprietà Status includono i seguenti:

• Unknown   Questo stato indica in genere che non è possibile verificare lo stato del certificato perché l'elenco di revoche di certificati (CRL, Certificate Revocation List) non è disponibile oppure il server non è in grado di connettersi a questo elenco. Assicurarsi che il computer sia in grado di connettersi all'autorità responsabile della revoca dei certificati. Per ulteriori informazioni, vedere Come configurare le impostazioni proxy per WinHTTP.

• Valid   Il certificato funziona correttamente.

• Revoked   L'elenco di revoche dei certificati ha indicato che questo certificato è stato revocato. È necessario generare un nuovo certificato.

• DateInvalid   Questo stato indica che l'ora di sistema è inesatta, il certificato è scaduto oppure l'ora del sistema che ha firmato il file è inesatta. Verificare che siano soddisfatte le seguenti condizioni:

  • L'orologio del computer locale è preciso.

  • Il certificato non è scaduto.

  • L'orologio del sistema di invio è preciso.

  Se il certificato è scaduto, è necessario generare un nuovo certificato.

• Untrusted   Questo stato indica che il certificato non è autofirmato. Tuttavia è firmato da una CA che non è considerata attendibile dal computer locale. È necessario aggiungere il certificato CA all'archivio Autorità di certificazione radice disponibile nell'elenco locale. Per ulteriori informazioni sull'aggiunta manuale dei certificati nell'archivio di certificati locale, vedere il file della Guida per Gestione certificati in MMC.

• Invalid   Il certificato è stato invalidato a seguito di un altro problema, ad esempio per via di un certificato non attendibile, non valido o revocato in una determinata posizione del percorso del certificato.

Per ulteriori informazioni sulla risoluzione del problema, vedere i seguenti argomenti:

• Come correggere gli errori di convalida del certificato

• Come verificare la PKI e la configurazione proxy

• Come configurare le impostazioni proxy per WinHTTP

HasPrivateKey

La proprietà HasPrivateKey indica se il certificato installato ha una chiave privata. Questa proprietà è molto importante in quanto il servizio di trasporto di Microsoft Exchange, il servizio Microsoft Exchange POP3 e il servizio Microsoft Exchange IMAP4 non utilizzeranno un certificato che non dispone di una chiave privata.

Thumbprint

La proprietà Thumbprint è una stringa univoca che identifica il certificato. Se lo stesso certificato è installato in più server Exchange, è possibile identificarli mediante la rispettiva identificazione personale. Lo stesso certificato in genere è installato in più server Exchange quando più server Trasporto Edge accettano lo stesso nome di dominio completo (FQDN), ad esempio mail.fourthcoffee.com. È molto più conveniente installare lo stesso certificato in più server che richiedere nuovi certificati per ciascun server. Tuttavia il certificato deve disporre di una chiave privata esportabile.

La proprietà Thumbprint viene utilizzata per specificare un certificato per i seguenti cmdlet:

• Get-ExchangeCertificate

• Remove-ExchangeCertificate

• Export-ExchangeCertificate

• Enable-ExchangeCertificate

Il nome dell'estensione di certificato X.509 associata al valore Thumbprint è anch'esso Thumbprint.

Inizio pagina

Attendibilità e convalida dei certificati

Per utilizzare un certificato per l'autenticazione, il certificato deve essere convalidato e attendibile.

Per convalidare un determinato certificato X.509, è necessario riconoscere come attendibile l'Autorità di certificazione radice che ha emesso il certificato. La CA radice è considerata la CA più attendibile e si trova al vertice di una CA. L'Autorità di certificazione radice ha un certificato autofirmato. Se si esegue un'applicazione basata sull'autenticazione dei certificati, ogni certificato deve disporre di una catena di certificati che termina con un certificato nel contenitore radice attendibile del computer locale. Il contenitore radice attendibile contiene certificati provenienti dalle CA radice.

Un certificato è concatenato a una CA mediante un altro certificato. Anche quest'ultimo certificato potrebbe essere stato emesso da una CA e pertanto sarebbe concatenato a tale CA. Questo concatenamento di certificati è noto anche come percorso di certificazione. Affinché il certificato possa essere considerato valido, deve essere valido ogni certificato lungo il percorso di certificazione. Inoltre, il certificato al vertice della catena deve essere di una CA radice attendibile.

Esistono due tipi di CA radice attendibili che possono essere utilizzati per implementare applicazioni che richiedono l'autenticazione tramite certificato: CA radice pubbliche di terze parti e CA radice private.

Autorità di certificazione radice di terze parti

Windows, Windows Mobile e vari sistemi operativi di terze parti includono un insieme di CA radice di terze parti incorporate. Se si considerano come attendibili i certificati emessi da queste autorità di certificazione radice pubbliche di terze parti, è possibile verificare i certificati emessi da dette autorità di certificazione.

L'attendibilità è automatica se sono soddisfatte le seguenti condizioni:

• L'organizzazione utilizza l'installazione di Windows predefinita

• Il software client e i dispositivi mobili utilizzati nell'organizzazione considerano attendibili le CA radice pubbliche di terze parti incorporate

In questo caso non è necessaria una configurazione di attendibilità aggiuntiva.

Autorità di certificazione radice private disponibili nell'elenco locale

Un'Autorità di certificazione radice privata disponibile nell'elenco locale è un'Autorità di certificazione radice che è stata distribuita da una PKI privata o interna. Ad esempio, quando l'organizzazione ha distribuito una PKI interna con un proprio certificato radice, è necessario effettuare configurazioni di attendibilità aggiuntive.

In genere non è consigliabile utilizzare certificati emessi da una PKI privata per applicazioni client che supportano connessioni esterne all'organizzazione.

Quando si utilizzano CA radice private, è necessario aggiornare l'archivio di certificati radice attendibili di Windows in tutti i dispositivi, nei client e nei sistemi operativi Windows in cui è richiesta l'autenticazione.

È possibile configurare l'attendibilità in due modi: trust radice diretto e certificazione incrociata.

Trust radice diretto

Se si desidera considerare come valido un certificato emesso da una CA radice privata, è possibile aggiungere manualmente il certificato radice all'archivio di certificati radice attendibili nel computer che esegue Windows. In alcuni casi è possibile aggiungere un certificato radice anche all'archivio di certificati radice attendibili dei client mobili. Per ulteriori informazioni sull'aggiunta manuale dei certificati nell'archivio di certificati locale di un computer che esegue Windows, vedere il file della Guida di Gestione certificati in MMC. Per ulteriori informazioni su come installare certificati nei dispositivi mobili Windows, vedere Installazione di certificati radice in un dispositivo basato su Windows Mobile.

Certificazione incrociata

La certificazione incrociata viene generata quando una CA firma un certificato generato da una CA diversa. La certificazione incrociata viene utilizzata per creare trust da un'infrastruttura a chiave pubblica con un'altra infrastruttura a chiave pubblica. Se si dispone di una PKI propria, anziché utilizzare il trust manuale diretto per una CA radice di un'altra PKI privata, è possibile creare un certificato incrociato per l'altra CA sotto la propria CA radice. In questo caso, l'attendibilità viene stabilita in quanto il certificato incrociato rimanda alla CA radice attendibile.

Configurazione dell'accesso all'elenco di revoche di certificati

Quando un determinato servizio recupera un certificato, ad esempio il servizio di trasporto di Microsoft Exchange nello scenario SMTP/TLS oppure IIS nello scenario HTTPS, il servizio convalida la catena di certificati e il certificato stesso. La convalida del certificato è un processo in cui vengono confermati molti attributi del certificato. La maggior parte di questi attributi può essere confermata sul computer locale dall'applicazione che richiede il certificato. Ad esempio, l'uso previsto del certificato, le date di scadenza sul certificato e attributi simili possono essere verificati all'esterno del contesto di un'infrastruttura a chiave pubblica. Tuttavia, la verifica che il certificato non sia stato revocato deve essere convalidata con l'Autorità di certificazione che ha emesso il certificato. Per questo motivo la maggior parte delle Autorità di certificazione mette a disposizione del pubblico un elenco di revoche di certificati (CRL, Certificate Revocation List) per convalidare lo stato di revoca.

Per eseguire correttamente l'autenticazione con i certificati, è necessario che i CRL per le CA utilizzate siano accessibili ai servizi che eseguono l'autenticazione del client. Se la verifica della revoca non riesce, l'autenticazione non sarà possibile.

I server che eseguono l'autenticazione devono essere in grado di accedere ai CRL per le CA esterne.

Tutte le CA pubbliche dispongono di CRL che sono disponibili pubblicamente e possono essere contattate da parte dei server dell'organizzazione. In alcuni casi, i CRL per PKI private interne sono disponibili solo con il protocollo LDAP (Lightweight Directory Access Protocol). Nella maggior parte dei casi, con CA pubbliche, gli elenchi di revoche di certificati vengono pubblicati tramite il protocollo HTTP. Assicurarsi di avere configurato le porte in uscita e i proxy appropriati per consentire ai server e ai client di mettersi in contatto con l'elenco di revoche di certificati. È possibile determinare il protocollo accettato da uno specifico punto di distribuzione dell'elenco di revoche di certificati aprendo un certificato in MMC e visualizzando il campo CRL Distribution Points (Punti di distribuzione Elenco di revoche di certificati [CRL]).

In alcuni casi potrebbe essere necessario rendere pubblicamente accessibile il CRL per la CA che emette i certificati. Ad esempio, se si distribuisce Protezione del dominio è necessario tenere presente che, anche quando un server Trasporto Edge recupera un certificato dall'organizzazione, esso convalida la catena di certificati per convalidare il certificato stesso. Pertanto, l'elenco di revoche di certificati per la CA deve essere a disposizione dei server Trasporto Edge in uso. Inoltre, tutti i partner con cui si scambiano messaggi di posta elettronica con dominio protetto devono essere in grado di accedere all'elenco di revoche di certificati per l'Autorità di certificazione che emette i certificati.

Configurazione delle impostazioni proxy per WinHTTP

I server di trasporto di Exchange 2007 si basano sui servizi HTTP Windows (WinHTTP) secondari per la gestione di tutto il traffico HTTP e HTTPS. Ad esempio, sia i server Trasporto Hub sia i server Trasporto Edge possono utilizzare HTTP per accedere agli aggiornamenti standard del filtro della posta indesiderata di Exchange 2007 e al servizio di aggiornamento della protezione dalla posta indesiderata di Microsoft Forefront Security per Exchange Server. Tutti i ruoli del server Exchange utilizzano WinHTTP per abilitare la convalida CRL.

Per ulteriori informazioni, vedere Come configurare le impostazioni proxy per WinHTTP.

Verifica della configurazione proxy e PKI

Per verificare la configurazione proxy e PKI per uno specifico server Exchange, utilizzare Certutil.exe per esaminare la catena di certificati per il certificato server. Certutil.exe è uno strumento della riga di comando installato come parte dei Servizi certificati nei sistemi operativi Windows Server. Per ulteriori informazioni, vedere Come verificare la PKI e la configurazione proxy.

Inizio pagina

Creazione, importazione e abilitazione di certificati

Esistono vari metodi per ottenere un certificato che sia installato e operativo in Exchange 2007. La scelta del metodo dipende dalle esigenze specifiche. In Exchange 2007 viene generato un insieme di certificati autofirmati per consentire la protezione della configurazione predefinita. Tali certificati devono essere rinnovati con il passare del tempo per garantire la protezione del sistema. In Exchange non vengono automaticamente generate richieste di firma da parte delle autorità di certificazione. Che si intenda creare un nuovo certificato autofirmato o una richiesta di certificato per un'autorità di certificazione, entrambi i metodi utilizzano lo stesso cmdlet.

Questa sezione offre una panoramica delle operazioni che possono essere eseguite con i certificati utilizzati da Exchange 2007. È consigliabile leggere questa sezione se non si ha familiarità con i cmdlet ExchangeCertificate. Esempi e procedure specifici delle applicazioni vengono forniti più avanti in questo documento, utilizzando POP3 come esempio. In questa sezione vengono inoltre forniti collegamenti alla documentazione specifica dell'applicazione.

Cmdlet dei certificati

Nelle versioni precedenti di Exchange Server l'intera gestione dei certificati veniva eseguita tramite IIS e Gestione certificati in MMC. In Exchange 2007 la maggioranza delle attività di gestione dei certificati relative a Exchange può essere eseguita utilizzando i cmdlet ExchangeCertificate con Exchange Management Shell:

• New-ExchangeCertificate   Questo cmdlet consente di generare certificati autofirmati e richieste di certificati per le autorità di certificazione.

• Import-ExchangeCertificate   Questo cmdlet consente di importare certificati che sono stati esportati in precedenza e di importare file di certificato generati dalle CA.

• Export-ExchangeCertificate   Questo cmdlet consente di esportare certificati per il backup o per l'utilizzo in più server.

• Enable-ExchangeCertificate   Questo cmdlet consente di abilitare servizi specifici su un certificato.

• Get-ExchangeCertificate   Questo cmdlet consente di visualizzare gli attributi di un certificato.

• Remove-ExchangeCertificate   Questo cmdlet consente di rimuovere certificati da Exchange Server e dall'archivio certificati locale.

Per ulteriori informazioni su come creare richieste di certificati per le autorità di certificazione, vedere Creazione di un certificato o di una richiesta di certificato per TLS.

Nelle seguenti sezioni vengono forniti dei brevi esempi per illustrare l'utilizzo dei cmdlet ExchangeCertificate per l'esecuzione di alcune attività comuni relative ai certificati. Per ulteriori informazioni ed esempi, vedere la Guida dei cmdlet ExchangeCertificate sotto Cmdlet globali.

Generazione di certificati autofirmati

Per generare un certificato autofirmato per l'utilizzo da parte del servizio SMTP per un server con nome host Server1 e un dominio denominato fourthcoffee.com, eseguire il seguente comando:

New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

Clonazione di certificati autofirmati

Se è necessario rinnovare un certificato autofirmato esistente, è possibile clonarlo eseguendo il seguente comando:

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

Il segnaposto identificazione digitale è l'identificazione digitale del certificato da rinnovare. È possibile specificare anche i servizi per il nuovo certificato, procedendo nel modo seguente:

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

È quindi possibile abilitare questo certificato eseguendo il seguente comando:

Enable-ExchangeCertificate <thumbprint>

Creazione di richieste di certificati e installazione di certificati attendibili

L'installazione di un certificato pubblico di terze parti è un processo più complesso. È necessario generare una richiesta di certificato, importare il certificato emesso e tutti i certificati CA necessari, quindi abilitare il certificato emesso per lo scopo o gli scopi prefissi.

In questa sezione viene fornito un esempio di come abilitare il servizio POP3 per l'utilizzo mediante un certificato. Nell'esempio i client si connettono al servizio POP3 connettendosi al nome di dominio completo (FQDN) popserver.fourthcoffee.com.

Richiesta di certificato

Poiché il certificato risultante proviene da una CA pubblica di terze parti, è necessario innanzitutto generare una richiesta di certificato eseguendo il seguente comando:

New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

Se la richiesta di certificato è stata generata correttamente, verrà creato un file di richiesta di certificato (file CER o DER) nella directory principale dell'unità di sistema e in Exchange Management Shell verrà visualizzata un'identificazione personale per la richiesta.

Nel comando precedente il parametro PrivateKeyExportable è impostato su $True. Ciò consente di esportare questo certificato insieme alla chiave privata per l'utilizzo in più server Exchange ai quali potrebbe essere necessario accedere utilizzando lo stesso nome di dominio completo (FQDN). Ad esempio, è possibile eseguire il bilanciamento del carico di più server Accesso client per supportare connessioni POP3.

Il comando precedente specifica inoltre il parametro Subjectname come nome X.500. La maggioranza delle CA di terze parti richiede che venga specificato un nome X.500 valido per il nome del soggetto del certificato. Come requisito minimo, la maggioranza delle CA richiede che l'organizzazione elencata nel campo organizationName (o=) sia proprietaria del nome di dominio riportato in commonName (cn=) del server Web.

Una volta completata la richiesta, il file della richiesta può essere inviato a un fornitore di certificati per ottenere un certificato.

Importazione di un certificato

Dopo che un certificato è stato restituito da una CA, è necessario importarlo nel server Exchange. Per importare correttamente un certificato per il quale è stata generata una richiesta utilizzando il cmdlet New-ExchangeCertificate, eseguire il seguente comando:

Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

Se il certificato è stato importato correttamente, questo comando restituirà un'identificazione personale del certificato che sarà possibile utilizzare per l'abilitazione di determinati servizi.

Abilitazione di un certificato

L'abilitazione di un certificato consente di specificare i servizi che utilizzeranno un certificato specifico. Il seguente comando consente di abilitare il certificato emesso per il servizio POP3:

Enable-ExchangeCertificate <thumprint> -Services:"POP"

È possibile importare e abilitare contemporaneamente un certificato eseguendo il seguente comando:

Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

Convalida dell'installazione di un certificato

Per confermare che tutti i passaggi richiesti sono stati completati e che il certificato è installato e operativo, eseguire il seguente comando:

Get- ExchangeCertificate <thumbprint> | fl *

L'output di questo comando restituisce dati simili a quelli riportati di seguito:

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=3rdPartyCAExample.com
NotAfter           : 8/7/2008 10:04:02 AM
NotBefore          : 8/7/2007 10:04:02 AM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 83FAE8B2398F2A9E44485CBA85D548DF
Services           : POP
Status             : Valid
Subject            : C=us,o=contoso corp, CN=fourthcoffee.com 
Thumbprint         : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

Esaminare l'output di questo comando per convalidare che le seguenti informazioni sono corrette:

• I nomi di dominio previsti sono elencati nel campo CertificateDomains.

• La proprietà HasPrivateKey è impostata su True.

• La proprietà RootCAType è impostata correttamente. Per ulteriori informazioni sulla proprietà RootCAType, vedere la precedente sezione Proprietà del certificato in questo documento.

• I servizi richiesti sono abilitati per il certificato.

• Lo Stato è impostato su Valid.

Servizi certificati

In un certificato possono essere abilitati servizi quali POP, IMAP, IIS e SMTP. I servizi non sono campi presenti nel certificato stesso, bensì proprietà dei metadati dei certificati. Pertanto possono essere modificati senza invalidare il certificato.

Quando si abilitano dei servizi, vengono apportate modifiche ad altri componenti, ad esempio alla metabase IIS, al file system o alle impostazioni IMAP4 e POP3. In questa sezione vengono descritte le modifiche che vengono apportate alla configurazione quando si abilita un determinato servizio eseguendo il cmdlet Enable-ExchangeCertificate.

POP e IMAP

Quando si aggiungono POP e IMAP come servizi aggiuntivi a un certificato, l'attributo x509CertificateName dell'oggetto POPSettings o dell'oggetto IMAPSettings viene aggiornato per includere il dominio nel soggetto del certificato.

Ad esempio, per verificare che l'oggetto POPSettings sia stato aggiornato, eseguire il seguente comando:

Get-POPSettings | fl *

IIS

Quando si abilita IIS, il sito Web IIS predefinito viene aggiornato per l'utilizzo del certificato specifico.

È possibile abilitare un certificato per IIS utilizzando il cmdlet Enable-ExchangeCertificate solo per il sito Web IIS predefinito. Se si ospita Outlook Web Access o il servizio di individuazione automatica su siti diversi dal sito Web IIS predefinito, è necessario utilizzare Gestione IIS per associare un certificato specifico ai certificati di tali siti Web.

SMTP

Quando si abilita il servizio SMTP in un certificato, all'account servizio di rete viene concesso l'accesso in lettura per il file di chiave privata appropriato nella directory Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys. Questa azione fornisce l'autorizzazione richiesta per accedere al servizio di trasporto di Microsoft Exchange e per utilizzare la chiave privata per decrittografare i messaggi protetti tramite TLS.

Servizio Messaggistica unificata di Microsoft Exchange

Quando si abilita il servizio Messaggistica unificata di Microsoft Exchange in un certificato, le proprietà del certificato vengono aggiornate per includere il servizio Messaggistica unificata. Il certificato viene utilizzato se sono soddisfatte le seguenti condizioni:

• Il ruolo del server Messaggistica unificata è installato nel computer.

• Il certificato contiene il nome di dominio completo fisico del computer locale nel campo CertificateDomains.

Inizio pagina

Selezione di un certificato

La selezione di un certificato è un processo che viene eseguito dai componenti di Exchange per determinare il certificato appropriato da utilizzare per una connessione in ingresso. SMTP STARTTLS, POP3 e IMAP4 eseguono un processo di selezione analogo per determinare il certificato da utilizzare per una determinata sessione. Questo processo è abbastanza deterministico. Tuttavia può creare confusione quando nel computer sono installati più certificati.

In questa sezione viene descritto il processo di selezione della certificazione per SMTP STARTTLS, SMTP X-AnonymousTLS, POP3 e IMAP4. Per ulteriori informazioni sulla selezione di certificati specifici per il trasporto, vedere Selezione del certifcato TLS SMTP.

SMTP STARTTLS

STARTTLS è il comando SMTP che consente di avviare una sessione TLS protetta. STARTTLS viene indicato da Exchange soltanto se nel computer che esegue Exchange è presente un certificato valido.

Per indicare o utilizzare STARTTLS, in Exchange viene selezionato un certificato in base al nome di dominio completo (FQDN) e a un valore corrispondente nel campo CertificateDomains di un certificato. Il nome di dominio completo è basato sulle seguenti informazioni:

• STARTTLS in uscita   Il certificato viene selezionato in base al valore del nome di dominio completo (FQDN) in un connettore di invio.

• STARTTLS in ingresso   Il certificato viene selezionato in base al valore del nome di dominio completo (FQDN) in un connettore di ricezione.

  Nota

  Per STARTTLS in uscita e in ingresso, se il nome di dominio completo (FQDN) del connettore non è specificato, viene utilizzato per la corrispondenza il nome di dominio completo fisico del server Exchange.

Una volta determinato il nome di dominio completo (FQDN), Exchange effettua una ricerca di tutti i certificati validi nell'archivio certificati Personale del computer host. Un certificato è considerato valido per l'utilizzo TLS se soddisfa i seguenti requisiti:

• Il campo Enhanced Key Usage (Utilizzo chiavi avanzato) contiene l'identificatore dell'oggetto autenticazione server (noto anche come OID, Object Identifier) oppure è vuoto.

• Nell'estensione certificato PKI (Public Key Infrastructure) è elencata una chiave RSA contenente un minimo di 1024 bit.

• Il certificato convalida la catena di certificati fino a una radice attendibile oppure il certificato è autofirmato.

• Il certificato e la catena di certificati superano la verifica della revoca.

• La chiave privata è presente e disponibile.

• La chiave privata non è memorizzata in un dispositivo rimovibile.

• La chiave privata non è protetta da password.

Se vengono rilevati più certificati validi, viene selezionato un certificato in base ai seguenti criteri:

• Il valore nel campo NotBefore   Viene selezionato il certificato valido più recente.

• Certificati emessi da una CA attendibile rispetto ai certificati autofirmati   Per la selezione viene assegnata la priorità ai certificati emessi da una CA attendibile.

Nella maggioranza dei casi viene selezionato un certificato emesso da una CA attendibile anziché un certificato autofirmato, indipendentemente dalla data di emissione di quest'ultimo. Se non viene trovato un certificato valido, STARTTLS non viene indicato.

SMTP X-AnonymousTLS

X-AnonymousTLS viene utilizzato per proteggere la comunicazione tra due server Trasporto Hub e tra server Trasporto Hub e server Trasporto Edge. In Exchange 2007 SP1 il processo di selezione dei certificati è stato semplificato in modo che tale che, se non viene individuato alcun certificato, viene generata per la sessione una chiave di crittografia temporanea.

Viene effettuata la ricerca per un certificato di trasporto interno. Se non viene individuato un certificato di trasporto interno valido, viene effettuata la ricerca di un certificato CA valido.

Pertanto, per la comunicazione da Hub a Hub in cui l'autenticazione è basata sul protocollo Kerberos, l'assenza di un certificato di trasporto interno valido non compromette la sessione SMTP. La sessione SMTP viene crittografata utilizzando la chiave di crittografia temporanea. In questo caso viene registrato un evento ed è necessario creare un nuovo certificato di trasporto interno eseguendo il cmdlet New-ExchangeCertificate senza argomenti sul computer che genera l'evento.

Per la comunicazione da Hub a Edge, dove il server Trasporto Edge è sottoscritto all'organizzazione, se non viene rilevato un certificato di trasporto interno valido, la sessione non riesce e viene registrato un errore. In questo caso è necessario eseguire il cmdlet New-ExchangeCertificate senza argomenti sul computer che genera l'evento, quindi eseguire nuovamente il servizio Microsoft Exchange EdgeSync.

POP3 e IMAP4

Come nel caso del processo di selezione dei certificati per SMTP STARTTLS, nel processo per POP3 e IMAP4, Exchange deve selezionare un nome di dominio completo (FQDN) e trovare un certificato sulla base di un valore corrispondente nel campo CertificateDomains. Il nome di dominio completo viene scelto sulla base dell'attributo X509CertificateName nelle impostazioni del servizio POP3 o IAP4. È possibile visualizzare l'attributo X509CertificateName eseguendo il cmdlet Get-POPSettings o il cmdlet Get-IMAPSettings. Per ulteriori informazioni, vedere Get-POPSettings e Get-IMAPSettings.

Il processo di selezione per POP3 e IMAP4 in Exchange 2007 SP1 è identico al processo per SMTP STARTTLS.

Messaggistica unificata   

Se si avvia il servizio Messaggistica unificata di Microsoft Exchange in modalità protetta, verrà effettuata una ricerca nell'archivio certificati Personale locale per trovare un certificato valido al fine di consentire a TLS di abilitare la crittografia. Il servizio Messaggistica di Microsoft Exchange cercherà innanzitutto un certificato valido emesso da una PKI privata o da una CA pubblica. Se non viene trovato un certificato appropriato, verrà effettuata una ricerca per un certificato autofirmato. Se non vengono individuati certificati PKI, pubblici o autofirmati, il servizio Messaggistica unificata di Microsoft Exchange crea un certificato autofirmato da utilizzare per l'avvio in modalità protetta. Se il server Messaggistica unificata si avvia in modalità non protetta, non è necessario alcun certificato.

Tutti i dettagli del certificato utilizzato per l'avvio in modalità protetta saranno registrati ogni qualvolta si utilizza un certificato o se il certificato viene modificato. Tra i dettagli registrati sono inclusi:

• Nome dell'emittente

• Numero di serie

• Identificazione personale

L'identificazione personale è l'hash Secure Hash Algorithm (SHA1), che può essere utilizzato per identificare in modo univoco il certificato utilizzato. È quindi possibile esportare dall'archivio certificati locale il certificato utilizzato dal servizio Messaggistica unificata di Microsoft Exchange per l'avvio in modalità protetta, quindi importarlo nell'archivio certificati attendibili dei gateway IP e degli IP PBX presenti nella rete.

Una volta individuato e utilizzato un certificato appropriato, il servizio Messaggistica unificata di Microsoft Exchange registra un evento un mese prima della scadenza di tale certificato. Se il certificato non viene modificato in questo periodo, il servizio Messaggistica unificata di Microsoft Exchange registrerà un evento ogni giorno fino alla scadenza del certificato e ogni giorno dopo la scadenza del certificato.

Quando il server Messaggistica unificata cerca un certificato per consentire a MTLS di stabilire un canale crittografato, la ricerca viene eseguita nell'archivio certificati radice attendibili. Se sono disponibili più certificati validi di diverse autorità emittenti, il server Messaggistica unificata sceglierà il certificato valido con la scadenza più lunga. Se esistono più certificati, il server Messaggistica unificata sceglierà i certificati in base all'emittente e alla data di scadenza. Il server Messaggistica unificata effettua la ricerca di un certificato valido nel seguente ordine di preferenza:

1. Certificato PKI o pubblico con la scadenza più lunga.

2. Certificato PKI o commerciale con la scadenza più breve.

3. Certificato autofirmato con la scadenza più lunga.

4. Certificato autofirmato con la scadenza più breve.

Inizio pagina

Ulteriori informazioni

In questo argomento è stato fatto riferimento alla seguente documentazione:

• I certificati con più voci SAN possono provocare errori nel caso di pubblicazione Web tramite ISA Server

• Creazione di un certificato o di una richiesta di certificato per TLS

• Creazione di un certificato o di una richiesta di certificato per TLS

• Riferimenti per la protezione dei percorsi dei dati

• Enable-ExchangeCertificate

• Lezioni di Exchange 2007 - generazione di un certificato con una CA di terze parti

• Export-ExchangeCertificate

• Get-ExchangeCertificate

• Get-IMAPSettings

• Get-POPSettings

• Come aggiungere Gestione certificati a MMC (Microsoft Management Console)

• Come configurare le impostazioni proxy per WinHTTP

• Come verificare la PKI e la configurazione proxy

• Import-ExchangeCertificate

• Lezioni: generazione di un certificato con una CA di terze parti

• Gestione della protezione dell'accesso client

• Gestione della protezione POP3 e IMAP4

• New-ExchangeCertificate

• Remove-ExchangeCertificate

• Selezione del certifcato TLS SMTP

• Funzionalità TLS e relativa terminologia in Exchange 2007

• Concetti relativi al processo di sincronizzazione EdgeSync

• Concetti relativi alla pianificazione dello spazio dei nomi per Exchange Server 2007

• Concetti relativi alla protezione VoIP per la messaggistica unificata

• I partner unificati di certificato di comunicazione per Exchange 2007 e Communications Server 2007

• White paper: Servizio di individuazione automatica di Exchange 2007

Inizio pagina