Generating certificates in OS X 10.11 doesn't work

[oscarrenalias]

Overall output:

bash -x ./adop compose gen_certs ~/.foo
++ basename ./adop
+ CMD_NAME=adop
+++ echo ./adop
+++ sed -e 's,\\,/,g'
++ dirname ./adop
+ export CLI_DIR=.
+ CLI_DIR=.
+ export CONF_DIR=.
+ CONF_DIR=.
+ export CONF_PROVIDER_DIR=./conf/provider
+ CONF_PROVIDER_DIR=./conf/provider
+ CLI_CMD_DIR=./cmd
+ main compose gen_certs /Users/oscar.renalias/.foo
+ '[' 3 -lt 1 ']'
+ SUBCOMMAND=compose
+ shift
+ '[' '!' -e ./cmd/compose ']'
+ . ./cmd/compose gen_certs /Users/oscar.renalias/.foo
++ SUB_CMD_NAME=compose
++ DEFAULT_MACHINE_NAME=default
++ export MACHINE_NAME=default
++ MACHINE_NAME=default
++ export VOLUME_DRIVER=local
++ VOLUME_DRIVER=local
++ export LOGGING_DRIVER=syslog
++ LOGGING_DRIVER=syslog
++ export CUSTOM_NETWORK_NAME=local_network
++ CUSTOM_NETWORK_NAME=local_network
++ export OVERRIDES=
++ OVERRIDES=
++ export TOTAL_OVERRIDES=
++ TOTAL_OVERRIDES=
++ export PULL=YES
++ PULL=YES
++ getopts m:f:F:v:l:n:i: opt
++ shift 0
++ SUBCOMMAND_OPT=gen_certs
++ '[' 2 -ge 1 ']'
++ shift
++ ADOPFILEOPTS='-f ./docker-compose.yml -f ./etc/volumes/local/default.yml -f ./etc/logging/syslog/default.yml'
++ ELKFILEOPTS='-f ./compose/elk.yml'
++ case ${SUBCOMMAND_OPT} in
++ gen_certs /Users/oscar.renalias/.foo
++ echo 'Generating client certificates for TLS-enabled Engine'
Generating client certificates for TLS-enabled Engine
++ CERT_PATH=/Users/oscar.renalias/.foo
++ '[' -z /Users/oscar.renalias/.foo ']'
+++ uname
++ HOST_OS=Darwin
++ CLIENT_SUBJ=/CN=client
++ echo Darwin
++ grep -E 'MINGW*'
++ TEMP_CERT_PATH=/Users/oscar.renalias/docker_certs
++ rm -rf /Users/oscar.renalias/docker_certs
++ mkdir -p /Users/oscar.renalias/docker_certs
++ set +e
++ openssl genrsa -out /Users/oscar.renalias/docker_certs/key.pem 4096
++ openssl req -subj /CN=client -new -key /Users/oscar.renalias/docker_certs/key.pem -out /Users/oscar.renalias/docker_certs/client.csr
++ echo 'extendedKeyUsage = clientAuth'
++ openssl x509 -req -days 365 -sha256 -in /Users/oscar.renalias/docker_certs/client.csr -CA /Users/oscar.renalias/.docker/machine/certs/ca.pem -CAkey /Users/oscar.renalias/.docker/machine/certs/ca-key.pem -CAcreateserial -out /Users/oscar.renalias/docker_certs/cert.pem -extfile /Users/oscar.renalias/docker_certs/extfile.cnf
++ set -e
++ CERT_FILE=/Users/oscar.renalias/docker_certs/cert.pem
++ [[ -s /Users/oscar.renalias/docker_certs/cert.pem ]]
++ echo '/Users/oscar.renalias/docker_certs/cert.pem was not created successfully and is empty.'
/Users/oscar.renalias/docker_certs/cert.pem was not created successfully and is empty.
++ echo 'This is because you have not run your shell window in Administrator mode or with root access.'
This is because you have not run your shell window in Administrator mode or with root access.
++ echo 'Please run your shell window in Administrator mode or with root access and re-run the quickstart script with the same flags provided in this run.'
Please run your shell window in Administrator mode or with root access and re-run the quickstart script with the same flags provided in this run.
++ exit 1

The last openssl command is failing. When running it manually, this is the output:

