Come generare un CSR su Office 365

Questa guida spiega come generare una CSR (Certificate Signing Request) per Microsoft 365 (Office 365). La risposta onesta, prima di tutto: non si genera una CSR per il cloud Microsoft 365 in sé. Microsoft 365 è una piattaforma SaaS ospitata, quindi Microsoft possiede e gestisce i certificati TLS su outlook.office365.com, sugli endpoint di posta *.mail.protection.outlook.com, su *.sharepoint.com e sugli altri servizi ospitati da Microsoft. Non esiste una pagina del portale che accetti un certificato fornito dal cliente per quegli URL.

Una CSR entra in gioco solo quando si gestisce anche un server on-premises o ospitato nel cloud che si integra con Microsoft 365. La CSR viene generata su quel server, non nel portale di amministrazione di Microsoft 365. Le sezioni seguenti coprono gli scenari in cui questo accade realmente.

In quale scenario ti trovi?

Scegli la riga che corrisponde a ciò che stai effettivamente cercando di proteggere, quindi vai alla sezione corrispondente:

Cosa stai cercando di proteggere	Dove viene generata la CSR	Sezione
I servizi cloud di Microsoft 365 stessi (Exchange Online, SharePoint Online, Teams, outlook.office365.com)	Da nessuna parte. Microsoft gestisce quei certificati.	Perché non esiste una CSR per il cloud
Un server Exchange on-premises in una configurazione ibrida con Exchange Online	Sul server Exchange on-premises (PowerShell, o l’EAC nelle build supportate)	CSR per Exchange ibrido
Un server AD FS che federa l’accesso con Microsoft 365 / Entra ID	Sul server AD FS (richiesta certificato Windows)	CSR per federazione AD FS / Entra
Una web app, funzione o API di Azure App Service che si connette a Microsoft 365	Generata esternamente (con qualsiasi strumento), poi caricata su Azure	CSR per Azure App Service
Un server web Windows autonomo (IIS) che non è Exchange, ma si integra con Microsoft 365 (ad esempio un portale, un ricevitore di hook o un relay)	In IIS Manager su quel server	CSR per server IIS autonomo

Perché non esiste una CSR per il cloud Microsoft 365

Microsoft 365 è una piattaforma cloud multi-tenant completamente ospitata. I certificati TLS per Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams e ogni altro endpoint ospitato da Microsoft vengono emessi, distribuiti e rinnovati da Microsoft. Non esiste una pagina del centro amministrativo, un cmdlet PowerShell o un’API che permetta a un tenant di caricare un certificato di terze parti su outlook.office365.com, sugli endpoint di flusso di posta *.mail.protection.outlook.com, o su qualsiasi altro hostname di proprietà Microsoft. Questo vale anche nel caso in cui tu abbia aggiunto il tuo dominio personalizzato come contoso.com: una volta verificato il dominio, Microsoft continua a terminare il TLS per gli endpoint SMTP, IMAP, POP e HTTPS sottostanti, quindi non è necessaria alcuna CSR da parte tua.

Se il tuo obiettivo è applicare il TLS al flusso di posta tra Microsoft 365 e un partner esterno, lo fai tramite un connettore di Exchange Online che richiede al partner di presentare un certificato pubblico valido. Nessun certificato viene caricato dalla tua parte. Consulta la nostra guida all’installazione SSL per Microsoft 365 per i passaggi del connettore.

Genera la CSR per Exchange ibrido (Exchange Server on-premises)

Se hai già generato la tua CSR sul server Exchange on-premises, passa direttamente alla guida all’installazione SSL per Microsoft 365 / Exchange. Altrimenti, questo è il motivo più comune per cui i clienti chiedono una “CSR per Microsoft 365”. In una distribuzione ibrida, il tuo server Exchange on-premises (2016, 2019 o Subscription Edition) comunica con Exchange Online tramite OAuth, EWS e Autodiscover, e queste connessioni devono essere protette con un certificato pubblicamente attendibile. La CSR viene generata sul server Exchange on-premises, non su qualcosa in Microsoft 365.

Su ogni build di Exchange supportata (e come unico percorso supportato su Exchange 2016 CU23+ ed Exchange 2019 da CU12 a CU14, dove Microsoft ha rimosso le opzioni certificato dall’EAC), la CSR viene generata con PowerShell. Esegui Exchange Management Shell come amministratore sul server che conterrà la chiave privata, quindi esegui:

New-ExchangeCertificate `
  -GenerateRequest `
  -SubjectName "C=US, S=California, L=San Francisco, O=Example Inc, OU=IT, CN=mail.example.com" `
  -DomainName mail.example.com, autodiscover.example.com `
  -KeySize 2048 `
  -PrivateKeyExportable $true `
  | Set-Content -Path "C:certsexchange.req"

L’uso in due passaggi (l’output del cmdlet convogliato a Set-Content) è richiesto sulle build attuali: l’aggiornamento di sicurezza KB5014278 ha rimosso il vecchio parametro -RequestFile da New-ExchangeCertificate su Exchange 2016 CU23 ed Exchange 2019 CU12. Modifica i valori in base al tuo ambiente:

• C è il codice paese a due lettere (US, GB, DE, e così via).
• S è il nome completo dello stato o della provincia, non l’abbreviazione.
• L è la città o località completa.
• O è la ragione sociale legalmente registrata.
• OU è il reparto, spesso “IT”. Opzionale.
• CN è il nome host completamente qualificato principale che il certificato proteggerà, ad esempio mail.example.com.
• -DomainName è l’elenco di Subject Alternative Name (SAN) separati da virgola. Per una distribuzione ibrida, includi almeno mail.example.com e autodiscover.example.com, oltre a eventuali altri namespace che utilizzi (OWA, EWS, hostname ibridi).
• -KeySize 2048 è conforme ai requisiti di base del CA/Browser Forum. Usa 4096 solo se la tua policy di sicurezza lo richiede. Microsoft documenta solo 1024, 2048 e 4096 come valori validi per -KeySize, quindi non usare 3072 in questo caso.
• -PrivateKeyExportable $true ti permette di esportare la chiave in seguito per il backup o per condividerla con gli altri nodi in un DAG.

Su Exchange Server Subscription Edition ed Exchange 2019 CU15, la procedura guidata per i certificati dell’EAC in Servers > Certificates è nuovamente disponibile come flusso GUI alternativo. La guida completa passo per passo (PowerShell più la procedura guidata dell’EAC, con note per ogni versione) si trova nella nostra guida correlata CSR per Microsoft Exchange. Usa quella pagina per il flusso canonico della CSR per Exchange ibrido; la stessa CSR funziona per il certificato che assegnerai ai servizi Exchange on-prem che si connettono a Microsoft 365.

Dopo l’esecuzione del cmdlet, apri il file .req in Blocco note e verifica che assomigli a un normale blocco PEM:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIC6TCCAdECAQAwgaMxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
...
-----END NEW CERTIFICATE REQUEST-----

Copia l’intero blocco, comprese le righe BEGIN ed END (cinque trattini su ciascun lato), e incollalo nel campo CSR del tuo ordine SSL. Decodificalo prima con il nostro CSR Decoder per confermare il common name, i SAN e la lunghezza della chiave prima di inviarlo.

Genera la CSR per la federazione AD FS / Entra ID con Microsoft 365

Se utilizzi AD FS (Active Directory Federation Services) per federare l’accesso tra il tuo Active Directory on-prem e Microsoft Entra ID (precedentemente Azure AD) per il single sign-on di Microsoft 365, il servizio AD FS ha bisogno di un certificato TLS pubblicamente attendibile per il nome del suo servizio di federazione (ad esempio sts.example.com). Quel certificato è associato al servizio AD FS e all’eventuale Web Application Proxy davanti ad esso.

La CSR viene generata sul server AD FS (o su qualsiasi server Windows) utilizzando lo snap-in dei certificati della Microsoft Management Console o PowerShell, quindi inviata a una CA pubblica. Genera la CSR con il nostro CSR Generator (poi combina in seguito il certificato emesso e la chiave in un file .pfx), oppure segui la nostra guida CSR per Windows per produrre la richiesta direttamente sul server. Lo stesso certificato viene quindi assegnato al servizio AD FS con Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumb>.

I certificati per la firma e la decrittazione dei token all’interno di AD FS sono un argomento separato. Di solito sono autofirmati e rinnovati automaticamente dallo stesso AD FS, quindi non è necessario generare una CSR per questi.

Genera la CSR per un’Azure App Service che si integra con Microsoft 365

Se ospiti una web app, una funzione o un’API su Azure App Service che si connette a Microsoft 365 (un portale personalizzato, un endpoint SSO, un ricevitore di webhook), proteggi il suo dominio personalizzato con un certificato che carichi su Azure. Azure App Service non genera CSR autonomamente: generi la richiesta al di fuori di Azure e carichi il file .pfx risultante.

