longevidad maxima de un certificado autofirmado?

garlor

voy a montar en algun momento un servidor de puppet y como la seguridad me importa un pito pero ha de tener un certificado por narices quiero ponerle uno que dure lo maximo posible, jugando con certificados para otro asunto vi que aunque al crearlo le pusiera 99999 dias de longevidad luego cuando miraba el certificado ya hecho me decia que el certificado era valido hasta "solo" 2038

es esto lo maximo que permite el standard o como funciona el tema?, cuando busco por google solo me sale info de la duracion de los certificados ssl para webs y mierdas asi

Dream-MV

Hasta 2038 te deberia sobrar, a saber como va la tecnologia de aqui a alli

1 respuesta
garlor

#2 en la organizacion donde trabajo igual en un tiempo se dan cuenta que estamos en el siglo XXI xD, asi que 2038 esta aqui al lado

tenemos servidores en smb1, cuando smb2 salio en 1999

1 respuesta
Dream-MV

Si, pero los certificados es una cuestion basada en cuestiones de cifrado y demas, es muy probable que la estructura cambie en ese tiempo 17 años esta bien.

1 respuesta
garlor

#4 si hoy instalo un servidor y unos clientes que en los proximos 25 años no se van a tocar, da igual lo que cambie la estructura

bloodhound

Y por qué no le metes let’s encrypt y a correr?

1 respuesta
garlor

#6 es un servidor que estara dentro de la lan y dara servicio a clientes que estaran dentro de la lan, el certificado del servidor no deberia cambiar durante la operacion del servicio, un certificado tls para web tendra una longevidad maxima de 2 años, si he dicho que una longevidad de 17 me parece poco, tu porque crees que no lo uso?, o hay alguna manera de que let's encrypt de certificados para 25 o 50 años?

bloodhound

Let’s Encrypt te los renueva automáticamente con el Certbot. Entonces te da igual tener uno que dure milenios, a tener uno que se va renovando indefinidamente.

Pero vamos, quizás no se adapte a tus necesidades.

1 respuesta
AikonCWD

con openssl puedes autofirmar certificados, incluso programar un script que te genere uno nuevo cada 12 meses y así nunca caducará. Realmente la longitud máxima la desconozco pero nunca debería ser un handicap.

1 respuesta
garlor

#8 y let's encrypt me renovara el certificado cambiado en cada uno de los cientos de ordenadores que se conectan al servidor?

#9 si lo vi con el openvpn, pero los certificados pem que utiliza puppet funcionan igual?, si mal no recuerdo no genero un certificado con una ca y despues un certificado de servidor para ese nombre de host, sino un certificado servidor privado y un certificado servidor publico, en los propios manuales de puppet te dice como cambiarlo antes de que caduque, pero que si caduca las jodio

1 respuesta
AikonCWD

#10 puedes generar tanto CA como certificados PK, ahora cuando entre a currar lo miro más que nada por la curiosidad de la longitud máxima.

1 respuesta
garlor

#11 entiendo que lo de la CA seria lo suyo, pero no se si el servidor puede funcionar asi, apenas tengo experiencia con certificados

1 respuesta
AikonCWD

#12 Los certificados se pueden enerar, pero para que un equipo lo considere válido, necesita que su cadena de trust-CA sea completa. Windows (y el resto de sistemas) tienes un número concreto de CAs instaladas, de empresas con alta reputación reconocidas por todo el mundo.

Cualquier certificado será válido siempre que alguna de esas CAs lo valide como tal.

Si tu generas un autofirmado con una CA propia, solo tienes que instalar la CA en cualquier equipo para que acepte tu certificado autofirmado como seguro.

edit: aqui hay un ejemplo que se explica muy bien https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/

1 1 respuesta
AikonCWD

doble post: este ejemplo es mejor https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309

garlor

#13 si eso lo entiendo, pero ese no es el unico esquema posible no?, simplemente el mas utilizado, tambien se pueden usar certificados con solo par publico/privado
bueno cuando vaya presencial miro un cliente a ver que certificados tiene en el directorio del puppet ( son linux, no estan en el sistema sino en los directorios de la propia aplicacion )

1 respuesta
tDarka

Lo del 2038 es por el tema de los 32bits. Algunos temen el 2038 por aplicaciones y hardware viejo como temían el 2000 en su momento.

Ojala una hornada de películas malas rollo acabose como las de entonces.

1 respuesta
AikonCWD

#15 pues supongo que sí pero mi corta experiencia haciendo estas cosas siempre han pasado por generar una CA propia.

garlor

bueno, como veo que no hay muchas opciones de lo que pido pues si a los que han de dar el visto bueno les parece corto 2038 que pregunten como generar un certificado mas largo a los de sistemas

#16 efecto 2038 suena muy poco sexy para hacer peliculas sobre eso xD

B

En 2036 empezará la fiesta de los problemas con las fechas...

February 7, 2036 (Y2036) for the Network Time Protocol
January 19, 2038 (Y2038) for signed 32-Bit Unix epoch values (system time, filesystems)
February 7, 2106 (Y2106) for unsigned 32-Bit Unix epoch values (system time, filesystems)
January 1, 2108 for FAT timestamps

El problema del año 2000 tenía que ver con como algunos programas representaban la fecha. Para el software el año 01-01-00 era el 01-01-1900 y no el 01-01-2000...

El problema con el año de 2038 tiene más calado... no es insalvable pero es más jodido. La solución por la que se pasa es la de operar con fechas en modo texto :D pero lo que se estima es que para esas fechas la mayoría de los equipos opere con 64bits. Además de que no todos los sitemas necesitan de tener una fecha exacta para operar con normalidad.

B

#3 por literalmente cosas como esas dejé sistemas.

el mundo no revienta porque alguien con un poco de idea no quiere.

Usuarios habituales

Tags