Signature ok
subject=/CN=client
Getting CA Private Key
/Users/oscar.srl: Permission denied
43913:error:02001002:system library:fopen:No such file or directory:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.40.2/src/crypto/bio/bss_file.c:356:fopen('/Users/oscar.srl','r')
43913:error:20074002:BIO routines:FILE_CTRL:system lib:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.40.2/src/crypto/bio/bss_file.c:358:
43913:error:0200100D:system library:fopen:Permission denied:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.40.2/src/crypto/bio/bss_file.c:356:fopen('/Users/oscar.srl','w')
43913:error:20074002:BIO routines:FILE_CTRL:system lib:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.40.2/src/crypto/bio/bss_file.c:358:

I'm not sure why it's trying to create file /Users/oscar.srl, because that's never passed as a parameter anywhere. And I don't know enough of the openssl set of commands to troubleshoot this myself.

In case it helps, the version of OpenSSL is OpenSSL 0.9.8zh 14 Jan 2016 as provided in OS X 10.11.4.

Any ideas?

[josequaresma]

Hey Oscar. I encountered this issue before but then ended up not having time to follow up on it. My guess (and here his is more a guess than something else) is that that openssl command does not support paths that have dots in them. I think it finds the "." and thinks that the rest of the string is the extension and then replaces that by 'srl' (i think it needs to read from that file, which is in the docker_certs or machine/certs folder

[oscarrenalias]

It could be, but that's the kind of username that we get in our Accenture workstations so we can't work around that. And no, I don't think that doing this with sudo is a good alternative.

This should probably be documented as part of the README, under "Known issues" or similar, as it's a pretty important thing to keep in mind.

[josequaresma]

I agree. It is a bug thing to have in known issues though, since (as far as I know) you can't get it to work without the certificate installation. I will look into it the latest in the weekend

[dsingh07]

Hi @oscarrenalias

Can you please run your terminal with root-level access?

The problem is the fact that openSSL tries to read your .srl file which I think is a salt file needed to generate certificates. So because of the fact that the file by default lives outside your home directory, your terminal won't be able to read it if it doesn't have root access.

[oscarrenalias]

I could run as root but I won't 👎, as I don't see a clear reason for doing so and I think it's the wrong solution.

Besides, can you guarantee that the rest of the script will find the .srl file if it ends up under /Users/oscar.srl and not /Users/oscar.renalias//?

[larrywright]

Not meaning to hijack this issue, but I wanted to point out that it's not limited to OS X. If you run the ADOP setup in a non-Administrator windows terminal session, it also fails to generate the SSL certificates and then fails silently.

[nickdgriffin]

Yep, it's a known problem and that's why the readme states to run as administrator - it's existed since the beginning - and once that requirement has been satisfied everything works as expected. I believe #75 addresses/eliminates this issue though by forcing it to create the file somewhere that doesn't require root.

When it fails on Windows it's because of the same problem to do with where it decides to create the SRL file too.

[josequaresma]

This is still failing for me but #75 should have fixed it right? Maybe I am doing something wrong, but I am getting this:

$ ./adop compose gen-certs ${DOCKER_CLIENT_CERT_PATH} Generating client certificates for TLS-enabled Engine Generating RSA private key, 4096 bit long modulus ...................................................................................................................................++ ..................................................++ e is 65537 (0x10001) Signature ok subject=/CN=client Getting CA Private Key Could not read CA certificate "/c/Users/Jose.Quaresma/.docker/machine/certs/ca.pem": open /c/Users/Jose.Quaresma/.docker/machine/certs/ca.pem: The system cannot find the path specified.

I am running on Windows 10 with docker toolbox 1.11.1b.

Also, is there a specific reason why we are using &> /dev/null in the commands we have for generating the keys? that makes it fail silently as @larrywright mentioned above. (I have removed those from the compose script so that I could see the output)

[nickdgriffin]

We use it to cut out noise. It could start throwing things into log files instead though so it isn't lost but also doesn't clutter the output.

[josequaresma]

@nickdgriffin would it be okay to forward to a log file and then delete that file in the end if everything goes well?

[josequaresma]

In PR #104 the certificate generation is redesigned a bit and not using the home folder anymore for temporary folders (it is using mktemp). Could it be that this issue is fixed with that PR? Could you check @oscarrenalias ?