Cómo generar un CSR en Office 365

Esta guía explica cómo generar una CSR (Certificate Signing Request) para Microsoft 365 (Office 365). La respuesta honesta primero: no se genera una CSR para la nube de Microsoft 365 en sí. Microsoft 365 es una plataforma SaaS alojada, por lo que Microsoft posee y gestiona los certificados TLS en outlook.office365.com, los puntos de conexión de correo *.mail.protection.outlook.com, *.sharepoint.com, y los demás servicios alojados por Microsoft. No existe ninguna página del portal que acepte un certificado proporcionado por el cliente para esas URL.

Una CSR entra en juego solo cuando también se ejecuta un servidor local (on-premises) o alojado en la nube que se integra con Microsoft 365. La CSR se genera en ese servidor, no en el portal de administración de Microsoft 365. Las secciones siguientes cubren los escenarios en los que esto realmente ocurre.

¿En qué escenario te encuentras?

Elige la fila que coincida con lo que realmente intentas proteger y luego ve a la sección correspondiente:

Qué intentas proteger	Dónde se genera la CSR	Sección
Los propios servicios en la nube de Microsoft 365 (Exchange Online, SharePoint Online, Teams, outlook.office365.com)	En ningún sitio. Microsoft gestiona esos certificados.	Por qué no hay CSR para la nube
Un servidor Exchange local en una configuración híbrida con Exchange Online	En el servidor Exchange local (PowerShell, o el EAC en versiones compatibles)	CSR de Exchange híbrido
Un servidor AD FS que federa el inicio de sesión con Microsoft 365 / Entra ID	En el servidor AD FS (solicitud de certificado de Windows)	CSR de federación AD FS / Entra
Una aplicación web, función o API de Azure App Service que se conecta con Microsoft 365	Generada externamente (con cualquier herramienta), luego subida a Azure	CSR de Azure App Service
Un servidor web Windows independiente (IIS) que no es Exchange, pero que se integra con Microsoft 365 (por ejemplo, un portal, un receptor de webhooks o un relay)	En el Administrador de IIS de ese servidor	CSR de servidor IIS independiente

Por qué no hay CSR para la nube de Microsoft 365

Microsoft 365 es una plataforma en la nube totalmente alojada y multiinquilino (multi-tenant). Los certificados TLS de Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams y cualquier otro punto de conexión alojado por Microsoft son emitidos, implementados y renovados por Microsoft. No existe ninguna página del centro de administración, cmdlet de PowerShell ni API que permita a un inquilino subir un certificado de terceros a outlook.office365.com, a los puntos de conexión de flujo de correo *.mail.protection.outlook.com, ni a ningún otro nombre de host propiedad de Microsoft. Esto incluye el caso en que hayas añadido tu propio dominio personalizado (vanity domain), como contoso.com: una vez verificado el dominio, Microsoft sigue terminando el TLS de los puntos de conexión SMTP, IMAP, POP y HTTPS subyacentes, por lo que no necesitas ninguna CSR por tu parte.

Si tu objetivo es forzar el TLS en el flujo de correo entre Microsoft 365 y un socio externo, lo consigues mediante un conector de Exchange Online que exige que el socio presente un certificado público válido. No se sube ningún certificado por tu parte. Consulta nuestra guía de instalación de SSL en Microsoft 365 para conocer los pasos del conector.

Generar la CSR para Exchange híbrido (Exchange Server local)

Si ya has generado tu CSR en tu servidor Exchange local, pasa directamente a la guía de instalación de SSL de Microsoft 365 / Exchange. En caso contrario, este es el motivo más común por el que los clientes piden una «CSR de Microsoft 365». En una implementación híbrida, tu servidor Exchange local (2016, 2019 o Subscription Edition) se comunica con Exchange Online mediante OAuth, EWS y Autodiscover, y esas conexiones deben protegerse con un certificado de confianza pública. La CSR se genera en el servidor Exchange local, no en nada de Microsoft 365.

En todas las versiones compatibles de Exchange (y como única ruta compatible en Exchange 2016 CU23+ y Exchange 2019 CU12 a CU14, donde Microsoft eliminó las opciones de certificado del EAC), la CSR se genera con PowerShell. Ejecuta Exchange Management Shell como administrador en el servidor que albergará la clave privada, y luego ejecuta:

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"

