Compartir a través de

Preguntas más frecuentes sobre la autenticación de aplicaciones anidadas y los tokens heredados de Outlook

  • Artículo

Los tokens de identidad de usuario de Exchange y los tokens de devolución de llamada están en desuso y se desactivarán a partir del 17 de febrero de 2025. Se recomienda mover complementos de Outlook que usan tokens de Exchange heredados a la autenticación de aplicaciones anidadas.

Preguntas más frecuentes generales

¿Qué es la autenticación de aplicaciones anidadas (NAA)?

La autenticación de aplicaciones anidadas permite el inicio de sesión único (SSO) para las aplicaciones anidadas dentro de aplicaciones compatibles de Microsoft, como Outlook. En comparación con los modelos de autenticación de plena confianza existentes y el flujo en nombre de, NAA proporciona una mejor seguridad y una mayor flexibilidad en la arquitectura de aplicaciones, lo que permite la creación de aplicaciones enriquecidas y controladas por el cliente. Para obtener más información, vea Habilitar el inicio de sesión único en un complemento de Office mediante la autenticación de aplicaciones anidadas.

¿Cuál es la escala de tiempo para apagar los tokens heredados de Exchange Online?

Microsoft comienza a desactivar los tokens en línea de Exchange heredados a partir del 17 de febrero de 2025. Desde ahora hasta el 17 de febrero de 2025, los inquilinos existentes y nuevos no se verán afectados. Hemos proporcionado herramientas para que los administradores puedan volver a habilitar tokens de Exchange para inquilinos y complementos si esos complementos aún no se migran a NAA. Consulte ¿Puedo volver a activar los tokens heredados? para obtener más información.

Fecha Estado de tokens heredados
17 de febrero de 2025 Tokens heredados desactivados para todos los inquilinos. Los administradores pueden volver a habilitar tokens heredados a través de PowerShell.
Junio de 2025 Tokens heredados desactivados para todos los inquilinos. Los administradores ya no pueden volver a habilitar tokens heredados a través de PowerShell y deben ponerse en contacto con Microsoft para cualquier excepción.
Octubre de 2025 Tokens heredados desactivados para todos los inquilinos. Ya no se permiten excepciones.

¿Qué ocurre el 17 de febrero?

Microsoft comenzará a implementar un cambio en todos los usuarios de todo el mundo en los inquilinos de Microsoft 365 que desactivará la emisión de tokens en línea de Exchange heredados. La implementación tardará varias semanas en implementarse en todos los usuarios. Si un complemento de Outlook solicita un token de Exchange heredado y la emisión de tokens está desactivada, el complemento recibirá un error. Este cambio romperá los complementos de Outlook que siguen solicitando tokens de Exchange Online heredados. Tenga en cuenta que incluso después de desactivar los tokens heredados, los tokens heredados emitidos anteriormente seguirán siendo válidos durante un máximo de una hora.

Tenga en cuenta que, dado que el cambio se aplica por usuario y se implementa durante varias semanas, podría ver que algunos usuarios se ven afectados mientras que otros no. Si necesita no participar en este cambio, consulte ¿Puedo volver a activar los tokens heredados?

¿Cuándo está disponible naa con carácter general para mi canal?

La fecha de disponibilidad general (GA) para NAA depende del canal que esté usando.

Fecha Disponibilidad general (GA) de NAA
Octubre de 2024 NAA es ga en el canal actual.
Noviembre de 2024 NAA es disponibilidad general en el canal mensual de empresa.
Enero de 2025 NAA es GA en Semi-Annual channel build 16.0.17928.20392.
Junio de 2025 NAA tendrá disponibilidad general en Semi-Annual canal extendido.

Cómo tokens heredados controlados desactivados en Semi-Annual canal extendido, ¿qué aún no admite NAA?

Semi-Annual canal extendido no admitirá NAA hasta junio de 2025. Esto significa que incluso si los complementos se actualizan para admitir NAA y ya no usan tokens de Exchange Online heredados, no funcionarán en este canal. Si usa Semi-Annual canal extendido como administrador, se recomienda lo siguiente.

¿Los complementos COM se ven afectados por el desuso de tokens de Exchange Online heredados?

Es muy poco probable que los complementos COM se vean afectados por el desuso de los tokens de Exchange Online heredados. Los complementos web de Outlook se ven afectados principalmente porque pueden usar Office.js API que se basan en tokens de Exchange. Para obtener más información, vea How do i know if my outlook add in se basa en tokens heredados. Los tokens de Exchange se usan para acceder a los servicios web de Exchange (EWS) o a las API REST de Outlook, que también están en desuso. Si sospecha que un complemento COM podría verse afectado, puede probarlo mediante su uso en un inquilino con tokens de Exchange desactivados. Para obtener más información, vea Activar o desactivar tokens de Exchange Online heredados.

Preguntas sobre el administrador de Microsoft 365

¿Puedo volver a activar Exchange Online tokens heredados?

Sí, hay comandos de PowerShell que puede usar para activar o desactivar tokens heredados en cualquier inquilino. Para obtener más información sobre cómo activar o desactivar tokens heredados, consulte Activar o desactivar tokens de Exchange Online heredados. Si usa los comandos para habilitar tokens de Exchange Online heredados, no se desactivarán en febrero de 2025. Permanecerán activados hasta junio de 2025 o hasta que use las herramientas para desactivarlas.

En junio de 2025, los tokens heredados se desactivarán y no podrá volver a activarlos sin una excepción específica concedida por Microsoft. En octubre de 2025, no será posible activar los tokens heredados y se deshabilitarán para todos los inquilinos. Actualizaremos estas preguntas más frecuentes con información adicional una vez que el proceso de excepción esté listo.

Los proveedores de software independientes (ISV) están actualizando sus complementos para usar tokens de id. de entra y ámbitos de Microsoft Graph. Cuando el complemento solicita un token de acceso, debe tener el consentimiento del administrador o del usuario. Si el administrador da su consentimiento, todos los usuarios del inquilino pueden usar el complemento para los ámbitos que requiere el complemento. De lo contrario, se pedirá consentimiento a cada usuario final, si el consentimiento del usuario está habilitado. Para una mejor experiencia porque no se solicita a los usuarios, complete el consentimiento del administrador.

Una opción para el consentimiento es que el ISV le proporciona un URI de consentimiento del administrador.

  1. El desarrollador del complemento proporciona un URI de consentimiento del administrador. Si esto no está en la documentación que proporcionan, debe ponerse en contacto con ellos para obtener más información.
  2. El administrador busca el URI de consentimiento del administrador.
  3. Se pide al administrador que inicie sesión y dé su consentimiento a una lista de ámbitos que requiere el complemento.
  4. Una vez completado, el explorador redirige a una página web desde el ISV, que debe mostrar que el consentimiento se realizó correctamente.

Como alternativa, el ISV puede proporcionar un manifiesto de aplicación actualizado que solicitará el consentimiento del administrador como parte de la implementación central. En este escenario, al implementar el manifiesto de aplicación actualizado, se le pedirá que dé su consentimiento antes de que se pueda completar la implementación. No es necesario un URI de consentimiento del administrador.

Por último, si el complemento se publica en el almacén de Microsoft 365, la actualización se implementará automáticamente y se pedirá al administrador que dé su consentimiento a los ámbitos. Si el administrador no da su consentimiento, los usuarios no podrán usar el complemento actualizado.

Asegúrese de que no deshabilita las características ni revoca los permisos que requiere el complemento. Para obtener un ejemplo, consulte modificación de las propiedades de directiva de buzón de correo. El complemento usa permisos delegados y, por lo tanto, tiene acceso a los mismos recursos que el usuario que inició sesión. Sin embargo, si una directiva o configuración bloquea al usuario de un recurso o acción determinados, el complemento también se bloqueará.

Cómo implementar actualizaciones de complementos desde un ISV?

Si tiene un complemento que usa tokens de Exchange heredados, debe ponerse en contacto con el ISV para obtener información sobre su escala de tiempo para migrar su complemento para usar NAA. Una vez que el ISV migra su complemento, lo más probable es que proporcione una dirección URL de consentimiento del administrador. Para obtener más información, vea ¿Cómo funciona el flujo de consentimiento del administrador? .

El ISV también puede proporcionarle un manifiesto de aplicación actualizado para implementarlo mediante la implementación centralizada. Durante la implementación centralizada, esto puede pedirle que dé su consentimiento a cualquier ámbito de Microsoft Graph que requiera el complemento. En este escenario, no tendrá que usar un URI de consentimiento del administrador.

