Filtro por: compliance x borrar
compliance

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:

  • Take inventory of needed 2-year certificates—new and renewals.
  • Order any 2-year certificates that you need before August 13.
  • Respond to any domain and organization validation requests in a timely manner.

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.

new

Multi-year Plans now available

We are happy to announce that Multi-year Plans are now available in CertCentral and CertCentral Partners.

DigiCert® Multi-year Plans allow you to pay a single discounted price for up to six years of SSL/TLS certificate coverage. With Multi-year Plans, you pick the SSL/TLS certificate, the duration of coverage you want (up to six years), and the certificate validity. Until the plan expires, you reissue your certificate at no cost each time it reaches the end of its validity period.

The maximum validity of an SSL/TLS certificate will go from 825 days to 397 days on September 1, 2020. When the active certificate for a Multi-year Plan is about to expire, you reissue the certificate to maintain your SSL/TLS coverage.

compliance

Browser support for TLS 1.0 and 1.1 has ended

The four major browsers no longer support Transport Layer Security (TLS) 1.0 and 1.1.

What you need to know

This change doesn't affect your DigiCert certificates. Your certificates continue to work as they always have.

This change affects browser-dependent services and applications relying on TLS 1.0 or 1.1. Now that browser support for TLS 1.0 and 1.1 has ended, any out-of-date systems will be unable to make HTTPS connections.

What you need to do

If you are affected by this change and your system supports more recent versions of the TLS protocol, upgrade your server configuration as soon as you can to TLS 1.2 or TLS 1.3.

If you do not upgrade to TLS 1.2 or 1.3, your webserver, system, or agent will not be able to use HTTPS to securely communicate with the certificate.

Browser TLS 1.0/1.1 deprecation information

Firefox 78, released June 30, 2020

Safari 13.1, released March 24, 2020

Chrome 84, released July 21, 2020

Edge v84, released 7/16/2020

Helpful resources

With so many unique systems relying on TLS, we can't cover all upgrade paths, but here are a few references that may help:

enhancement

CertCentral Services API: Updated error message documentation

In the Services API documentation, we've updated the Errors page to include descriptions for error messages related to:

  • Immediate DV certificate issuance
  • Domain control validation (DCV)
  • Certificate Authority Authorization (CAA) resource record checks

Earlier this year, we improved the APIs for DV certificate orders and DCV requests to provide more detailed error messages when DCV, file authorization, DNS lookups, or CAA resource record checks fail. Now, when you receive one of these error messages, check the Errors page for additional troubleshooting information.

For more information:

compliance

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:

compliance

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.

compliance

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:

  • Debe usar un algoritmo de la familia SHA-2 en el algoritmo de firma. Los certificados SSL/TLS firmados SHA-1 ya no son fiables.
  • Deben tener un período de validez de 825 días o menos. Los certificados SSL/TLS con una validez mayor a los 825 días ya no gozan de confianza.

¿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:

compliance

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

  • Podrá seguir usando Firefox 69 para la autenticación de clientes. En primer lugar, genere un certificado SMIME en IE 11 o Safari. Luego importe el certificado SMIME a Firefox.
  • Para evitar generar certificados de firma de código, de cliente o SMIME en su navegador, genere y envíe una CSR junto con su pedido. En lugar de un enlace, DigiCert le enviará un correo electrónico con su certificado adjunto.
new

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).

enhancement

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).

compliance

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:

  • Estado o provincia*
  • Ciudad o localidad*

* Esto vale para las direcciones de las organizaciones y jurisdicciones.

new

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:

  • Enviar los nombres exactos de los dominios para validarlos
    Con esta opción, las solicitudes de nuevos dominios se envían a validar con el mismo nombre que se les dio (es decir, la solicitud para sub.ejemplo.com se envía a validar como sub.ejemplo.com). También funciona la validación para el dominio de “nivel superior” (por ejemplo, ejemplo.com). Este es el comportamiento predeterminado de CertCentral.
  • Limitar la validación únicamente a los dominios base
    Esta opción le deja restringir la validación de dominio al dominio base (por ejemplo, ejemplo.com). Para las solicitudes que incluyan nuevos subdominios (por ejemplo, sub.ejemplo.com), solo aceptamos validaciones de dominio del dominio base (por ejemplo, ejemplo.com). La validación para el subdominio (por ejemplo, sub.ejemplo.com) no funcionará.

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.