El uso en dos pasos (la salida del cmdlet redirigida a Set-Content) es obligatorio en las versiones actuales: la actualización de seguridad KB5014278 eliminó el antiguo parámetro -RequestFile de New-ExchangeCertificate en Exchange 2016 CU23 y Exchange 2019 CU12. Edita los valores para que coincidan con tu entorno:

• C es el código de país de dos letras (US, GB, DE, etc.).
• S es el nombre completo del estado o provincia, no la abreviatura.
• L es la ciudad o localidad completa.
• O es el nombre de la empresa legalmente registrado.
• OU es el departamento, a menudo «IT». Opcional.
• CN es el nombre de host completamente cualificado principal que protegerá el certificado, por ejemplo mail.example.com.
• -DomainName es la lista de nombres alternativos del sujeto (SAN) separados por comas. Para una implementación híbrida, incluye al menos mail.example.com y autodiscover.example.com, además de cualquier otro espacio de nombres que utilices (OWA, EWS, nombres de host híbridos).
• -KeySize 2048 cumple con los requisitos básicos del CA/Browser Forum. Usa 4096 solo si tu política de seguridad lo exige. Microsoft solo documenta 1024, 2048 y 4096 como valores válidos para -KeySize, así que no uses 3072 aquí.
• -PrivateKeyExportable $true te permite exportar la clave más adelante para hacer una copia de seguridad o compartirla con los demás nodos de un DAG.

En Exchange Server Subscription Edition y Exchange 2019 CU15, el asistente de certificados del EAC en Servidores > Certificados vuelve a estar disponible como flujo alternativo con interfaz gráfica. El paso a paso completo (PowerShell más el asistente del EAC, con notas por versión) está en nuestra guía complementaria CSR de Microsoft Exchange. Usa esa página para el flujo canónico de CSR de Exchange híbrido; la misma CSR sirve para el certificado que asignarás a los servicios de Exchange locales que se conectan con Microsoft 365.

Después de ejecutar el cmdlet, abre el archivo .req en el Bloc de notas y confirma que tiene el aspecto de un bloque PEM normal:

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

Copia todo el bloque, incluidas las líneas BEGIN y END (cinco guiones a cada lado), y pégalo en el campo CSR de tu pedido de SSL. Decodifícalo primero con nuestro Decodificador de CSR para confirmar el nombre común, los SAN y el tamaño de la clave antes de enviarlo.

Generar la CSR para la federación AD FS / Entra ID con Microsoft 365

Si utilizas AD FS (Active Directory Federation Services) para federar el inicio de sesión entre tu Active Directory local y Microsoft Entra ID (antes Azure AD) para el inicio de sesión único de Microsoft 365, el servicio AD FS necesita un certificado TLS de confianza pública para el nombre de su servicio de federación (por ejemplo, sts.example.com). Ese certificado está vinculado al servicio AD FS y al Web Application Proxy opcional que lo antecede.

La CSR se genera en el servidor AD FS (o en cualquier servidor Windows) mediante el complemento de certificados de la Microsoft Management Console o PowerShell, y luego se envía a una CA pública. Puedes generar la CSR con nuestro Generador de CSR (y más tarde combinar el certificado emitido y la clave en un archivo .pfx), o seguir nuestra guía de CSR para Windows para generar la solicitud directamente en el servidor. El mismo certificado se asigna después al servicio AD FS con Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumb>.

Los certificados de firma de token y de descifrado de token dentro de AD FS son un tema aparte. Normalmente son autofirmados y se renuevan automáticamente por el propio AD FS, así que no se genera ninguna CSR para ellos.

Generar la CSR para un Azure App Service que se integra con Microsoft 365

Si alojas una aplicación web, una función o una API en Azure App Service que se conecta con Microsoft 365 (un portal personalizado, un punto de conexión SSO, un receptor de webhooks), proteges su dominio personalizado con un certificado que subes a Azure. Azure App Service no genera CSR por sí mismo: la solicitud se genera fuera de Azure y luego se sube el .pfx resultante.