Si el complemento se implementa desde Microsoft AppSource, lo más probable es que se le pida que dé su consentimiento a los ámbitos de Microsoft Graph cuando el ISV implemente actualizaciones en el complemento. Hasta que no dé su consentimiento, los usuarios del inquilino no podrán usar la nueva versión del complemento con NAA.

¿Qué complementos de mi organización se ven afectados?

Publicamos una lista de todos los complementos de Outlook publicados en microsoft store que usan tokens heredados a partir de octubre de 2024. Para obtener más información sobre cómo usar la lista y crear un informe de complementos de Outlook que pueden usar tokens heredados, vea Buscar complementos de Outlook que usan tokens de Exchange Online heredados.

Los complementos pueden usar los tokens heredados para obtener recursos de Exchange a través de las API REST de EWS o Outlook. A veces, un complemento requiere recursos de Exchange para algunos casos de uso y no para otros, lo que dificulta averiguar si el complemento requiere una actualización. Se recomienda ponerse en contacto con los desarrolladores y propietarios de complementos para preguntarles si su código de complemento hace referencia a las siguientes API.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Si confía en un ISV para el complemento, le recomendamos que se ponga en contacto con ellos lo antes posible para confirmar que tienen un plan y una escala de tiempo para salir de los tokens de Exchange heredados. Los desarrolladores de ISV deben ponerse en contacto directamente con sus contactos de Microsoft con preguntas para asegurarse de que están listos para el final de los tokens heredados de Exchange. Si confía en un desarrollador de su organización, deben revisar estas preguntas más frecuentes y el artículo Habilitación del inicio de sesión único en un complemento de Office mediante la autenticación anidada de aplicaciones. Cualquier pregunta debe plantearse en el sitio de problemas de GitHub OfficeDev/office-js.

Nota:

Hemos estado trabajando para proporcionar una actualización de comandos a Exchange Online PowerShell que notifica cualquier complemento mediante tokens de Exchange Online heredados. Desafortunadamente, hemos tenido dificultades para implementar esta actualización debido a la complejidad de capturar un uso específico de tokens en el ecosistema de Microsoft 365. Seguimos trabajando en esta actualización y proporcionaremos nueva información en esta P+F cuando esté disponible.

Una vez que el administrador o un usuario dan su consentimiento, se mostrará en el Centro de administración Microsoft Entra. Puede encontrar registros de aplicaciones mediante los pasos siguientes.

  1. Vaya a https://entra.microsoft.com/#home e inicie sesión como administrador en el inquilino.
  2. En el panel de navegación izquierdo, seleccione Aplicaciones>empresariales aplicaciones.
  3. En la página Aplicaciones empresariales , en la sección Administrar , seleccione Todas las aplicaciones.
  4. Seleccione el complemento. Se abrirá una página de información general. En la página de información general, seleccione Permisos. Hay dos vistas para los permisos; Administración consentimiento y consentimiento del usuario. Seleccione Consentimiento del usuario para ver los consentimientos individuales.

¿Hay una lista de publicadores que han actualizado sus complementos?

Algunos editores de complementos de Outlook ampliamente usados ya han actualizado sus complementos como se muestra a continuación.

Si el publicador actualizó su manifiesto y el complemento se implementa a través de Microsoft Store, se le pedirá como administrador que actualice e implemente las actualizaciones. Si el publicador actualizó su manifiesto y el complemento se implementa a través de la implementación central, deberá implementar el nuevo manifiesto como administrador. En algunos casos, el publicador puede tener un URI de consentimiento de administrador que debe usar para dar su consentimiento a nuevos ámbitos para el complemento. Póngase en contacto con los publicadores si necesita más información sobre cómo actualizar un complemento.

Algunos complementos se están rompiendo. ¿Puedo saber si esto se debe a que los tokens de Exchange se desactivaron?

A partir del 17 de febrero de 2025, Microsoft está implementando una actualización para desactivar gradualmente los tokens de Exchange Online heredados para todos los usuarios. La actualización no desactivará los tokens de Exchange en el inquilino si ya ha activado tokens de Exchange Online heredados.