Il percorso più semplice è il nostro CSR Generator: inserisci i tuoi dati, scarica la CSR e la chiave privata corrispondente, invia la CSR alla CA, quindi combina il certificato emesso, gli intermedi e la chiave privata in un file .pfx (PKCS#12). Carica quel file .pfx in App Service > Certificates > Bring your own certificates (.pfx) e associalo al tuo dominio personalizzato. Se preferisci un flusso interamente gestito da server, genera la CSR su una postazione di amministrazione Windows utilizzando la nostra guida CSR per Windows ed esporta il risultato in un file .pfx prima di caricarlo. Azure richiede che il certificato includa l’Extended Key Usage Server Authentication (OID 1.3.6.1.5.5.7.3.1), cosa che ogni certificato SSL commerciale già fa.

Genera la CSR su un server Windows / IIS autonomo

Se per “Office 365” nel tuo caso intendi in realtà “un server Windows che esegue IIS nello stesso ambiente di Microsoft 365” (ad esempio un portale, un sito intranet o un relay non Exchange), allora generi la CSR in IIS Manager su quel server. Questo è il percorso descritto nel tutorial originale. È il flusso corretto per un host IIS generico, ma non produce un certificato per il cloud Microsoft 365, bensì solo per il sito ospitato su IIS che stai gestendo.

1. Apri Start > Strumenti di amministrazione Windows > Gestione Internet Information Services (IIS), oppure premi Win + R, digita inetmgr e premi Invio.
2. Nel pannello Connessioni a sinistra, seleziona il tuo nome server.
3. Nel riquadro centrale, fai doppio clic su Certificati del server.
4. Nel pannello Azioni a destra, fai clic su Crea richiesta certificato.
5. Nella procedura guidata Richiedi certificato, compila i campi Proprietà nome distinto come segue:
   • Nome comune: il nome di dominio completamente qualificato che vuoi proteggere, ad esempio portal.example.com. Non inserire outlook.office365.com o qualsiasi altro hostname di proprietà Microsoft.
   • Organizzazione: la ragione sociale completa della tua azienda (ad esempio Example Inc.).
   • Unità organizzativa: il reparto, spesso IT.
   • Città/località: la città in cui è registrata la tua azienda (non abbreviare).
   • Stato/provincia: il nome completo dello stato o della provincia (non abbreviare).
   • Paese/regione: il codice paese ISO a due lettere (US, GB, DE, e così via).
6. Fai clic su Avanti.
7. Nella schermata Proprietà provider di servizi crittografici, lascia il provider su Microsoft RSA SChannel Cryptographic Provider, imposta la Lunghezza bit su 2048 (o 3072 / 4096 se richiesto dalla tua policy), quindi fai clic su Avanti.
8. Specifica un nome file per la CSR (ad esempio C:certsportal.req) e fai clic su Fine.

IIS non genera Subject Alternative Name tramite questa procedura guidata. Per un certificato SAN o multi-dominio, genera la CSR con PowerShell utilizzando un file INF personalizzato con certreq, oppure utilizza il nostro CSR Generator e in seguito combina il certificato emesso e la chiave in un file .pfx per l’importazione. Per il flusso completo specifico per IIS con screenshot, consulta la nostra guida CSR per Microsoft IIS.

Apri il file .req salvato in Blocco note e copia l’intero blocco, comprese le righe -----BEGIN NEW CERTIFICATE REQUEST----- e -----END NEW CERTIFICATE REQUEST-----, nel modulo d’ordine della tua CA.

Verifica la tua CSR prima di inviarla

Prima di incollare la CSR nel modulo d’ordine, decodificala per confermare che i dettagli siano corretti. Un errore di battitura nel common name, un SAN mancante o una lunghezza della chiave troppo breve faranno rifiutare l’ordine o costringeranno a una riemissione in seguito. Incolla la CSR nel nostro CSR Decoder per vedere il common name, l’elenco completo dei SAN, l’organizzazione, il paese, l’algoritmo di firma e la lunghezza della chiave.

Una volta che la CA convalida la richiesta ed emette il certificato, continua con la nostra guida all’installazione SSL per Microsoft 365 per il passaggio di installazione corrispondente (importazione in Exchange ibrido, associazione AD FS, caricamento su Azure App Service o associazione IIS).