Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix use of multiple CAs on Linux #59

Closed
wants to merge 1 commit into from

Conversation

vortura
Copy link

@vortura vortura commented Aug 15, 2018

Fix a bug on Linux where multiple CAs would overwrite each other by
replacing the static SystemTrustFilename with a variable name based on
caUniqueName().

This should address #52

Fix a bug on Linux where multiple CAs would overwrite each other by
replacing the static SystemTrustFilename with a variable name based on
caUniqueName().
@vortura
Copy link
Author

vortura commented Aug 15, 2018

Just to give a bit more detail on the fix...

Rather than writing the CA cert to a fixed location (/etc/pki/ca-trust/source/anchors/mkcert-rootCA.pem or /usr/local/share/ca-certificates/mkcert-rootCA.crt) for import into the Linux system trust store, it now writes to e.g. <base_path>/<ca_unique_name>.(crt|pem). This means when you have multiple CAs in use, the filenames don't collide, and therefore all available CAs are correctly imported into the trust store. <ca_unique_name> in this case is the output of caUniqueName with spaces replaced with underscores.

Because we don't have access to the mkcert struct (and caUniqueName() from the truststore_linux.go init() function, I've moved determination of the SystemTrustFilename to a new method defined on the struct. The init function now determines the appropriate base directory and file extension for the file, which is used in the systemTrustPath() function with caUniqueName() to identify the final location of the CA root file for import. Anywhere that previously referenced the SystemTrustFilename variable now calls m.systemTrustPath() instead.

@FiloSottile
Copy link
Owner

Thank you for the contribution! I did something similar in 0bd4ac6, rebasing and adding a cleanup step for the old file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants