Filtro por: compliance x borrar
compliance

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:

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

  • Debe usar un algoritmo de la familia SHA-2 en el algoritmo de firma. Los certificados firmados SHA-1 ya no son confiables para SSL/TLS.
  • 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.

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.

compliance

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

  • You can still use Firefox 69 for client authentication. First, generate the SMIME certificate in IE 11 or Safari. Then, import the SMIME certificate to Firefox.
  • To bypass generating Code Signing, Client, or SMIME certificates in your browser, generate and submit a CSR with your order. Instead of a link, DigiCert will send you an email with your certificate attached.
new

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

enhancement

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

compliance

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:

  • State or Province*
  • City or Locality*

*This applies to organization and jurisdiction addresses.

new

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:

  • Submit exact domain names for validation
    With this option, requests for new domains are submitted for validation exactly as named (i.e., request for sub.example.com is submitted for validation exactly as sub.example.com). Validation for the “higher level” domain (e.g., example.com) also works. This is the default behavior for CertCentral.
  • Restrict validation to base domain only
    This option allows you to restrict domain validation to the base domain (e.g., example.com). For request that include new subdomains (e.g., sub.example.com), we only accept domain validation for the base domain (e.g., example.com). Validation for the subdomain (e.g., sub.example.com) won’t work.

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.

fix

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.

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

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

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.

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 con confianza pública: entradas de datos que violan los estándares de la industria.

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 demostrar que tiene el control de sus dominios:

  • Por correo electrónico formado
  • DNS TXT
  • DNS CNAME
  • Demostración práctica 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) 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.

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 con confianza pública: entradas de datos que violan los estándares de la industria.

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