Caducidad y renovación de certificados S/MIME: guía para equipos de TI

Un certificado S/MIME vincula una clave pública a una dirección de correo electrónico y está firmado por una autoridad de certificación (CA). Su período de validez tiene una fecha de inicio y una fecha de fin fijas. Después de la fecha de fin:

• El cifrado para el usuario falla o genera una advertencia. Los clientes de correo generalmente se niegan a cifrar con un certificado caducado, por lo que los socios envían correo sin cifrar o no pueden enviarlo.
• Las nuevas firmas no se consideran de confianza. Los destinatarios ven una advertencia en los mensajes firmados con un certificado caducado.
• Las firmas existentes pueden seguir verificándose. Muchos clientes comprueban si el certificado era válido en el momento en que se firmó el mensaje.
• Los mensajes cifrados anteriormente siguen siendo legibles, siempre que la clave privada siga disponible.

Dicho de otro modo, la caducidad es sobre todo un problema para el correo futuro. Solo se convierte en un problema grave para el correo anterior si la clave privada se pierde durante la renovación.

Desde el 1 de septiembre de 2023, las CA de confianza pública emiten los certificados S/MIME conforme a los S/MIME Baseline Requirements del CA/Browser Forum (enlace externo). Estas normas estandarizan cómo validan las CA el control de un buzón y la identidad de su titular, definen perfiles de certificado y limitan el período de validez. Para los perfiles estricto (strict) y multipropósito (multipurpose) que se utilizan actualmente, el máximo es de 825 días, algo más de dos años.

Los requisitos también definen tipos de validación. Un certificado validado por buzón (mailbox-validated) solo confirma el control de la dirección de correo electrónico, mientras que los certificados validados por organización, por patrocinador o por persona física (organization-, sponsor- e individual-validated) también contienen datos verificados de la organización o de la persona. Elija el tipo que se corresponda con la forma en que los destinatarios confiarán en sus firmas.

Las distintas CA suelen emitir certificados de uno o dos años, y el CA/Browser Forum ha acortado en repetidas ocasiones la validez máxima de los certificados de servidor TLS. Es sensato tratar la renovación de S/MIME como un proceso rutinario y recurrente, no como un acontecimiento ocasional.

Los certificados de una CA privada, como la que se opera en un servicio de PKI en la nube, no están sujetos a estas normas públicas, pero solo son de confianza para los sistemas que tienen instalada la raíz privada. Nuestra página sobre las autoridades de certificación externas y privadas explica las ventajas e inconvenientes de cada opción.

Claves privadas perdidas

Si se sustituye un dispositivo, o se vuelve a emitir un certificado con un nuevo par de claves, y no se conserva la clave privada antigua, todos los mensajes cifrados para el certificado antiguo se vuelven ilegibles. Las organizaciones que deben conservar el correo necesitan un historial de claves: el almacenamiento seguro de las claves de cifrado anteriores de cada usuario.

Los socios aún tienen el certificado antiguo

Los socios cifran con el certificado que tienen registrado. Hasta que reciben el nuevo, normalmente a partir de un mensaje firmado o de una búsqueda en un directorio, el correo que le envían puede fallar o llegar sin cifrar.

Renovación mediante recordatorios en el calendario

Las hojas de cálculo y los recordatorios no escalan a cientos o miles de buzones personales, buzones compartidos y cuentas de servicio, cada uno con una fecha de caducidad distinta.

Dispositivos desincronizados

Un certificado renovado en un equipo portátil pero no en un teléfono deja al usuario sin poder leer el correo cifrado en el dispositivo que conserva la clave antigua o que no tiene ninguna.

Faltan certificados intermedios

De vez en cuando, las CA cambian los certificados intermedios a partir de los cuales emiten. Si la nueva cadena no se envía con los mensajes firmados ni se publica junto con el certificado, algunos destinatarios no pueden validar la firma.

Los certificados no son solo para personas. Los buzones compartidos, como las direcciones de facturación o del departamento jurídico, y los sistemas que envían notificaciones firmadas también necesitan certificados, y son los que con más frecuencia se olvidan porque no pertenecen a ninguna persona concreta.

Los cambios de personal también requieren un proceso. Cuando alguien se marcha, revoque o retire su certificado de firma, pero mantenga sus claves de cifrado a disposición del personal autorizado si la organización debe seguir pudiendo leer el correo enviado a esa persona. La revocación indica a las partes que confían en un certificado que dejen de confiar en él antes de su fecha de fin, por ejemplo cuando se sospecha que la clave se ha visto comprometida.

El objetivo es eliminar los pasos manuales de la emisión, la distribución y la renovación:

• Intégrese con la CA. Solicite y renueve los certificados a través de la interfaz de la CA en lugar de hacerlo manualmente. El RFC 8823 (enlace externo) amplía el protocolo ACME a los certificados S/MIME de usuario final, aunque la compatibilidad de las CA varía.
• Centralice las claves. Genere y almacene las claves en un servicio gestionado, para que la renovación no dependa de dispositivos individuales.
• Publique automáticamente. Ponga los nuevos certificados a disposición a través de un directorio como LDAP, para que los socios puedan encontrarlos.
• Firme el correo saliente. Los mensajes firmados incluyen el certificado del remitente, lo que permite a los socios actualizar su copia.
• Supervise la caducidad. Haga un seguimiento de todos los certificados y emita alertas con mucha antelación a su fecha de fin.

Un modelo de pasarela gestiona gran parte de esto de forma centralizada. Nuestras páginas sobre la gestión del ciclo de vida de los certificados S/MIME y sobre la emisión y renovación de certificados con S/MIME alojado en la nube describen cómo CloudPGP da soporte a estos flujos de trabajo, así como las integraciones con autoridades de certificación con las que funciona.

1. Haga un inventario de todos los certificados, incluidos los de buzones compartidos y cuentas de servicio, con su CA, su perfil y su fecha de caducidad.
2. Defina una política de claves. Decida si la renovación utiliza un nuevo par de claves y conserve las claves de cifrado anteriores durante todo el tiempo que el correo deba seguir siendo legible.
3. Empiece con antelación. Renueve mucho antes de la caducidad, para que los socios reciban el nuevo certificado a tiempo.
4. Distribuya el nuevo certificado a través de su directorio y del correo firmado.
5. Verifique de extremo a extremo intercambiando mensajes firmados y cifrados con algunos socios importantes.

Si su organización aún está decidiendo entre estándares, nuestra comparación de PGP frente a S/MIME para el correo electrónico empresarial expone en qué se diferencian sus modelos de claves y certificados.