El camino más sencillo es nuestro Generador de CSR: introduce tus datos, descarga la CSR y la clave privada correspondiente, envía la CSR a la CA y luego combina el certificado emitido, los intermedios y la clave privada en un archivo .pfx (PKCS#12). Sube ese .pfx en App Service > Certificates > Bring your own certificates (.pfx) y vincúlalo a tu dominio personalizado. Si prefieres un flujo totalmente gestionado desde el servidor, genera la CSR en una estación de trabajo Windows administrativa usando nuestra guía de CSR para Windows y exporta el resultado a un .pfx antes de subirlo. Azure requiere que el certificado incluya el Uso extendido de clave Server Authentication (OID 1.3.6.1.5.5.7.3.1), algo que ya cumple todo certificado SSL comercial.

Generar la CSR en un servidor Windows / IIS independiente

Si «Office 365» en tu caso significa en realidad «un servidor Windows que ejecuta IIS en el mismo entorno que Microsoft 365» (por ejemplo, un portal, un sitio de intranet o un relay que no es Exchange), entonces generas la CSR en el Administrador de IIS de ese servidor. Este es el flujo que describía el tutorial original. Es la vía correcta para un host IIS genérico, pero no produce un certificado para la nube de Microsoft 365, solo para el sitio alojado en IIS que estés gestionando.

1. Abre Inicio > Herramientas administrativas de Windows > Administrador de Internet Information Services (IIS), o pulsa Win + R, escribe inetmgr y pulsa Intro.
2. En el panel Conexiones de la izquierda, selecciona el nombre de tu servidor.
3. En el panel central, haz doble clic en Certificados de servidor.
4. En el panel Acciones de la derecha, haz clic en Crear solicitud de certificado.
5. En el asistente Solicitar certificado, completa los campos de Propiedades del nombre distintivo de la siguiente manera:
   • Nombre común: el nombre de dominio completamente cualificado que quieres proteger, por ejemplo portal.example.com. No introduzcas outlook.office365.com ni ningún nombre de host propiedad de Microsoft.
   • Organización: el nombre legal completo de tu empresa (por ejemplo, Example Inc.).
   • Unidad organizativa: el departamento, a menudo IT.
   • Ciudad/localidad: la ciudad donde está registrada tu empresa (no abrevies).
   • Estado/provincia: el nombre completo del estado o provincia (no abrevies).
   • País/región: el código de país ISO de dos letras (US, GB, DE, etc.).
6. Haz clic en Siguiente.
7. En la pantalla Propiedades del proveedor de servicios criptográficos, deja el proveedor en Microsoft RSA SChannel Cryptographic Provider, establece Longitud de bits en 2048 (o 3072 / 4096 si tu política lo exige), y luego haz clic en Siguiente.
8. Especifica un nombre de archivo para la CSR (por ejemplo, C:certsportal.req) y haz clic en Finalizar.

IIS no genera nombres alternativos del sujeto a través de este asistente. Para un certificado SAN o multidominio, genera la CSR con PowerShell utilizando un archivo INF personalizado con certreq, o usa nuestro Generador de CSR y más adelante combina el certificado emitido y la clave en un archivo .pfx para importarlo. Para el flujo completo específico de IIS con capturas de pantalla, consulta nuestra guía de CSR para Microsoft IIS.

Abre el archivo .req guardado en el Bloc de notas y copia todo el bloque, incluidas las líneas -----BEGIN NEW CERTIFICATE REQUEST----- y -----END NEW CERTIFICATE REQUEST-----, en el formulario de pedido de tu CA.

Verifica tu CSR antes de enviarla

Antes de pegar la CSR en el formulario de pedido, decodifícala para confirmar que los datos son correctos. Un error tipográfico en el nombre común, un SAN faltante o una longitud de clave demasiado corta rechazará el pedido o forzará una reemisión más adelante. Pega la CSR en nuestro Decodificador de CSR para ver el nombre común, la lista completa de SAN, la organización, el país, el algoritmo de firma y el tamaño de la clave.

Una vez que la CA valide la solicitud y emita el certificado, continúa con nuestra guía de instalación de SSL en Microsoft 365 para conocer el paso de instalación correspondiente (importación en Exchange híbrido, vinculación en AD FS, subida a Azure App Service o vinculación en IIS).