Si el inquilino usa un complemento que todavía se basa en tokens de Exchange, el complemento interrumpirá o perderá la funcionalidad. La actualización se implementa por usuario. Esto significa que uno o más usuarios pueden tener un complemento afectado cuando los tokens de Exchange están desactivados, pero otros usuarios todavía tendrían un complemento de trabajo. Si observa que un complemento tiene problemas y sospecha que puede verse afectado por tokens de Exchange desactivados, realice las siguientes acciones.

Comprobación de la lista de complementos conocidos

Hemos publicado una lista de complementos que se sabía que usaban tokens de Exchange heredados a partir de octubre de 2024. Si un complemento está en esta lista, debe ponerse en contacto con el publicador para ver si hay actualizaciones disponibles. Para obtener más información, vea Buscar complementos de Outlook que usan tokens de Exchange Online heredados.

Compruebe si los tokens están desactivados mediante Script Lab

Compruebe si los tokens de Exchange Online heredados están desactivados para un usuario mediante el complemento de Script Lab.

  1. Instale Script Lab para Outlook.

  2. Inicie sesión en Outlook con la cuenta de usuario o buzón de correo que se ve afectado. Los tokens de Exchange pueden estar desactivados para un usuario, pero no para otro hasta que se complete el lanzamiento.

  3. En un correo electrónico nuevo o existente, abra Script Lab en el menú Aplicaciones y elija Código en el menú Script Lab.

    Captura de pantalla del menú Script Lab.

  4. En el panel de tareas Script Lab, seleccione el icono backstage (tiene tres líneas).

    Captura de pantalla del icono de backstage.

  5. Seleccione Ejemplos y busque el ejemplo Obtener un token de identidad de usuario . Seleccione este ejemplo para abrirlo en el editor de código.

    Captura de pantalla del menú de Script Lab y el cuadro de búsqueda para buscar el ejemplo obtener un token de identidad de usuario.

  6. Una vez cargado el código del ejemplo, seleccione Ejecutar ejecución>en este panel.

    Captura de pantalla de la opción de menú Ejecutar en Script Lab.

  7. Una vez que se ejecute el código, seleccione Obtener token.

Si los tokens de Exchange Online heredados están activados, verá un token mostrado en la consola como una cadena codificada en Base64.

Captura de pantalla de un token que se muestra en la ventana de la consola.

Si los tokens de Exchange Online heredados están desactivados, verá un error en la consola como se muestra a continuación.

Captura de pantalla de un error en la ventana de la consola.

Si un complemento se ve afectado por los tokens de Exchange desactivados, puede volver a activarlos. Para obtener más información, consulte ¿Puedo volver a activar Exchange Online tokens heredados?.

Preguntas más frecuentes sobre la migración de complementos de Outlook

¿Por qué Microsoft realiza la migración de complementos de Outlook?

Cambiar a Microsoft Graph mediante tokens de id. de Entra es una gran mejora en la seguridad para los clientes de Outlook y Exchange. Entra ID (anteriormente Azure Active Directory) es un servicio líder de administración de identidades y acceso basado en la nube. Los clientes pueden aprovechar las características de confianza cero, como el acceso condicional, los requisitos de MFA, la supervisión continua de tokens, la heurística de seguridad en tiempo real y mucho más que no están disponibles con tokens de Exchange heredados. Los clientes almacenan datos empresariales importantes almacenados en Exchange, por lo que es fundamental que nos aseguremos de que estos datos están protegidos. La migración de todo el ecosistema de Outlook para usar tokens de id. de Entra con Microsoft Graph mejora considerablemente la seguridad de los datos de los clientes.

¿Mi complemento de Outlook tiene que migrar a NAA?

No. Los complementos de Outlook no tienen que usar NAA, aunque NAA ofrece la mejor experiencia de autenticación para los usuarios y la mejor posición de seguridad para las organizaciones. Si los complementos no usan tokens de Exchange heredados, no se verán afectados por el desuso de los tokens de Exchange. Los complementos que usan MSAL.js u otros métodos de SSO que dependen de Entra ID seguirán funcionando.

Cómo saber si mi complemento de Outlook se basa en tokens heredados?

Para averiguar si el complemento usa tokens de identidad de usuario y tokens de devolución de llamada heredados de Exchange, busque en el código las llamadas a las siguientes API.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Si el complemento llama a cualquiera de estas API, debe adoptar NAA y migrar a mediante tokens de id. de entra para acceder a Microsoft Graph en su lugar.

