Cum să generați un CSR pe Office 365

Acest ghid explică cum să generați un CSR (Certificate Signing Request) pentru Microsoft 365 (Office 365). Răspunsul sincer, mai întâi: nu generați un CSR pentru platforma cloud Microsoft 365 în sine. Microsoft 365 este o platformă SaaS găzduită, astfel încât Microsoft deține și gestionează certificatele TLS pe outlook.office365.com, punctele de acces de e-mail *.mail.protection.outlook.com, *.sharepoint.com și celelalte servicii găzduite de Microsoft. Nu există nicio pagină de portal care să accepte un certificat furnizat de client pentru aceste URL-uri.

Un CSR intervine doar atunci când operați și un server local sau găzduit în cloud care se integrează cu Microsoft 365. CSR-ul este generat pe acel server, nu în portalul de administrare Microsoft 365. Secțiunile de mai jos acoperă scenariile în care acest lucru se întâmplă efectiv.

În care scenariu vă aflați?

Alegeți rândul care corespunde cu ceea ce încercați de fapt să securizați, apoi accesați secțiunea corespunzătoare:

Ce încercați să securizați	Unde este generat CSR-ul	Secțiune
Serviciile cloud Microsoft 365 în sine (Exchange Online, SharePoint Online, Teams, outlook.office365.com)	Nicăieri. Microsoft gestionează aceste certificate.	De ce nu există CSR pentru cloud
Un server Exchange local, într-o configurație hibridă cu Exchange Online	Pe serverul Exchange local (PowerShell sau EAC pe build-urile compatibile)	CSR pentru Exchange hibrid
Un server AD FS care federalizează autentificarea cu Microsoft 365 / Entra ID	Pe serverul AD FS (cerere de certificat Windows)	CSR pentru federarea AD FS / Entra
O aplicație web Azure App Service, o funcție sau un API care se conectează la Microsoft 365	Generat extern (orice instrument), apoi încărcat în Azure	CSR pentru Azure App Service
Un server web Windows independent (IIS) care nu este Exchange, dar se integrează cu Microsoft 365 (de exemplu un portal, un receptor de hook-uri sau un releu)	În IIS Manager, pe acel server	CSR pentru server IIS independent

De ce nu există CSR pentru cloud-ul Microsoft 365

Microsoft 365 este o platformă cloud complet găzduită, cu mai mulți chiriași (multi-tenant). Certificatele TLS pentru Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams și orice alt punct final găzduit de Microsoft sunt emise, implementate și reînnoite de Microsoft. Nu există nicio pagină în centrul de administrare, niciun cmdlet PowerShell sau API care să permită unui chiriaș să încarce un certificat terț pe outlook.office365.com, pe punctele finale de flux de e-mail *.mail.protection.outlook.com sau pe orice alt nume de gazdă deținut de Microsoft. Acest lucru se aplică și în cazul în care ați adăugat propriul domeniu personalizat, cum ar fi contoso.com: odată ce domeniul este verificat, Microsoft continuă să termine TLS pentru punctele finale SMTP, IMAP, POP și HTTPS subiacente, astfel încât nu este necesar niciun CSR din partea dumneavoastră.

Dacă scopul dumneavoastră este să impuneți TLS pentru fluxul de e-mail dintre Microsoft 365 și un partener extern, faceți acest lucru printr-un conector Exchange Online care solicită partenerului să prezinte un certificat public valid. Niciun certificat nu este încărcat din partea dumneavoastră. Consultați ghidul nostru de instalare SSL pentru Microsoft 365 pentru pașii de configurare a conectorului.

Generați CSR-ul pentru Exchange hibrid (Exchange Server local)

Dacă ați generat deja CSR-ul pe serverul dumneavoastră Exchange local, treceți direct la ghidul de instalare SSL pentru Microsoft 365 / Exchange. În caz contrar, acesta este cel mai frecvent motiv pentru care clienții solicită un „CSR Microsoft 365″. Într-o implementare hibridă, serverul dumneavoastră Exchange local (2016, 2019 sau Subscription Edition) comunică cu Exchange Online prin OAuth, EWS și Autodiscover, iar aceste conexiuni trebuie securizate cu un certificat de încredere publică. Generați CSR-ul pe serverul Exchange local, nu pe nimic din Microsoft 365.

Pe fiecare build Exchange compatibil (și ca singura cale acceptată pe Exchange 2016 CU23+ și Exchange 2019 CU12 până la CU14, unde Microsoft a eliminat opțiunile de certificate din EAC), CSR-ul este generat cu PowerShell. Rulați Exchange Management Shell ca administrator pe serverul care va deține cheia privată, apoi rulați:

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"

