-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
openssl: generate cacert.pem from system and user CA #2825
Conversation
The implementation looks fine. I'm just worried about the security now that anyone with access to the system can now insert their cert into the chain, perhaps for nefarious reasons. |
Yes, I guess that is a possibility, and not one to which I have a solution. Given the design of the entire root-only system, this is just one more potential issue for the list... |
It's possible (but not as elegant) to bind-mount a custom cert (as proved by @vpeter4 in the forums) so restricting the cert to be in the read-only filesystem area doesn't afford greater security. Plus, if an actor with bad intentions has compromised an LE installation there are much more interesting things that can be done and malicious tweaking of an SSL cert chain is the least of your worries. |
The problem with the bind mount solution (and indeed any solution that replaces the system provided CA bundle with a complete alternative bundle) is that as the system installed bundle is updated with new CA certs over time, the user with the bind mounted CA bundle will not see these new CA changes - they will complain when public sites slowly become inaccessible due to expired/revoked CAs in their increasingly stale custom CA bundle. They'll almost certainly neglect to inform us they are using a bind mounted custom CA bundle when reporting some weird TLS issue that nobody else is able to reproduce, because they themselves will have forgotten they set it up months previously (it's easily done, been there/done it myself...) |
One other option is to leave /etc/ssl/cacert.pem as readonly. Instead users put it's own certs in some folder at /storage and use |
I can confirm: it's working with my webdavs connection now! |
From Milhouse build #715, 15-Jul-2018:
I assume changing path /etc/ssl/cert.pem was bad idea and would need to change in every other package? From strace I see that Python is expecting file /etc/ssl/cert.pem. I assume because this is default path used by openssl in file crypto/cryptlib.h. That's why I was wondering about renaming file and also moving location. I would just leave this file as was before. There is no point of changing every other package if this is default file name. So change back cacert.pem to cert.pem in /etc/ssl. Just made a test and it is working as it should. Also with custom cacert. |
Curiously, I get the same error as you on a NUC, but not on an RPi or RPi2 build. Some parts of openssl refer to cacert.pem, while other parts refer to cert.pem. I think I'll just add a |
I think cacert.pem is filename used when making self signed certificates and there is no need to put it there. That's why change in openssl.cnf was not needed either. I think with another file we will just have a mess. Only because the problem is not understand fully. |
I wouldn't call adding a second file a mess, but there are parts of OpenSSL which default to cacert.pem, and other parts which default to cert.pem, so it's OpenSSL that seems to be a bit of a mess! While we could switch back to using cert.pem only, adding a second sym link resolves both issues. The need for cacert.pem is very likely a corner case, but it's configured correctly now so I'd like to keep it. This doesn't look like too much of a mess:
|
I don't see a need to /etc/ssl/cacert.pem when grepping openssl. Now I see that change in curl is also not needed anymore. |
This should allow users to append their own self-signed CA.
https://forum.libreelec.tv/thread/12789-adding-own-certs-to-connect-via-webdavs-sftp-again