Browser support ending for TLS 1.0 and 1.1
In 2020, the four major browsers are ending support for Transport Layer Security (TLS) 1.0 and 1.1.
This change doesn't affect your DigiCert certificates. Your certificates will continue to work as they always have.
What you need to know
This change affects browser-dependent services and applications relying on TLS 1.0 or 1.1. Once browser support for TLS 1.0 or 1.1 ends, these out-of-date systems will be unable to make HTTPS connections.
What you need to do
If you are affected by this change, plan to enable or upgrade to TLS 1.2 or TLS 1.3 now. Give yourself lead time to deal with any problems. Before you start, make sure to identify all systems that might use TLS 1.0 or 1.1.
Remember to check web servers like Apache or Microsoft IIS, .NET Framework, server monitoring agents, and other commerce applications that might use it.
Helpful resources
With so many different types of systems relying on TLS, we can't cover all available upgrade paths, but here are a few references that may help:
Microsoft is sunsetting support for third-party kernel-mode driver package digital signatures
The process for signing your kernel-mode driver packages is changing. Starting in 2021, Microsoft will be the sole provider of production kernel-mode code signatures. You will need to start following Microsoft’s updated instructions to sign any new kernel-mode driver packages going forward. See Partner Center for Windows Hardware.
What is DigiCert doing about this?
As a first step in this sunsetting process, DigiCert has removed the Microsoft Kernel-Mode Code platform option from Code Signing certificate request forms: new, reissue, and renew.
This means going forward, you can no longer order, reissue, or renew a code signing certificate for the kernel-mode platform.
How does this affect my existing kernel-mode Code Signing certificate?
You can continue to use your existing certificates to sign Kernel-Mode driver packages until the cross-signed root it is chained to expires. DigiCert brand cross-signed root certificates expire in 2021.
For more details, see our knowledgeable article, Microsoft sunsetting support for cross-signed root certificates with kernel-mode signing capabilities.
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 a los certificados públicos y privados emitidos después 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. Por suerte, los lanzamientos de estas versiones de SO de Apple se anuncian para el otoño de este año. Esto significa que tiene tiempo para prepararse.
Si tiene certificados privados que no cumplen con estos requisitos, y se exige la confianza de iOS de Apple y macOS para sus certificados privados, deberá garantizar que los certificados SSL/TLS privados emitidos después el 1 de julio de 2019 están inicialmente emitidos o reemitidos antes de la disponibilidad general de iOD 13 y macOS 10.15. Vea Reemisión de un certificado SSL/TLS.
Firefox ending key generation support
With the release of Firefox 69, Firefox will finally drop support for Keygen. Firefox uses Keygen to facilitate generating key material for submitting the public key when generating Code Signing, Client, and SMIME certificates in their browser.
Note: Chrome already dropped support for key generation, and Edge and Opera never supported it.
How does this affect you?
After DigiCert issues your Code Signing, Client, or SMIME certificates, we send you an email with a link to create and install your certificate.
Once Firefox 69 is released, you can only use two browsers to generate these certificates: Internet Explorer and Safari. If company policy requires the use of Firefox, you can use Firefox ESR or a portable copy of Firefox.
For more information, see Keygen support to be dropped with Firefox 69.
Tips and tricks
We added a new status, Emailed to Recipient, to the Orders and Order Details pages, for Code Signing and Client certificate orders, making it easier to identify where these orders are in the issuance process.
This new status indicates the DigiCert has validated the order, and the certificate is waiting for the user/email recipient to generate it in one of the supported browsers: IE 11, Safari, Firefox 68, and portable Firefox.
(In the sidebar menu, click Certificates > Orders. Then, on the Orders page, click the order number for the Code Signing or Client certificate order.)
We updated our Extended Validation (EV) Code Signing (CS) and Document Signing (DS) certificate reissue processes, enabling you to reissue these certificates without automatically revoking the current certificate (original or previously reissued certificate).
Note: If you don't need the current certificate (original or previously reissued certificate), you'll need to contact support so they can revoke it for you.
Now, the next time you reissue an EV CS or DS certificate, you can keep the previously issued certificate active to its current validity period (or for as long as you need it).
Industry standards compliance reminder
For public and private certificates, Certificate Authorities (CAs) don't accept abbreviations for these parts of an address in your certificate orders or organization pre-validation requests:
*This applies to organization and jurisdiction addresses.
We made it easier to define the domain validation scope for your account when submitting your domains for validation (pre-validation or via certificate orders).
On the Division Preferences page, we added two domain validation scope options:
To configure the domain validation scope for your account, in the sidebar menu, click Settings > Preferences. On the Division Preference page, expand Advanced Settings. In the Domain Control Validation (DCV) section, under Domain Validation Scope, you'll see the new settings.
We fixed a bug where we were limiting the maximum allowed number of SANS to 10 on Wildcard SSL certificate reissue and new certificate orders.
Now, when reissuing or ordering a new Wildcard SSL certificate, you can add up to 250 SANs.
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-hash P-384 con SHA-2 512 (SHA-512). Este par curva-hash 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-hash:
Nota: ¿Tiene un certificado con un P-384 con par curva-hash SHA-512? No se preocupe. Cuando se tiempo de renovar el certificado, se emitirá automáticamente usando un par curva-hash 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.
Vea Certificados con confianza pública: entradas de datos que violan los estándares de la industria.
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 demostrar 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) agregado a las terminales API de solicitud de certificados SSL. Además, se agregó una nueva 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 con confianza pública: entradas de datos que violan los estándares de la industria.
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).
