Como Gerar um CSR no Office 365

Este guia explica como gerar uma CSR (Certificate Signing Request) para o Microsoft 365 (Office 365). A resposta honesta, antes de mais nada: você não gera uma CSR para a nuvem do Microsoft 365 em si. O Microsoft 365 é uma plataforma SaaS hospedada, portanto a Microsoft possui e gerencia os certificados TLS em outlook.office365.com, nos endpoints de e-mail *.mail.protection.outlook.com, *.sharepoint.com e nos demais serviços hospedados pela Microsoft. Não existe uma página no portal que aceite um certificado fornecido pelo cliente para essas URLs.

Uma CSR entra em cena apenas quando você também opera um servidor local (on-premises) ou hospedado na nuvem que se integra ao Microsoft 365. A CSR é gerada nesse servidor, não no portal de administração do Microsoft 365. As seções abaixo abordam os cenários em que isso realmente acontece.

Em qual cenário você está?

Escolha a linha que corresponde ao que você realmente está tentando proteger e vá para a seção correspondente:

O que você está tentando proteger	Onde a CSR é gerada	Seção
Os próprios serviços em nuvem do Microsoft 365 (Exchange Online, SharePoint Online, Teams, outlook.office365.com)	Em lugar nenhum. A Microsoft gerencia esses certificados.	Por que não há CSR para a nuvem
Um servidor Exchange local em uma configuração híbrida com o Exchange Online	No servidor Exchange local (PowerShell, ou o EAC nas versões suportadas)	CSR para Exchange híbrido
Um servidor AD FS que federaliza o login com Microsoft 365 / Entra ID	No servidor AD FS (solicitação de certificado do Windows)	CSR para federação AD FS / Entra
Um aplicativo web, função ou API do Azure App Service que se conecta ao Microsoft 365	Gerada externamente (qualquer ferramenta) e depois enviada ao Azure	CSR para Azure App Service
Um servidor web Windows independente (IIS) que não é o Exchange, mas que se integra ao Microsoft 365 (por exemplo, um portal, receptor de hooks ou relay)	No Gerenciador do IIS nesse servidor	CSR para servidor IIS independente

Por que não existe CSR para a nuvem do Microsoft 365

O Microsoft 365 é uma plataforma em nuvem totalmente hospedada e multilocatária. Os certificados TLS do Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams e de todos os demais endpoints hospedados pela Microsoft são emitidos, implantados e renovados pela Microsoft. Não existe uma página no centro de administração, um cmdlet do PowerShell ou uma API que permita a um locatário enviar um certificado de terceiros para outlook.office365.com, para os endpoints de fluxo de e-mail *.mail.protection.outlook.com, ou para qualquer outro nome de host pertencente à Microsoft. Isso inclui o caso em que você adicionou seu próprio domínio personalizado, como contoso.com: uma vez verificado o domínio, a Microsoft continua a encerrar a conexão TLS nos endpoints subjacentes de SMTP, IMAP, POP e HTTPS, portanto nenhuma CSR é necessária do seu lado.

Se o seu objetivo é impor TLS no fluxo de e-mail entre o Microsoft 365 e um parceiro externo, isso é feito com um conector do Exchange Online que exige que o parceiro apresente um certificado público válido. Nenhum certificado é enviado do seu lado. Consulte nosso guia de instalação de SSL do Microsoft 365 para as etapas do conector.

Gerar a CSR para o Exchange híbrido (Exchange Server local)

Se você já gerou sua CSR no seu servidor Exchange local, avance diretamente para o guia de instalação de SSL do Microsoft 365 / Exchange. Caso contrário, este é o motivo mais comum pelo qual os clientes pedem uma “CSR do Microsoft 365”. Em uma implantação híbrida, seu Exchange Server local (2016, 2019 ou Subscription Edition) se comunica com o Exchange Online por OAuth, EWS e Autodiscover, e essas conexões precisam ser protegidas com um certificado publicamente confiável. Você gera a CSR no servidor Exchange local, não em nada dentro do Microsoft 365.

