DigiCert will stop issuing 2-year public SSL/TLS certificates
On August 27, 2020 5:59 pm MDT (23:59 UTC), DigiCert will stop issuing 2-year public SSL/TLS certificates to prepare for the industry changes to the maximum allowed validity for public SSL/TLS certificates.
After the August 27 deadline, you can only purchase 1-year public SSL/TLS certificates.
What do I need to do?
To ensure you get needed 2-year public SSL/TLS certificates before the August 27 deadline:
To learn how this change will affect pending certificate orders, reissues, and duplicates, see End of 2-Year DV, OV, and EV public SSL/TLS certificates.
DigiCert Services API
For those using the DigiCert Services API, you'll need to update your API workflows to account for the new maximum certificate validity of 397 days for requests placed after the August 27 deadline. See Services API.
After August 27, 2020
After August 27, you can only purchase 1-year public SSL/TLS certificates. However, to maximize your SSL/TLS coverage, purchase your new certificates with a DigiCert® Multi-year Plan. See Multi-year Plans.
Why is DigiCert making this change?
On September 1, 2020, the industry says good-bye to 2-year certificates. Going forward Certificate Authorities (CA) can only issue public DV, OV, and EV SSL/TLS certificates with a maximum validity of 398 days (approximately 13 months).
DigiCert will implement a 397-day maximum validity for all public SSL/TLS certificates as a safeguard to account for time zone differences and to avoid issuing a public SSL/TLS certificate that exceeds the new 398-day maximum validity requirement.
Check out our blog to learn more about the transition to 1-year public SSL/TLS certificates: One-Year Public-Trust SSL Certificates: DigiCert’s Here to Help.
Terminará la compatiblidad de los navegadores TLS 1.0 y 1.1
En 2020, los cuatro navegadores principales dejarán de ser compatibles con la Seguridad de la capa de transporte (TLS) 1.0 y 1.1.
Este cambio no afecta sus certificados DigiCert. Sus certificados seguirán funcionando como siempre.
Lo que debe saber
Este cambio afecta los servicios y las aplicaciones que dependen del navegador y cuentan con TLS 1.0 o 1.1. Una vez que los navegadores dejen de ser compatibles con TLS 1.0 o 1.1, no se podrá entablar conexiones HTTPS mediante estos sistemas desactualizados.
Lo que debe hacer
Si lo afecta este cambio, planifique activar o actualizar a TLS 1.2 o TLS 1.3 ahora. Adelántese a los problemas que puedan surgir. Antes de comenzar, vele por detectar todos los sistemas que puedan estar usando TLS 1.0 o 1.1.
Recuerde controlar los servidores web como Apache o Microsoft IIS, .NET Framework, los agentes de control de servidores y otras aplicaciones comerciales que podrían usarlas.
Recursos útiles
Con tantos tipos diferentes de sistemas que cuentan con TLS, no podemos hablar de todos los canales de actualización disponibles, pero estas son algunas referencias que podrían serle de utilidad:
Microsoft dejará de ser compatible con las firmas digitales de encapsulados de controladores en modo kernel de terceros
El proceso de firma de sus encapsulados de controladores en modo kernel cambiará. A partir de 2021, Microsoft será el único proveedor de firmas de código en modo kernel de producción. Deberá comenzar a seguir las instrucciones de actualización de Microsoft para firmar cualesquier encapsulados de controladores en modo kernel nuevos en lo sucesivo. Consulte el Centro de socios para soporte lógico de Windows.
¿Qué hará DigiCert al respecto de esto?
Como primer paso del proceso de extinción de la compatibilidad, DigiCert ha eliminado la opción plataforma de código en modo kernel de Microsoft de los formularios de solicitud de certificados de firma de código: nuevos, reemisiones y renovaciones.
Esto significa que, en lo sucesivo, no podrá pedir, reemitir ni renovar un certificado de firma de código para una plataforma en modo kernel.
¿Cómo se verán afectados mis certificados de firma de código en modo kernel?
Puede seguir usando sus certificados que ya existen para firmar encapsulados de controladores en modo kernel hasta que venza la raíz cofirmada con la que están enlazados. Los certificados raíz cofirmados de la marca DigiCert vencen en 2021.
Para obtener más información, consulte nuestro artículo de consulta, Microsoft dejará de ser compatible con los certificados raíz cofirmados con las capacidades de firma en modo kernel.
Nuevos requisitos de cumplimiento de Apple para certificados SSL privados
Recientemente, Apple anunció algunos requisitos de seguridad nuevos para certificados SSL/TLS que entrarán en vigencia con la versión de iOS 13 y macOS 10.15. Estos requisitos afectan los certificados privados que se hayan emitido a partir del 1 de julio de 2019.
Para sus certificados SSL/TLS públicos de DigiCert, no se necesita hacer ninguna acción.
Los certificados SSL/TLS públicos de DigiCert ya cumplen con todos estos requisitos de seguridad. Sus certificados SSL/TLS públicos no se ven afectados por estos nuevos requisitos y tendrán confianza en iOS 13 y macOS 10.15.
¿Qué novedades hay?
Apple está implementando requisitos de seguridad adicionales para todos los certificados SSL/TLS que, por su diseño, afectan a los certificados SSL/TLS privados. Vea Requisitos para certificados de confianza en iOS 13 y macOS 10.15.
Los certificados SSL/TLS privados de DigiCert cumplen con estos requisitos si fueron emitidos por administradores de cuenta de acuerdo con los requisitos de los certificados públicos.
A continuación, proporcionamos una lista de los requisitos que pueden afectan a sus certificados SSL/TLS privados. Los lanzamientos de estas versiones de SO de Apple se prevén para el otoño de este año. Esto significa que se tiene que preparar ahora.
Requisitos de los nuevos certificados SSL/TLS privados:
¿Qué puede hacer?
Si necesita la fiabilidad de Apple iOS y macOS para sus certificados SSL/TLS privados, confirme que los certificados SSL/TLS privados que se hayan emitido desde el 1 de julio de 2019 cumplan los nuevos requisitos. Si encuentra certificados que no cumplen estos requisitos, debería hacer estas acciones pronto:
Firefox pone coto a su compatibilidad con la creación de claves
A partir del lanzamiento de Firefox 69, Firefox finalmente dejará de ser compatible con Keygen. Firefox usa Keygen para facilitar la creación de materiales clave para enviar la clave pública a la hora de crear certificados de firma de código, de cliente y de SMIME en su navegador.
Nota: Chrome ya había eliminado su compatibilidad con la creación de claves, y Edge y Opera nunca fueron compatibles con ella.
¿Cómo lo afecta esto?
Luego de que DigiCert emita su certificado de firma de código, de cliente o de SMIME, le enviaremos un correo electrónico con un enlace para crear e instalar su certificado.
Cuando se lance Firefox 69, solo podrá usar dos navegadores para crear estos certificados: Internet Explorer y Safari. Si la política de la empresa le exige que use Firefox, puede usar Firefox ESR o una copia portátil de Firefox.
Para obtener más información, consulte Keygen no será compatible con Firefox 69.
Consejos y trucos
Agregamos un nuevo estado, Enviado por correo electrónico al destinatario,, a las páginas Pedidos e Información del pedido, para los pedidos de certificados de firma de código y del cliente, lo que hace que sea más fácil reconocer en qué etapa del proceso de emisión están estos pedidos.
Con este nuevo estado se indica que DigiCert ha validado el pedido, y el certificado está a la espera de que el usuario/destinatario del correo electrónico lo genere en uno de los navegadores compatibles: IE 11, Safari, Firefox 68 y Firefox portable.
(En el menú lateral, haga clic en Certificados > Pedidos. Luego, en la página Pedidos, haga clic en el número de pedido del pedido de certificado de firma de código o del cliente).
Hemos actualizado nuestros procesos de reemisión de certificados de firma de código (CS) con validación extendida (EV) y de firma de documento (DS) para que pueda volver a emitir esos certificados sin revocar de manera automática el certificado actual (certificado original o ya reemitido).
Nota: Si no necesita el certificado actual (certificado original o ya reemitido), deberá comunicarse con el servicio técnico para que lo revoquen por usted.
Ahora, la próxima vez que vuelva a emitir un certificado EV CS o DS, podrá hacer que el certificado ya emitido se mantenga activo hasta que termine su período de validez vigente (o durante el período que lo necesite).
Recordatorio encaminado al cumplimiento de las normas del sector
Para los certificados públicos y privados, las Autoridades de certificados (CA) no aceptan abreviaciones en estas partes de una dirección en sus pedidos de certificado ni en las solicitudes de validación previa de organizaciones:
* Esto vale para las direcciones de las organizaciones y jurisdicciones.
Ya es más fácil definir el alcance de la validación de dominios para su cuenta a la hora de enviar a validar sus dominios (pedidos de validación previa o a través de certificados).
En la página Preferencias de la división, hemos agregado dos opciones de alcance de la validación de dominios:
Para configurar el alcance de la validación de dominios de su cuenta, en el menú lateral, haga clic en Configuración > Preferencias). En la página Preferencias de división, expanda Configuración avanzada. En la sección Validación de control de dominio (DCV), en Alcance de la validación de dominios,, verá las nuevas configuraciones.
Hemos solucionado un error por el cual se restringía el número permitido máximo de SAN a 10 en la reemisión de certificados Wildcard SSL y en los pedidos de certificados nuevos.
Ahora, cuando vuelva a emitir un certificado Wildcard SSL o pida uno nuevo, puede agregar hasta 250 SAN.
Cambio de los estándares de la industria
A partir del 31 de julio de 2019 (19:30 UTC), debe usar el método DCV de demostración práctica HTTP para demostrar que tiene el control de las direcciones IP que figuran en sus pedidos de certificados.
Para obtener más información sobre el método DCV de demostración práctica HTTP, vea estas instrucciones:
Estándares de la industria actualmente usados para permitirle utilizar otros métodos DCV para demostrar que tiene el control de su dirección IP. No obstante, con la aprobación de la Votación SC7, los reglamentos para la validación de la dirección IP cambiaron.
Votación SC7: actualizar los métodos de validación de la dirección IP
Esta votación redefine los procesos y los procedimientos permitidos para validar el control del cliente de una dirección IP que figura en un certificado. Los cambios respecto del cumplimiento para la Votación SC7 entran en vigencia el 31 de julio de 2019 (19:30 UTC).
Para seguir cumpliendo, a partir del 31 de julio de 2019 (19:30 UTC), DigiCert solo permite que los clientes usen el método DCV de demostración práctica HTTP para validar sus direcciones IP.
Eliminación de la compatibilidad con IPv6
A partir del 31 de julio de 2019 (19:30 UTC), DigiCert ha eliminado la compatibilidad de los certificados con las dirección IPv6. Debido a las limitaciones de los servidores, DigiCert no puede alcanzar la dirección IPv6 para verificar el archivo ubicado en el sitio web del cliente para el método DCV de demostración práctica HTTP.
Hemos actualizado la configuración de la federación SAML de CertCentral y ahora le permitimos evitar que su nombre de federación aparezca en la lista de IdP en las páginas Selección de IdP de inicio de sesión único SAML y Selección de IdP de solicitudes de certificados SAML.
Ahora, en la página Configuración de federación, en Metadatos de su IdP, agregamos la opción Incluir nombre de federación. Si desea evitar que su nombre de federación aparezca en la lista de IdP en la página Selección de IdP,, no seleccione Agregar el nombre de mi federación a la lista de IdP.
Los certificados Secure Site Pro TLS/SSL están disponibles en CertCentral. Con Secure Site Pro, se le cobra por dominio; sin costo de certificado base. Agregue un dominio y pague uno. Necesita nueve dominios, pague nueve. Proteja hasta 250 dominios en un certificado.
Ofrecemos dos tipos de certificados Secure Site Pro: uno para certificados OV y otro para certificados EV.
Beneficios incluidos con cada certificado Secure Site Pro
Cada certificado Secure Site Pro incluye (sin costo adicional) primer acceso a agregados futuros de funciones de primera calidad a CertCentral (por ejemplo, control de registro CT y gestión de validación).
Otros beneficios incluyen los siguientes:
Para activar los certificados Secure Site Pro para su cuenta de CertCentral, póngase en contacto con el administrador de su cuenta o con nuestro Equipo de asistencia.
Para obtener más información sobre nuestros certificados Secure Site Pro, vea Secure Site Pro de DigiCert.
Los certificados SSL públicos ya no pueden proteger nombres de dominio con guiones bajos ("_"). Todos los certificados previamente emitidos que tengan guiones bajos en los nombres de dominio deben caducar antes de esta fecha.
Nota: La solución preferida respecto de los guiones bajos es renombrar los nombres de host (FQDN) que contengan los contengan y reemplazarlos en los certificados. No obstante, para aquellas situaciones en las que renombrar no sea posible, puede usar certificados privados y, en algunos casos, un certificado comodín que proteja todo el dominio.
Para obtener más detalles, vea Eliminación de los guiones bajos de los nombres de dominio.
Requisitos del estándar de la industria para incluir la extensión CanSignHttpExchanges en un certificado ECC SSL/TLS:
* Nota: Estos requisitos entraron en vigencia a partir del 1 de mayo de 2019. La extensión Intercambios firmados de HTTP está en desarrollo activo. Puede haber cambios adicionales de los requisitos a medida que el desarrollo industrial continúa.
El requisito de validez máxima de 90 días del certificado no afecta a los certificados emitidos antes del 1 de mayo de 2019. Tenga en cuenta que el certificado reemitido se truncará a 90 días desde el momento de la reemisión. Sin embargo, puede continuar reemitiendo el certificado durante la totalidad el período de validez adquirido.
Extensión CanSignHttpExchanges
Recientemente, agregamos un nuevo perfil del certificado, Intercambios firmados de HTTP para ayudar a abordar el problema de visualización de URL AMP por el que su marca no aparece en la barra de direcciones. Vea Mostrar mejores URL AMP con Intercambios firmados de HTTP.
Este nuevo perfil le permite incluir la extensión CanSignHttpExchanges en los certificados OV y EV SSL/TLS. Una vez habilitada para su cuenta, la opción Incluir la extensión CanSignHttpExchanges en el certificado, aparece en los formularios de pedido de su certificado OV y EV SSL/TLS en Opciones adicionales del certificado. Vea Obtener su certificado de Intercambios firmados de HTTP.
Para activar este perfil del certificado para su cuenta, póngase en contacto con el administrador de su cuenta o comuníquese con nuestro Equipo de asistencia.
Las CA ya no pueden emitir certificados SSL públicos de 30 días que contengan guiones bajos en los nombres de dominio (nombres comunes y nombres alternativos del sujeto).
Nota: La solución preferida respecto de los guiones bajos es renombrar los nombres de host (FQDN) que contengan los contengan y reemplazarlos en los certificados. No obstante, para aquellas situaciones en las que renombrar no sea posible, puede usar certificados privados y, en algunos casos, un certificado comodín que proteja todo el dominio.
Para obtener más detalles, vea Eliminación de los guiones bajos de los nombres de dominio.
Último día en el que puede pedir certificados SSL públicos de 30 días que contengan guiones bajos en los nombres de dominio (nombres comunes y nombres alternativos del sujeto) de cualquier CA.
Nota: La solución preferida respecto de los guiones bajos es renombrar los nombres de host (FQDN) que contengan los contengan y reemplazarlos en los certificados. No obstante, para aquellas situaciones en las que renombrar no sea posible, puede usar certificados privados y, en algunos casos, un certificado comodín que proteja todo el dominio.
Para obtener más detalles, vea Eliminación de los guiones bajos de los nombres de dominio.
Usted no necesita hacer nada.
A partir del 13 de febrero de 2019, DigiCert ya no emitirá certificado ECC TLS/SSL (es decir, certificado con claves ECDSA) con el par curva-cifrado P-384 con SHA-2 512 (SHA-512). Este par curva-cifrado no cumple con la política de almacén raíz de Mozilla.
La Política de almacén de raíz de Mozilla es compatible únicamente con estos pares de curva-cifrado:
Nota: ¿Tiene un certificado con un P-384 con par curva-cifrado SHA-512? No se preocupe. Cuando se tiempo de renovar el certificado, se emitirá automáticamente usando un par curva-cifrado compatible.
Las Autoridades de certificados (CA) revocaron todos los certificados SSL públicos que contenían guiones bajos (en el nombre común y en los nombres alternativos del sujeto) con una validez máxima de más de 30 días para el final del día (hora UTC).
Si tenía un certificado SSL con una validez total de 31 días o más (que incluye a todos los certificados de 1 año, 2 años y 3 años) que caducaba después del 14 de enero de 2019, la CA que emitió su certificado debía revocarlo.
Para obtener más detalles, vea Eliminación de los guiones bajos de los nombres de dominio.
DigiCert comenzó a emitir certificados SSL públicos que contienen guiones bajos durante un tiempo limitado.
Para obtener más detalles, vea Eliminación de los guiones bajos de los nombres de dominio.
En el menú de la parte superior, agregamos dos nuevas opciones para ponerse en contacto con la asistencia (íconos de teléfono y chat) que facilitan ponerse en contacto con la asistencia desde el interior de CertCentral (a través de un correo electrónico, chat o teléfono).
El ícono de teléfono le brinda las opciones de correo electrónico y teléfono. El ícono de chat le proporciona una ventana de chat en la que puede comenzar un chat con uno de los miembros de nuestro dedicado equipo de asistencia.
Mejoramos el menú lateral,, lo que facilita ver la opción de menú para las páginas que visita. Ahora cuando visita una página en CertCentral, la opción de menú para esa página tendrá una barra azul horizontal al lado.
Solucionamos un error en la función Agregar organización en los formularios de solicitud de certificados SSL/TLS por el que el estado de validación (EV y OV validado) no se incluía para las nuevas organizaciones agregadas y validadas como parte del pedido de certificado.
Ahora las nuevas organizaciones agregadas al pedido un certificado SSL mostrarán un estado de Validado.
Nota: El estado de validación de la organización no aparece hasta que hayamos validado la organización.
El cumplimiento de los estándares de la industria cambió. Para los certificados con confianza pública, los guiones bajos (_) ya no se pueden incluir en los subdominios. Ahora también se aplica el RFC5280 para los subdominios.
Los estándares de la industria cambiaron y eliminaron dos métodos de validación de control de dominio (DCV) de los Requisitos de base (BR).
A partir del 1 de agosto de 2018, las Autoridades de certificados ya no pueden usar los siguientes métodos de validación de control de dominio (DCV):
Para obtener más información sobre algunos de los métodos DCV disponibles, vea Métodos de validación de control de dominio (DCV).
Cumplimiento de DigiCert de GFPR
El Reglamento General de Protección de Datos (RGPD) es una ley de la Unión Europea sobre la protección de datos y la privacidad de las personas dentro de la UE: El principal objetivo es brindarles a los ciudadanos y a los residentes de la UE más control sobre sus datos personales, así como simplificar el marco regulatorio para el comercio internacional al unificar los reglamentos dentro de la UE. El RGPD entró en vigencia el 25 de mayo de 2018. Más detalles »
Declaración de DigiCert
DigiCert trabajó para comprender el RGPD y respetarlo. Estuvimos alineados con el RGPD cuando entró en vigencia el 25 de mayo de 2018. Vea Cumplimiento del Reglamento General de Protección de Datos (RGPD).
Impacto del RGPD en la validación de control de dominio (DCV) por correo electrónico basada en WHOIS
El Reglamento General de Protección de Datos (RGPD) de la Unión Europea entró en vigencia el 25 de mayo de 2018. El RGPD exige la protección de los datos de las personas naturales (no entidades jurídicas) que residen en la Unión Europea (UE).
DigiCert trabajó con ICANN para mantener la información WHOIS disponible. ICANN anunció que continúa exigiendo que los registros y los registradores envíen información a WHOIS, con algunos pocos cambios, para abordar el RGPD. Vea Una nota sobre WHOIS, RGPD y validación de dominio.
¿Confía en la validación de dominio por correo electrónico basada en WHOIS?
Verifique con el registrador de su dominio para averiguar si está usando un correo electrónico o un formulario web anonimizado como medio para que las CA accedan a los datos WHOIS como parte de su cumplimiento del RGPD.
Para obtener el proceso de validación más eficaz, hágale saber a su registrador que desea que continúe usando sus registros totalmente publicados o que use una dirección de correo electrónico anonimizada para sus dominios. Usar estas opciones garantizará un impacto mínimo o ningún impacto en nuestros procesos de validación.
¿Su registrados usa un correo electrónico o un formulario web anonimizado como un modo de que las CA accedan a los datos WHOIS? En caso afirmativo, podemos enviar el correo electrónico DCV a las direcciones que figuran en su registro WHOIS.
¿Su registrador enmascara o elimina las direcciones de correo electrónico? En caso afirmativo, usted deberá usar uno de los otros métodos para probar que tiene el control de sus dominios:
Para obtener más información sobre las direcciones de correo electrónico formadas y otros métodos DCV alternativos, vea Métodos de validación de control de dominio (DCV).
Los estándares de la industria permiten que una Autoridad de certificados (CA) emita un certificado SSL/TLS para un dominio que solo tiene registros CAA que no contienen etiquetas de propiedad "issue"/"issuewild".
Cuando una CA hace una consulta de los RR CAA de un dominio y encuentra registros sin etiquetas de propiedad "issue" o "issuewild" en ellas, una CA puede interpretar esto como un permiso para emitir el certificado SSL/TLS para ese dominio. Vea Votación 219: Aclarar el manejo de conjuntos de registros CAA sin etiqueta de propiedad "issue"/"issuewild".
Para conocer más sobre el proceso de verificación de RR CAA, vea nuestra página Verificación de registros de recurso CAA DNS.
Como parte del apartamiento de toda la industria de TLS 1.0/1.1 y para mantener nuestro cumplimiento PCI, DigiCert deshabilitó TLS 1.0/1.1 el 1 de abril de 2018. DigiCert solo es compatible con TLS 1.2 y versiones posteriores de aquí en adelante. Vea Se deja de usar TLS 1.0 y 1.1.
DigiCert implementa un proceso de verificación de unidad de organización (OU) mejorado.
Según los requisitos de base:
"La CA SHALL implementa un proceso que evita que un atributo OU incluya un nombre, DBA, nombre comercial, marca registrada, dirección, ubicación u otro texto que alude a una persona natural o entidad legal específica, a menos que la CA haya verificado esta información de acuerdo con la Sección 11.2..."
Nota: El campo OU es opcional. No es obligatorio que incluya una unidad de organización en una solicitud de certificado.
A partir del 1 de marzo de 2018, 825 días es la duración máxima permitida para un certificado SSL/TLS público de tres años reemitido (o duplicado emitido).
Para un certificado OV de tres años emitido después del 1 de marzo de 2017, tengan en cuenta que, durante el primer año del ciclo de vida del certificado de tres años, todos los certificados reemitidos y duplicados pueden tener un ciclo de vida más corto que el certificado "original," por lo que estos certificados reemitidos caducarán primero. Vea
¿Cómo afecta esto mis reemisiones de certificados de tres años y mis emisiones de duplicados?
A partir del 21 de febrero de 2018, DigiCert solo ofrece certificados SSL/TLS públicos de 1 y 2 años debido a los cambios en los estándares de la industria que limitan la duración máxima de un certificado SSL público a 825 días (alrededor de 27 meses). Vea 20 de febrero de 2018: último día para nuevos pedidos de certificados de tres años.
Esto es solo a modo informativo, no se necesita ninguna acción.
A partir del 1 de febrero de 2018, DigiCert publica todos los certificados SSL/TLS públicos recientemente emitidos en los registros de CT públicos. Esto no afecta a los certificados OV emitidos antes del 1 de febrero de 2018. Tenga en cuenta que el registro CT se exige para los certificados EV desde 2015. Vea Los certificados de DigiCert se registrarán públicamente a partir del 1 de febrero.
Nueva función "excluir del registro CT al pedir un certificado" agregada a CertCentral. Cuando activa esta función (Configuración > Preferencias), permite que los usuarios de la cuenta eviten registrar los certificados SSL/TLS públicos en los registros CT públicos por pedido de certificado.
Cuando piden un certificado SSL, los usuarios tienen una opción de no registrar el certificado SSL/TLS en los registros CT públicos. La función está disponible cuando un usuario pide un nuevo certificado, vuelve a emitir un certificado o lo renueva. Vea Guía de registro CT de certificados SSL/TLS públicos de CertCentral.
Nuevo campo de exclusión del registro CT opcional (disable_ct) para los terminales API de solicitud de certificados SSL. Además, se agregó un nuevo terminal de exclusión de certificados emitidos del registro CT (ct-status). Vea Guía de exclusión API de transparencia de certificados SSL/TLS públicos de CertCentral.
Los estándares de la industria cambian para las verificaciones del Registro de recurso CAA. Se modificó el proceso para verificar las cadenas CNAME que contienen 8 registros CNAME o menos, y la búsqueda no incluye el registro principal de un registro CNAME específico. Vea Verificar registros de recurso CAA DNS.
Los estándares de la industria cambian para la emisión de certificados. Se modificó el proceso de emisión de certificados para verificar los registros de recurso CAA DNS. Vea Verificar registros de recurso CAA DNS.
Cambios en el cumplimiento de los estándares de la industria; mejores verificaciones y aplicaciones de las violaciones a RFC5280. Vea Certificados en que el público confía: entradas de datos que van en incumplimiento de las normas del sector.
Cambio de los estándares de la industria al proceso de validación. La información de validación (DCV u organización) posterior a 825 días debe revalidarse antes de procesar una reemisión, una renovación o una emisión de un certificado. Más detalles »
Cambios en el cumplimiento de los estándares de la industria; compatibilidad agregada para los métodos adicionales de validación de control de dominio (DCV). Vea Validación previa de dominio: Métodos de validación de control de dominio (DCV).