¿Qué complementos de Outlook están en el ámbito?

Muchos complementos principales están en el ámbito. Si el complemento usa EWS o REST de Outlook para acceder a Exchange Online recursos, es casi seguro que necesita migrar de tokens heredados de Outlook a NAA. Si el complemento es solo para Exchange local (por ejemplo, Exchange 2019), no se ve afectado por este cambio.

¿Qué pasará con mis complementos de Outlook si no migre a NAA?

Si no migra los complementos de Outlook a NAA, dejarán de funcionar según lo esperado en Exchange Online. Cuando se desactivan los tokens de Exchange, Exchange Online bloqueará la emisión de tokens heredados. Cualquier complemento que use tokens heredados no podrá acceder a los recursos de Exchange Online.

Si el complemento solo funciona de forma local o si el complemento está en una ruta de desuso, es posible que no tenga que actualizarlo. Sin embargo, la mayoría de los complementos que acceden a recursos de Exchange a través de EWS o REST de Outlook deben migrar para seguir funcionando según lo previsto.

Cómo migrar mis complementos de Outlook a NAA?

Para admitir NAA en el complemento de Outlook, consulte la siguiente documentación y ejemplo.

Cómo mantenerse al día con las instrucciones más recientes?

Actualizaremos estas preguntas más frecuentes a medida que haya información nueva disponible. Compartiremos instrucciones adicionales para avanzar en la llamada a la comunidad de complementos de Office y en el blog para desarrolladores de M365. Por último, puede formular preguntas sobre NAA y la desuso de tokens Exchange Online heredados en el sitio de problemas de GitHub OfficeDev/office-js. Coloque "NAA" en el título para que podamos agrupar y priorizar los problemas.

Si envía un problema, incluya la siguiente información.

  • Versión de cliente de Outlook.
  • Audiencia del canal de versión de Outlook (para el cliente).
  • Captura de pantalla del problema.
  • La plataforma donde se produce el problema (Windows, Outlook (nuevo), Mac, iOS, Android).
  • Id. de sesión donde se encuentra el problema.
  • Tipo de cuenta que se usa.
  • Versión de msal-browser.
  • Registros de msal-browser.

Preguntas para desarrolladores

Cómo obtener más información de depuración de MSAL y NAA?

Use el código siguiente para habilitar la información de depuración en msalConfig al inicializar la aplicación cliente pública anidable. Esto registrará detalles adicionales en la consola.

const msalConfig = {
  auth: {...},
  system: {
    loggerOptions: {
      logLevel: LogLevel.Verbose,
      loggerCallback: (level, message, containsPii) => {
        switch (level) {
          case LogLevel.Error:
            console.error(message);
            return;
          case LogLevel.Info:
            console.info(message);
            return;
          case LogLevel.Verbose:
            console.debug(message);
            return;
          case LogLevel.Warning:
            console.warn(message);
            return;
        }
      },
    }
  }
};

Prueba del complemento actualizado

Una vez que haya actualizado el complemento para usar NAA, debe probarlo en todas las plataformas que admita, como Mac, móvil, web y Outlook en Windows.

Prueba cuando los tokens de Exchange están desactivados

Para probar que el complemento funciona correctamente cuando los tokens de Exchange están desactivados, implemente el complemento en un inquilino con tokens desactivados y pruébelo. Para desactivar los tokens, consulte Activar o desactivar tokens de Exchange Online heredados.

Si ha implementado un patrón en el que el código usa tokens de Exchange pero, a continuación, se cae si no están disponibles, asegúrese de comprobar los errores correctos. Cuando se produce un error en una llamada para obtener un token de Exchange, compruebe asyncResult.diagnostics. Si se devuelve cualquiera de los siguientes errores, cambie a NAA.

  • GenericTokenError: An internal error has occurred.
  • InternalServerError: The Exchange server returned an error. Please look at the diagnostics object for more information.

Prueba del código de reserva para la vista web trident+

Si el complemento de Outlook admite Outlook 2016 o Outlook 2019 en Windows, compruebe que funciona correctamente cuando se usa la vista web Trident+ (Internet Explorer 11). Cuando se usa la vista web trident+, el código debe volver a MSAL v2 para abrir un cuadro de diálogo e iniciar sesión en el usuario. Para obtener más información sobre cómo implementar el patrón de reserva, vea Complemento de Outlook con SSO mediante la autenticación de aplicaciones anidadas, incluida la reserva de Internet Explorer.

Pruebas en Trident+ y WebView2

Outlook 2016 y Outlook 2019 en Windows usan Trident+ o WebView2 en función de varias condiciones del sistema operativo.

Cómo validar el token de identificador o autenticar al usuario?

Con los tokens de Exchange, puede validar el token de identificador y usarlo para autorizar al usuario a acceder a sus propios recursos. Para obtener más información, consulte Autenticación de un usuario con un token de identidad para Exchange. Sin embargo, MSAL con tokens de id. de entra no usa este enfoque.

Cuando se solicita un token a través de MSAL, siempre devuelve tres tokens.

Token Objetivo Scopes
Token de identificador Proporciona información sobre el usuario al cliente (panel de tareas). profile y openid
Token de actualización Actualiza el identificador y los tokens de acceso cuando expiran. offline_access
Token de acceso Autentica al usuario para ámbitos específicos en un recurso, como Microsoft Graph. Cualquier ámbito de recursos, como user.read.

MSAL siempre devuelve estos tres tokens. Solicita , profileopenidy offline_access como ámbitos predeterminados, incluso si la solicitud de token no los incluye. Esto garantiza que se soliciten los tokens de id. y actualización. Sin embargo, debe incluir al menos un ámbito de recurso, como user.read para obtener un token de acceso. Si no es así, la solicitud puede producir un error.

Pasar el token de identificador a través de una llamada de red para habilitar o autorizar el acceso a un servicio es un anti-patrón de seguridad. El token solo está pensado para el cliente (panel de tareas) y no hay ninguna manera de que el servicio use el token de forma confiable para asegurarse de que el usuario tiene acceso autorizado. Para obtener más información sobre las notificaciones de token de identificador, vea https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference.

Es muy importante que siempre solicite un token de acceso a sus propios servicios. El token de acceso también incluye las mismas notificaciones de identificador, por lo que no es necesario pasar el token de identificador. En su lugar, cree un ámbito personalizado para el servicio. Para obtener más información sobre la configuración de registro de aplicaciones para sus propios servicios, consulte API web protegida: Registro de aplicaciones. Cuando el servicio recibe el token de acceso, puede validarlo y usar notificaciones de identificador desde dentro del token de acceso.

Cómo determinar si el usuario es una cuenta en línea o local?

Puede determinar si el usuario que ha iniciado sesión tiene una cuenta de Exchange Online o una cuenta de Exchange local mediante la propiedad Office.UserProfile.accountType. Si el valor de la propiedad de tipo de cuenta es enterprise, el buzón de correo se encuentra en un servidor exchange local. Tenga en cuenta que el Outlook 2016 perpetuo con licencia por volumen no admite la propiedad accountType. Para solucionar este problema, llame a la operación ResolveNames en el servicio web de Exchange (EWS) en el servidor local de Exchange para obtener los tipos de destinatario.

Cómo implementar mi complemento en Microsoft AppSource

Si va a publicar un nuevo complemento en Microsoft AppSource, tendrá que pasar por un proceso de certificación. Para obtener más información, vea Publicar el complemento de Office en Microsoft AppSource. Si va a actualizar el manifiesto de un complemento que ya está publicado en Microsoft AppSource, debe volver a realizar el proceso de certificación. Puede actualizar el código fuente del complemento en el servidor web en cualquier momento sin necesidad de pasar por el proceso de certificación.

Si el complemento usa el inicio de sesión único a través de NAA, el complemento debe cumplir las siguientes directrices de publicación.

Asegúrese de controlar el consentimiento del administrador correctamente. Consulte Publicación de un complemento que requiera el consentimiento del administrador para los ámbitos de Microsoft Graph.

Para obtener más detalles sobre la implementación, consulte Hacer que las soluciones estén disponibles en Microsoft AppSource y en Office. Si actualiza el complemento (cambie el manifiesto), deberá volver a realizar el proceso de certificación. Puede actualizar el código del servidor web en cualquier momento sin necesidad de revisión.

Contenido relacionado