Em todas as versões do Exchange suportadas (e como o único caminho suportado no Exchange 2016 CU23+ e no Exchange 2019 CU12 a CU14, onde a Microsoft removeu as opções de certificado do EAC), a CSR é gerada com o PowerShell. Execute o Exchange Management Shell como administrador no servidor que armazenará a chave privada e, em seguida, execute:

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"

O uso em duas etapas (a saída do cmdlet redirecionada para Set-Content) é obrigatório nas versões atuais: a atualização de segurança KB5014278 removeu o parâmetro antigo -RequestFile de New-ExchangeCertificate no Exchange 2016 CU23 e no Exchange 2019 CU12. Edite os valores para corresponder ao seu ambiente:

• C é o código de país de duas letras (US, GB, DE, e assim por diante).
• S é o nome completo do estado ou província, e não a abreviação.
• L é a cidade ou localidade completa.
• O é o nome da empresa legalmente registrado.
• OU é o departamento, geralmente “TI”. Opcional.
• CN é o nome de host totalmente qualificado principal que o certificado protegerá, por exemplo mail.example.com.
• -DomainName é a lista de Subject Alternative Name (SAN) separada por vírgulas. Para uma implantação híbrida, inclua pelo menos mail.example.com e autodiscover.example.com, além de quaisquer outros namespaces que você utilize (OWA, EWS, nomes de host híbridos).
• -KeySize 2048 corresponde aos requisitos básicos do CA/Browser Forum. Use 4096 apenas se sua política de segurança exigir. A Microsoft documenta apenas 1024, 2048 e 4096 como valores válidos para -KeySize, portanto não use 3072 aqui.
• -PrivateKeyExportable $true permite exportar a chave posteriormente para backup ou para compartilhar com os outros nós de um DAG.

No Exchange Server Subscription Edition e no Exchange 2019 CU15, o assistente de certificado do EAC em Servidores > Certificados está disponível novamente como um fluxo alternativo com interface gráfica. O passo a passo completo (PowerShell mais o assistente do EAC, com notas específicas por versão) está em nosso guia complementar de CSR do Microsoft Exchange. Use essa página para o fluxo canônico de CSR do Exchange híbrido; a mesma CSR funciona para o certificado que você atribuirá aos serviços do Exchange local que se conectam ao Microsoft 365.

Depois que o cmdlet for executado, abra o arquivo .req no Bloco de Notas e confirme que ele se parece com um bloco PEM normal:

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

Copie o bloco inteiro, incluindo as linhas BEGIN e END (cinco hifens de cada lado), e cole-o no campo de CSR do seu pedido de SSL. Decodifique-o primeiro com nosso Decodificador de CSR para confirmar o nome comum, os SANs e o tamanho da chave antes de enviar.

Gerar a CSR para federação AD FS / Entra ID com o Microsoft 365

Se você usa o AD FS (Active Directory Federation Services) para federar o login entre seu Active Directory local e o Microsoft Entra ID (antigo Azure AD) para o login único (SSO) do Microsoft 365, o serviço AD FS precisa de um certificado TLS publicamente confiável para o nome do seu serviço de federação (por exemplo sts.example.com). Esse certificado é vinculado ao serviço AD FS e ao Web Application Proxy opcional que fica na frente dele.

A CSR é gerada no servidor AD FS (ou em qualquer servidor Windows) usando o snap-in de certificados do Microsoft Management Console ou o PowerShell, e depois enviada a uma CA pública. Você pode gerar a CSR com nosso Gerador de CSR (e depois combinar o certificado emitido e a chave em um arquivo .pfx), ou seguir nosso guia de CSR para Windows para gerar a solicitação diretamente no servidor. O mesmo certificado é então atribuído ao serviço AD FS com Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumb>.

Os certificados de assinatura de token e de decriptação de token dentro do AD FS são um assunto separado. Eles geralmente são autoassinados e renovados automaticamente pelo próprio AD FS, portanto você não gera uma CSR para eles.

Gerar a CSR para um Azure App Service que se integra ao Microsoft 365

Se você hospeda um aplicativo web, uma função ou uma API no Azure App Service que se conecta ao Microsoft 365 (um portal personalizado, um endpoint de SSO, um receptor de webhook), você protege seu domínio personalizado com um certificado que você envia ao Azure. O Azure App Service não gera CSRs por conta própria: você gera a solicitação fora do Azure e envia o arquivo .pfx resultante.

