thinkboxsoftware/sslgeneration

A simple python script for generating openssl certificates.

sslgeneration's Issues

OpenSSL version is broken

The OpenSSL version specified in requirements.txt doesn't work:

Steps to reproduce:

1. On Ubuntu 18.04, install pip through apt-get install python-pip
2. pip install -r requirements.txt
3. Open Python shell by typing "python" in bash
4. import OpenSSL
5. Error..

This issue also occurs in the Deadline RCS installer if you ask it generate certificates on Linux

How to use this in immutable deployments?

I'm finding it difficult to apply this to an immutable deployment of Deadline DB, previously installed in an image.

The image itself cannot contain certs, so the installer must be used without any of the auth abilities enabled. This script then must be used somehow to generate the certs in user data (AWS EC2). There is no documentation on the steps required to generate the certs and configure deadline in this way, though it it be very helpful to know how to do this for usage in AWS, onsite VM's, and docker.

Security vulnerability: Improvements needed to avoid transfer of private keys - Doesn't follow best practice for certs

The steps listed here circumvent best practice with SSL certificates, and security could be improved for modern best practice:
https://docs.thinkboxsoftware.com/products/deadline/10.1/1_User%20Manual/manual/proxy-sslgen.html

• The private key should be able to be generated on a client machine without needing to be transferred to the signer, only the pubkey is needed to be signed by a CA. This doesn't occur because the instructions generate both the private key and cert in the same location. Transfer of both are required with the current workflow and that should be avoided. Only a public key should be required to be sent from a client to a server where it would be signed with the CA, and the public certificate is all that should need to be returned.

• The deadline DB should be configured to accept all certs signed by the CA, and a unique cert per host transferred over the wire would be best practice.

• The current workflow seems to suggest that a PKCS#12 container is sent over the wire to any of the deadline clients and since this contains both the client private key it is a vulnerability because this should not be necessary if following best practice with signing of public certs.

• For machines not used by humans (render nodes) passwords should not be necessary. If only pub keys and certs are required to to sent over the wire, this requirement shouldn't need to be recommended and would be more inline with AWS.