¿Está bien tener certificados autofirmados en el control de origen?

7

Acabo de hacer la pregunta

Certificados autofirmados SSL en desarrollo vs certificado adquirido en producción?

que ha sido respondido rápidamente (¡GRACIAS!).

Fuera de eso, tengo la siguiente pregunta:

  • ¿Es correcto tener mis certificados autogenerados y autofirmados en el control de fuente?

En general, sé que las contraseñas, etc. no deberían estar en control de código fuente. Pero como estos certificados se usan solo para desarrollo y prueba, pensé que no habría ningún problema?

El problema es que usamos codeship para la implementación, y allí no puedo ejecutar scripts para copiar cosas ... así, la única manera Veo que implementar los componentes es tenerlos en control de origen (aunque tendré que averiguar cómo hacerlo para la producción, pero eso es un problema diferente).

    
pregunta fablife 26.01.2016 - 23:36
fuente

3 respuestas

10

Los secretos, tanto las claves privadas como las contraseñas, no deben almacenarse en el control de fuente. Cuando sea posible, los certificados autofirmados también deben reemplazarse por certificados firmados centralmente.

El software como Vault facilita la distribución de secretos y, lo que es más importante, su renovación.

De esta manera, puede configurar sus máquinas de desarrollo con un nivel de control y mantenerse alejado del mal hábito de los secretos en el control de código fuente, porque incluso si son un certificado autofirmado, siguen siendo un mal hábito. Las cosas que están destinadas a ser de bajo valor o asegurar cosas sin importancia a menudo se vuelven importantes más tarde y se olvidan.

Configúralo a la derecha y sigue con él.

    
respondido por el Jeff Ferland 26.01.2016 - 23:47
fuente
2

Si solo está hablando sobre el certificado, no hay ninguna razón criptográfica para no ponerlo bajo control de origen, ya que los certificados están diseñados para ser públicos. Aún debe asegurarse de no filtrar ninguna información de propiedad exclusiva en los metadatos del certificado, como los nombres X.509 de las entidades privilegiadas.

Si también piensa almacenar la clave secreta en el repositorio, es como almacenar una contraseña. Entonces, de hecho, creó una "cuenta" compartida entre todos los usuarios que tienen acceso al repositorio o una copia de trabajo, por lo que se aplican todos los problemas de las cuentas compartidas. Las implicaciones de seguridad dependen de lo que pueda hacer el poseedor de la clave secreta. Si ese certificado permite iniciar sesión en algunos sistemas de producción, está condenado, mientras que en el otro extremo, si el único uso de la clave y el certificado es en la prueba de su producto, y no se acepta en ningún otro lugar, no se hace daño. En este último caso, podría considerar generar el certificado durante la prueba sobre la marcha. Hay puntos válidos tanto para usar una clave / certificado de prueba fija como para generarlos sobre la marcha, pero esta discusión ya no está relacionada con la seguridad de TI, sino con el código fuente y la administración de la compilación.

    
respondido por el Michael Karcher 27.01.2016 - 17:47
fuente
0

Hablando de la experiencia, es común tener certificados autofirmados para la dirección de su (s) máquina (s) local (es) para probar TLS / SSL antes de invertir en comprar un certificado. Tendrá que insertar manualmente el certificado en el navegador que usará para probar el sitio web si está hablando de una conexión a un sitio web.

Todavía no publicaría la clave privada del servidor en el control de origen si fuera accesible al público, pero siempre que la clave privada del certificado sea diferente de la que se está implementando, no veo mucho daño en generar una nueva firma automática. Los certificados son un procedimiento fácil.

    
respondido por el Seth M. Larson 26.01.2016 - 23:47
fuente

Lea otras preguntas en las etiquetas