Utilizarea în doi pași (rezultatul cmdlet-ului direcționat către Set-Content) este necesară pe build-urile actuale: actualizarea de securitate KB5014278 a eliminat vechiul parametru -RequestFile din New-ExchangeCertificate pe Exchange 2016 CU23 și Exchange 2019 CU12. Editați valorile pentru a se potrivi cu mediul dumneavoastră:

• C este codul de țară din două litere (US, GB, DE și așa mai departe).
• S este numele complet al statului sau provinciei, nu abrevierea.
• L este orașul sau localitatea completă.
• O este numele companiei înregistrate legal.
• OU este departamentul, adesea „IT”. Opțional.
• CN este numele principal de gazdă complet calificat pe care certificatul îl va securiza, de exemplu mail.example.com.
• -DomainName este lista de nume alternative de subiect (SAN), separate prin virgulă. Pentru o implementare hibridă, includeți cel puțin mail.example.com și autodiscover.example.com, plus orice alte spații de nume suplimentare pe care le utilizați (OWA, EWS, nume de gazdă hibride).
• -KeySize 2048 corespunde cerințelor de bază ale CA/Browser Forum. Utilizați 4096 doar dacă politica dumneavoastră de securitate o impune. Microsoft documentează doar 1024, 2048 și 4096 ca valori valide pentru -KeySize, deci nu utilizați 3072 aici.
• -PrivateKeyExportable $true vă permite să exportați ulterior cheia pentru backup sau pentru a o partaja cu celelalte noduri dintr-un DAG.

Pe Exchange Server Subscription Edition și Exchange 2019 CU15, expertul de certificate EAC din Servers > Certificates este din nou disponibil ca flux alternativ prin interfață grafică. Ghidul complet, pas cu pas (PowerShell plus expertul EAC, cu note pentru fiecare versiune), se află pe ghidul nostru asociat Ghidul CSR pentru Microsoft Exchange. Folosiți acea pagină pentru fluxul canonic de CSR pentru Exchange hibrid; același CSR funcționează pentru certificatul pe care îl veți atribui serviciilor Exchange locale care se conectează la Microsoft 365.

După ce cmdlet-ul rulează, deschideți fișierul .req în Notepad și confirmați că arată ca un bloc PEM normal:

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

Copiați întregul bloc, inclusiv liniile BEGIN și END (cinci cratime pe fiecare parte), și lipiți-l în câmpul CSR al comenzii SSL. Decodați-l mai întâi cu Decodorul nostru CSR pentru a confirma numele comun, SAN-urile și dimensiunea cheii înainte de a-l trimite.

Generați CSR-ul pentru federarea AD FS / Entra ID cu Microsoft 365

Dacă utilizați AD FS (Active Directory Federation Services) pentru a federaliza autentificarea între Active Directory local și Microsoft Entra ID (fostul Azure AD) pentru autentificarea unică (single sign-on) Microsoft 365, serviciul AD FS are nevoie de un certificat TLS de încredere publică pentru numele serviciului de federare (de exemplu sts.example.com). Acel certificat este asociat serviciului AD FS și, opțional, Web Application Proxy-ului din fața acestuia.

CSR-ul este generat pe serverul AD FS (sau pe orice server Windows) folosind snap-in-ul de certificate din Microsoft Management Console sau PowerShell, apoi este trimis către o CA publică. Fie generați CSR-ul cu Generatorul nostru de CSR (apoi combinați ulterior certificatul emis și cheia într-un fișier .pfx), fie urmați ghidul nostru CSR pentru Windows pentru a produce cererea direct pe server. Același certificat este apoi atribuit serviciului AD FS cu Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumb>.

Certificatele de semnare a token-urilor și de decriptare a token-urilor din AD FS reprezintă un subiect separat. De obicei sunt autosemnate și reînnoite automat de AD FS însuși, deci nu generați un CSR pentru acestea.

Generați CSR-ul pentru o aplicație Azure App Service care se integrează cu Microsoft 365

Dacă găzduiți o aplicație web, o funcție sau un API pe Azure App Service care se conectează la Microsoft 365 (un portal personalizat, un punct final SSO, un receptor de webhook-uri), securizați domeniul personalizat al acesteia cu un certificat pe care îl încărcați în Azure. Azure App Service nu generează CSR-uri singur: generați cererea în afara Azure și încărcați fișierul .pfx rezultat.