fix

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.

compliance

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.

enhancement

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.

new

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.

  • Secure Site Pro SSL
    Obtenga el certificado OV que se ajusta a sus necesidades. Proporcione cifrado y autenticación para un dominio, un dominio con comodín y todos sus subdominios, o use nombres alternativos del sujeto (SAN) para proteger varios dominios y dominios con comodín con un certificado.
  • Secure Site Pro EV SSL
    Obtenga el certificado de validación ampliada que se ajusta a sus necesidades. Proporcione cifrado y autenticación para proteger un dominio o use nombres alternativos del sujeto (SAN) a fin de proteger varios sitios (nombres de dominio completo) con un certificado.

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:

  • Validación prioritaria
  • Asistencia de prioridad
  • Dos sellos del sitio de primera calidad
  • Verificación de malware
  • Garantías líderes de la industria

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.

compliance

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.

compliance

Requisitos del estándar de la industria para incluir la extensión CanSignHttpExchanges en un certificado ECC SSL/TLS:

  • El registro de recursos CAA para el dominio que incluye el parámetro "cansignhttpexchanges=yes" *
  • Par de claves de criptografía de curva elíptica (ECC)
  • Extensión CanSignHttpExchanges
  • Validez máxima de 90 días*
  • Solo usado para el Intercambio firmado de HTTP

* 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.

compliance

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.

compliance

Ú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.

compliance

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:

  • P‐256 con SHA-256
  • P‐384 con SHA-384

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.

compliance

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.

compliance

DigiCert comenzó a emitir certificados SSL públicos que contienen guiones bajos durante un tiempo limitado.

  • La validez máxima es de 30 días para los certificados SSL públicos que contienen guiones bajos en los nombres de dominio.
  • Los guiones bajos no deben estar en el dominio base ("example_domain.com" no está permitido).
  • Los guiones bajos no deben estar a la izquierda de la mayoría de las etiquetas de dominio ("_ejemplo.dominio.com" y "example_domain.ejemplo.com" no están permitidos).

Para obtener más detalles, vea Eliminación de los guiones bajos de los nombres de dominio.

new

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.

enhancement

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.

fix

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.

compliance

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 en que el público confía: entradas de datos que van en incumplimiento de las normas del sector.

Agosto 1, 2018

compliance

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):

  • 3.2.2.4.1 Validación del solicitante como un contacto del dominio
    Este método le permitía a una CA validar el control del solicitante del certificado respecto de un dominio en un pedido de certificado SSL/TLS verificando que dicho solicitante fuera el contacto del dominio directamente con el Registro de nombres de dominios.
  • 3.2.2.4.5 Documento de autorización de dominio
    Este método le permitía a una CA validar el control del solicitante del certificado respecto de un pedido de certificado SSL/TLS usando la confirmación de la autoridad del solicitante para pedir un certificado para dicho dominio, según lo contenido en un Documento de autorización de dominio.
    Vea Votación 218: eliminar métodos de validación 1 y 5.

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).

Mayo 25, 2018

compliance

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).

compliance

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:

  • Por correo electrónico formado
  • DNS TXT
  • DNS CNAME
  • Demostración práctica de HTTP

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).

Mayo 10, 2018

compliance

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.

Abril 1, 2018

compliance

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.

Marzo 2, 2018

compliance

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.

compliance

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?

Febrero 21, 2018

compliance

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.

compliance

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.

enhancement

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.

enhancement

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.

Octubre 24, 2017

compliance

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.

Septiembre 8, 2017

compliance

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.

Julio 28, 2017

compliance

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.

Julio 21, 2017

compliance

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 »

Julio 10, 2017

compliance

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).