¿Existe un certificado SSL que no caduca?

Efectivamente, sí: puede generar su propio certificado raíz (es decir, convertirse en su propia autoridad de certificación) y luego firmar cada CSR de certificado SSL con la clave raíz. Luego podrá establecer la fecha de caducidad en el futuro (por ejemplo, utilizar una estimación de vida útil del producto muy optimista) en el certificado SSL instalado en cada dispositivo. El único problema con el ungüento es que su certificado raíz deberá estar instalado como una raíz de confianza en cada web de cliente Navegador que accede a las funciones de administrador. Si esto es demasiado complicado para sus usuarios, podrían simplemente confiar en cada certificado individualmente , lo que puede ser más fácil. En realidad, después de haber pensado un poco más en esto, cada certificado individual debería estar vinculado a un determinado nombre de host o dirección IP de todos modos para evitar otras advertencias del navegador (por ejemplo, el nombre del host del certificado no coincide con el nombre del host real) para que su nombre de host Tendría que ser "codificado" en el dispositivo. Como esto no es práctico, cada usuario deberá hacer clic en la advertencia del navegador para acceder al dispositivo. La solución es que deberá hacerlo para que ellos mismos puedan actualizar el certificado para eliminar por completo las advertencias del navegador o podrían hacer que el dispositivo genere su propio certificado.

Mi ZyXel NAS ofrece la funcionalidad para generar la suya propia y permite que se establezca el nombre común para el certificado:

Lageneracióndesuspropioscertificadostendrálosmismosbeneficiosdecifradodelusodelasautoridadesdecertificaciónpúblicasy,comolosdispositivosindividualestendránsuspropiosnombresdehostprivados,estasoluciónpodríasermásadecuadaqueutilizarunaCApública. Certificados de Intranet están disponibles ( pero se están eliminando ), pero como requieren un nombre de dominio completo o una dirección IP, sus clientes necesitarán actualízalos ellos mismos en el dispositivo.

Consulte este artículo para obtener información detallada sobre cómo esto funciona.

No, y hay varias razones para ello:

• Un certificado no solo contiene información sobre el propietario, sino que también contiene su clave pública. La clave privada coincidente solo es conocida por el propietario del certificado, y mediante el uso de la criptografía de clave pública se podría verificar que el punto final de la conexión SSL es realmente el propietario (o al menos el que tiene la clave privada). El certificado en sí está firmado por una agencia de certificación en la que el navegador confía (todo esto está simplificado). Pero, la fuerza criptográfica de todo esto depende del tamaño de las claves y los algoritmos utilizados. El aumento del tamaño hace que todo sea más lento, mientras que el tamaño hace que todo sea menos seguro. Y como las computadoras se vuelven más rápidas y los expertos en criptografía solo mejoran y al encontrar nuevas formas de descifrar un algoritmo, la protección criptográfica del certificado se debilita con el tiempo. Por lo tanto, cada certificado debe caducar antes de que la protección se debilite.

• Un certificado podría quedar comprometido, por ejemplo, algún tipo malo o agencia puede obtener la clave privada y, por lo tanto, identificarse como el propietario o descifrar todo el tráfico. En este caso, el certificado se revoca y la información de revocación se hace pública. Si el certificado nunca caducara, esta información debería conservarse para siempre y el tiempo de almacenamiento necesario y el tiempo para verificar un certificado para su revocación aumentarán. Es así como los certificados de usuario final más baratos tienen un tiempo de caducidad más corto que los certificados más caros, porque los usuarios finales de mentalidad económica probablemente tampoco protejan su clave privada, por lo que es bueno que sus revocaciones se puedan desechar después de la fecha de caducidad.

RFC 5280, Sección 4.1.2.5 ("Validez") responde técnicamente a tu pregunta exactamente.

En resumen, un certificado con una fecha de caducidad de 99991231235959Z (23:59 GMT del 31 de diciembre de 9999) cumple con sus requisitos exactos, pero el RFC 5280 también requiere que tenga que poder revocar ese certificado para romper el ruta de certificación (es decir, revocando el certificado) antes de esta fecha.

La fecha de caducidad también se considera una fecha en la que el usuario debe revisar si las medidas técnicas vigentes siguen cumpliendo con los estándares actuales (por ejemplo, si deberían actualizar de un módulo de 1024 bits a un módulo de 2048 bits, o actualizar su servidor desde DES a AES).

Por la misma razón, las CA comerciales acuerdan no emitir certificados por más de 3 años en el futuro y requieren nombres de DNS que se puedan resolver públicamente en el espacio de IP público; lo más probable es que ambos requisitos sean bloqueadores para usted.

Al final, solo hay dos opciones:

• conviértase en su propia CA raíz y emita dichos certificados automáticamente. Una política para emitir certificados "para siempre" no cumple con las consideraciones de seguridad de los proveedores de navegadores y sistemas operativos, por lo que esto finalmente requerirá que los usuarios importen su CA raíz manualmente. Aconsejar a sus usuarios que confíen en su CA raíz es una operación sensible y puede que no encuentre una buena aceptación entre sus usuarios. Es posible que la CA esté usando restricciones de nombre x509 (por lo que los certificados emitidos solo son válidos para algunos dominios o subredes IP), pero todos los que tengan cierta seguridad en mente seguirán cuestionándose si es una buena idea seguir ese camino. En resumen: esto puede ser muy complejo, complicado y arriesgado, no hagas esto.

• en la fabricación o "restablecer la configuración de fábrica", genere una clave privada individual en y / o para cada dispositivo y emita un certificado autofirmado con una fecha de caducidad de, por ejemplo, 10 años en el futuro (o la fecha especial mencionada anteriormente). La documentación debe solicitar a sus usuarios que eliminen los certificados previamente instalados después de "restablecer la configuración de fábrica" e importar ese certificado específico para evitar la advertencia del navegador. Karma adicional para explicar al usuario por qué se debe hacer esto :)

Recuerde que cuando use la fecha "para siempre", es posible que el certificado se vuelva "menos seguro" o "inválido". Como ejemplo, los navegadores y los sistemas operativos sí dictan una longitud de clave mínima o algoritmos (rotos) para rechazar y actualizar esos requisitos en consecuencia. En este momento, 1024 bits pueden "funcionar", pero los navegadores comienzan a mostrar las conexiones utilizando menos 2048 bits para "no ser seguros" o como "no válidos". Y los algoritmos también se rompen hasta el punto en que los navegadores ya no confían en ellos. Si su certificado autofirmado hace uso de esto, deberá actualizarlo en consecuencia.