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

Add an option to the notary client config file to point to folder/file for alternate trust root #204

Closed
cyli opened this issue Oct 5, 2015 · 6 comments

Comments

@cyli
Copy link
Contributor

cyli commented Oct 5, 2015

This way root CAs do not have to be added to the system in order to test self-signed certificates.

This gets around having to change the client's system (in Mac OS, involves editing /System/Library/Keychains/SystemRootCertificates.keychain).

See https://golang.org/src/crypto/tls/common.go?#L235.

Notary already makes use of a config file as well as the tls config.

@glyph
Copy link

glyph commented Oct 5, 2015

It's worth noting that changing the file at that path on the latest OS X release – El Capitan – requires rebooting into a recovery shell, so not something you can do as part of an automated dev environment setup. See Homebrew/legacy-homebrew#40837 (comment)

@diogomonica
Copy link
Contributor

@cyli @glyph checkout #210

Added the ability of having notary-cli config being loaded through a cmd-line variable (or by default under ~/.notary/config.json), and I'm now allowing setting a root-ca file. This should remove the need for messing with Library Keychains for development and testing.

@glyph
Copy link

glyph commented Oct 10, 2015

@diogomonica What would be really cool is if, rather than hard-coding the system keychain path, it extracted the current set of user-configured trust roots. Unfortunately this involves a complex series of Security.framework APIs I haven't quite figured out yet :). Maybe SecTrustCopyCustomAnchorCertificates?

@glyph
Copy link

glyph commented Oct 10, 2015

@diogomonica (that is only really a solution for OS X though, I don't think there's a reasonable equivalent to Keychain Access on Linux)

@glyph
Copy link

glyph commented Oct 10, 2015

Sorry, re-reading that, I think I wasn't very clear. What I meant to say is, configuring a trust root .pem path is cool, #210 is a good step, it's a necessary step for Linux regardless, but a better default than trusting the system keychain would be to trust the actual trust evaluation anchor set configured by the OS X platform, since users can add and remove trusted root certificates in the Keychain Access app (and also potentially via various Keychain APIs) that are per-user rather than system-wide; or, system-wide configured in /Library rather than /System/Library.

@cyli
Copy link
Contributor Author

cyli commented Oct 15, 2015

#210 got merged, s o closing this. Per-user trust roots can maybe be a different issue, since it's OS X specifically?

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

No branches or pull requests

4 participants