Things we need to provide to customers
pip user: some-pip-user
pip password: my-pip-password
We need to create the password by inventing an 8-character password and then entering it into openssl passwd and putting the resulting value into the salt pillar data
We need to find out if they use a custom root CA
These are the DNS entries that we need for local install:
app.authentise.<TLD> callback.authentise.<TLD> cerebro.authentise.<TLD> data.authentise.<TLD> db.authentise.<TLD> erp.authentise.<TLD> estimates.authentise.<TLD> events.authentise.<TLD> geometricsearch.authentise.<TLD> gigan.authentise.<TLD> installers.authentise.<TLD> integrations.authentise.<TLD> logs.authentise.<TLD> mes.authentise.<TLD> models.authentise.<TLD> packing.authentise.<TLD> payment.authentise.<TLD> print.authentise.<TLD> quickslice.authentise.<TLD> quoting.authentise.<TLD> rabbitmq.authentise.<TLD> rapidfab.authentise.<TLD> status.authentise.<TLD> stream.authentise.<TLD> syphon.authentise.<TLD> tetra.authentise.<TLD> users.authentise.<TLD> vision.authentise.<TLD> woodhouse.authentise.<TLD>
Custom Root CA¶
If the organization uses some kind of custom root certificate authority to issue SSL certificates (find out!) then there are a few things we have to fix. First, we need to get a copy of the root CA certificate so that we can add it to our certificate bundles. Second, we need to use that certificate on the Linux server to generate our own certificate bundle for the operating system. Third, you need to add that certificate to any windows servers
Linux Custom Root CA¶
Eli did it once for a customer but didn’t write down the steps so ask him about it. Effectively you’re going to follow the steps from the Debian README:
If you want to install local certificate authorities to be implicitly trusted, please put the certificate files as single files ending with ".crt" into /usr/local/share/ca-certificates/ and re-run 'update-ca-certificates'. If you remove local certificates from /usr/local/share/ca-certificates/, you can remove symlinks by running 'update-ca-certificates --fresh'. If you want to prepare a local package of your certificates, you should depend on ca-certificates, install the PEM files into /usr/local/share/ca-certificates/ as above and call 'update-ca-certificates' in the package's postinst, and should call 'update-ca-certificates --fresh' in the package's postrm.
After you’ve done that you need to create a custom data volume in docker that contains the updated ca-certificates file. Then you need to update the salt pillar so that all of the docker images mount that file and overwrite the default CA certificates file. Finally you’ll need to set up an environment variable for all the docker containers that set
REQUESTS_CA_BUNDLE to use the file since requests by default will use its own CA bundle separate from the OS.
Windows Root CA¶
Windows uses a certificate manager called
certmgr.msc which you can only open via the Run command. It holds all the certificate information for the system. This is entirely separate from the root CA store used by requests in all our Python code in windows. It’s good to know about the tool in case you need to export the Root CA which might be installed by the customer’s IT department. You can export the files into several different formats by right-clicking on the certificate you want, selecting ‘All Tasks’ and choosing ‘Export’. You usually want Base64-encoded X.509.
After that you’ll want to find your requests
cabundle file which will be installed alongside the requests code. Usually at
C:\Python35\Lib\site-packages\requests if you are using a system install. Take that file and copy it somewhere, I don’t care where. Append the entire content of your custom Root CA in X.509 format to the end of the file. Then update your windows service of choice, like Quickslice, to have an additional environment variable,
REQUESTS_CA_BUNDLE which points at the location of the modified file. We do it as a separate file so that when we inevitably update requests we don’t automatically blow away our file modifications