O caminho mais simples é nosso Gerador de CSR: insira seus dados, baixe a CSR e a chave privada correspondente, envie a CSR para a CA e depois combine o certificado emitido, os intermediários e a chave privada em um arquivo .pfx (PKCS#12). Envie esse .pfx em App Service > Certificates > Bring your own certificates (.pfx) e vincule-o ao seu domínio personalizado. Se preferir um fluxo totalmente gerenciado pelo servidor, gere a CSR em uma estação de trabalho Windows administrativa usando nosso guia de CSR para Windows e exporte o resultado para um arquivo .pfx antes de fazer o upload. O Azure exige que o certificado inclua o Extended Key Usage Server Authentication (OID 1.3.6.1.5.5.7.3.1), o que todo certificado SSL comercial já contempla.

Gerar a CSR em um servidor Windows / IIS independente

Se “Office 365” no seu caso na verdade significa “um servidor Windows executando o IIS no mesmo ambiente do Microsoft 365” (por exemplo, um portal, um site de intranet ou um relay que não é o Exchange), então você gera a CSR no Gerenciador do IIS nesse servidor. Este é o caminho descrito no tutorial original. É o fluxo correto para um host IIS genérico, mas não produz um certificado para a nuvem do Microsoft 365, apenas para o site hospedado no IIS que você está gerenciando.

1. Abra Iniciar > Ferramentas Administrativas do Windows > Gerenciador do IIS (Internet Information Services), ou pressione Win + R, digite inetmgr e pressione Enter.
2. No painel Connections, à esquerda, selecione o nome do seu servidor.
3. No painel central, clique duas vezes em Server Certificates.
4. No painel Actions, à direita, clique em Create Certificate Request.
5. No assistente Request Certificate, preencha os campos de Distinguished Name Properties da seguinte forma:
   • Common Name: o nome de domínio totalmente qualificado que você deseja proteger, por exemplo portal.example.com. Não insira outlook.office365.com ou qualquer outro nome de host pertencente à Microsoft.
   • Organization: o nome legal completo da sua empresa (por exemplo Example Inc.).
   • Organizational unit: o departamento, geralmente TI.
   • City/locality: a cidade onde sua empresa está registrada (não abrevie).
   • State/province: o nome completo do estado ou província (não abrevie).
   • Country/region: o código de país ISO de duas letras (US, GB, DE, e assim por diante).
6. Clique em Next.
7. Na tela Cryptographic Service Provider Properties, deixe o provedor como Microsoft RSA SChannel Cryptographic Provider, defina Bit length como 2048 (ou 3072/4096 se sua política exigir), e clique em Next.
8. Especifique um nome de arquivo para a CSR (por exemplo, C:certsportal.req) e clique em Finish.

O IIS não gera Subject Alternative Names por meio desse assistente. Para um certificado SAN ou multidomínio, gere a CSR com o PowerShell usando um arquivo INF personalizado com certreq, ou use nosso Gerador de CSR e depois combine o certificado emitido e a chave em um arquivo .pfx para importação. Para o fluxo completo específico do IIS, com capturas de tela, consulte nosso guia de CSR do Microsoft IIS.

Abra o arquivo .req salvo no Bloco de Notas e copie o bloco completo, incluindo as linhas -----BEGIN NEW CERTIFICATE REQUEST----- e -----END NEW CERTIFICATE REQUEST-----, no formulário de pedido da sua CA.

Verifique sua CSR antes de enviar

Antes de colar a CSR no formulário de pedido, decodifique-a para confirmar que os detalhes estão corretos. Um erro de digitação no nome comum, um SAN ausente ou um tamanho de chave curto rejeitará o pedido ou forçará uma reemissão posteriormente. Cole a CSR em nosso Decodificador de CSR para ver o nome comum, a lista completa de SANs, a organização, o país, o algoritmo de assinatura e o tamanho da chave.

Depois que a CA validar a solicitação e emitir o certificado, continue com nosso guia de instalação de SSL do Microsoft 365 para a etapa de instalação correspondente (importação no Exchange híbrido, vinculação no AD FS, envio no Azure App Service, ou vinculação no IIS).