Calea cea mai simplă este Generatorul nostru de CSR: introduceți detaliile, descărcați CSR-ul și cheia privată corespunzătoare, trimiteți CSR-ul către CA, apoi combinați certificatul emis, certificatele intermediare și cheia privată într-un fișier .pfx (PKCS#12). Încărcați acel .pfx în App Service > Certificates > Bring your own certificates (.pfx) și asociați-l domeniului personalizat. Dacă preferați un flux complet gestionat de server, generați CSR-ul pe o stație de lucru de administrare Windows folosind ghidul nostru CSR pentru Windows și exportați rezultatul într-un fișier .pfx înainte de a-l încărca. Azure necesită ca certificatul să includă Extended Key Usage Server Authentication (OID 1.3.6.1.5.5.7.3.1), lucru pe care orice certificat SSL comercial îl face deja.

Generați CSR-ul pe un server Windows / IIS independent

Dacă „Office 365″ înseamnă în cazul dumneavoastră de fapt „un server Windows care rulează IIS în același mediu cu Microsoft 365″ (de exemplu un portal, un site intranet sau un releu care nu este Exchange), atunci generați CSR-ul în IIS Manager pe acel server. Aceasta este calea descrisă în tutorialul original. Este fluxul potrivit pentru o gazdă IIS generică, dar nu produce un certificat pentru cloud-ul Microsoft 365, ci doar pentru orice site găzduit pe IIS pe care îl gestionați.

1. Deschideți Start > Windows Administrative Tools > Internet Information Services (IIS) Manager, sau apăsați Win + R, tastați inetmgr și apăsați Enter.
2. În panoul Connections din stânga, selectați numele serverului dumneavoastră.
3. În panoul central, faceți dublu clic pe Server Certificates.
4. În panoul Actions din dreapta, faceți clic pe Create Certificate Request.
5. În expertul Request Certificate, completați câmpurile Distinguished Name Properties după cum urmează:
   • Common Name: numele de domeniu complet calificat pe care doriți să îl securizați, de exemplu portal.example.com. Nu introduceți outlook.office365.com sau orice alt nume de gazdă deținut de Microsoft.
   • Organization: numele legal complet al companiei dumneavoastră (de exemplu Example Inc.).
   • Organizational unit: departamentul, adesea IT.
   • City/locality: orașul în care este înregistrată compania dumneavoastră (nu abreviați).
   • State/province: numele complet al statului sau provinciei (nu abreviați).
   • Country/region: codul de țară ISO din două litere (US, GB, DE și așa mai departe).
6. Faceți clic pe Next.
7. Pe ecranul Cryptographic Service Provider Properties, lăsați furnizorul la Microsoft RSA SChannel Cryptographic Provider, setați Bit length la 2048 (sau 3072 / 4096 dacă politica dumneavoastră o cere), apoi faceți clic pe Next.
8. Specificați un nume de fișier pentru CSR (de exemplu C:certsportal.req) și faceți clic pe Finish.

IIS nu generează nume alternative de subiect (SAN) prin acest expert. Pentru un certificat SAN sau multi-domeniu, generați CSR-ul cu PowerShell folosind un fișier INF personalizat cu certreq, sau folosiți Generatorul nostru de CSR și combinați ulterior certificatul emis și cheia într-un fișier .pfx pentru import. Pentru fluxul complet specific IIS, cu capturi de ecran, consultați ghidul nostru CSR pentru Microsoft IIS.

Deschideți fișierul .req salvat în Notepad și copiați întregul bloc, inclusiv liniile -----BEGIN NEW CERTIFICATE REQUEST----- și -----END NEW CERTIFICATE REQUEST-----, în formularul de comandă al CA-ului dumneavoastră.

Verificați CSR-ul înainte de a-l trimite

Înainte de a lipi CSR-ul în formularul de comandă, decodați-l pentru a confirma că detaliile sunt corecte. O greșeală de tastare în numele comun, un SAN lipsă sau o lungime de cheie prea mică vor duce la respingerea comenzii sau vor forța o reemitere ulterioară. Lipiți CSR-ul în Decodorul nostru CSR pentru a vedea numele comun, lista completă de SAN-uri, organizația, țara, algoritmul de semnătură și dimensiunea cheii.

Odată ce CA validează cererea și emite certificatul, continuați cu ghidul nostru de instalare SSL pentru Microsoft 365 pentru pasul de instalare corespunzător (import Exchange hibrid, asociere AD FS, încărcare Azure App Service sau asociere IIS).