-
-
Notifications
You must be signed in to change notification settings - Fork 818
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
CERTIFICATE_VERIFY_FAILED on macOS Sierra Beta #1220
Comments
Unfortunately I haven't been able to replicate the issue, so I don't know exactly what needs to be fixed and/or changed. If you can do some more debugging I would appreciate it! |
I managed to fix this by changing my package settings. I made my
Note:
I'm in the process of debugging the python. It looks like it's an error with the way the new urllib is behaving with regards to SSL/HTTPS. If I had to guess I'd say that it was a problem with the script not running as root, and perhaps not being able to read from the CA file, or write the new ones to it. |
So I looked into this a bit more. In
And I get this:
It looks like the cert and certificates might be incorrectly passed through? |
So I've spent the last day debugging it (and having to constantly reload sublime...) and playing around with SSL and where it fails. It looks like the error is either A) not having the intermediary certificates, or the merged ca bundle not processing correctly. It's an SSL verification error - if you change "cert_reqs" to 0, it doesn't verify them, and urllib completes successfully, and the problem is mitigated. While that isn't ideal as it opens you up for MitM attacks, it does show that the error is in the certificate file. _ssl.c fails at verification (called from ssl.py). It's able to correctly fetched channels_v3.json. A short term fix is to just change the downloader priority for OS X or to disable SSL verification. Curl, however, doesn't run into these issues. It means that it is either more robust in it's parsing of certificates/verifying intermediaries or that there is a bug in the way we are passing certificates to the ssl socket wrapper for urllib (and that it only fails sometimes, as this bug is uncommon enough to only have a few issues on GH). I tried verifying the permissions of the file, but that seems fine. I'm kind of stuck unless I find a better way of debugging it. @wbond - how do you debug when developing Package Control? Sorry, I've never made a sublime plugin so I'm not familiar to how you hot reload sublime and how you add breakpoints to the python. I've been using a ton of console_write() but I would really like to be able to step into each function and view the current stack. |
I tend to use print() debugging within the Sublime Text python environment. If you save the file For reference, your oscrypto bundle is about 40KB smaller than mine. I am running El Capitan, but I don't believe I have any custom roots. Based on the filesize difference, it seems you have fewer trust roots. I've done some work recently to make it possible for oscrypto to allow a callback to be called for each certificate that is being exported from the trust store. This should allow us to identify if the root requires for https://packagecontrol.io is being properly exported. The other possibility I see is that the exported trust information coming from the OS X trust store is confusing OpenSSL. This could also explain why only some OS X users are seeing the issue. My plan is to further augment oscrypto to provide trust and reject info to the callback so a full picture of each certificate can be presented. Once this is in place, hopefully we should be able to identify the root cause. Considering the small number of users having the issue and the security risk associated with installing software, I definitely would not consider disabling SSL verification on OS X. I think users that are hitting it certainly can utilize the curl downloader, but I don't want that to be the default. I'd rather get the bug fixed. My hope is to have a new build out with the trust root debug info in the next week or two, but I can't commit to deadlines with open source projects. |
Thanks for the quick reply! I agree with all you said. The only thing is that it might be worth including this in the common bugs page on packagecontrol.io, as the current suggestions are just to purge old installations and try reinstalling. Some less motivated users might just abandon package control since the temporary fix takes a while to find. And I understand. Thanks again for making PC! |
@jonluca Thanks again for your solution. For anyone else that stumbles here (like myself) I had to use wget as the downloader program in order for it to work on NOTE: An important distinction to highlight here is to make sure you override the downloader precedence setting in the Package Control User settings file. |
@jonluca, @wbond, @avelis Thanks for the solution and for trying to fix this issue. The change of downloader preference to curl fixed the issue in my Mac OS X El Capitan 10.11.6 box. For the record: this issue appeared here after some changes in the communication infrastructure of my organisation triggered by recent cyber attacks. It was working fine until then. As this changes are also affecting other processes (Mac OS X software updated, for instance), I'll try to describe them and keep this thread posted. It must be some relationship between this issue and the new requirements to correctly communicate with the World! Here Sublime Text console contents after setting curl as downloader and launch Package Control...
Thanks for your time! |
Can you try manually upgrading to Package Control 3.3.0? I think this may be resolved now. |
Hi All, I wanted to comment to add. I have found a fix. I then took the CA root which happens to be GeoTrust Global CA, converted it from DER to PEM format. I then appended it to the oscrypto-ca-bundle.crt file. Everything works as expected again. |
@patchsmyle can you share more details on the steps you took to resolve it? I have the same problem as you and tried removing/purging package control and all those troubleshooting steps like switching the downloader to curl or wget, same problem.
|
I ran into the Certificate Failure error when trying to install a package, and @patchsmyle's comment led me on the path to find a solution. I seem to run into this problem once a year so I persisted until I found something that worked. First here are my versions:
I tried deleting the I tried changing the Package Control user preferences so that MacOS used
I then found a curl command that could trigger the same error. It is using the same Package Control merged CA bundle.
I then tried downloading the certificates for codeload.github.com:
This printed two certificates, "DigiCert SHA2 High Assurance Server CA" and "DigiCert High Assurance EV Root CA". I added the PEM output to the end of the The openssl command did have a small clue:
So I figured that appending that root certificate to the TL;DR Download the root CA for codeload.github.com and add the PEM output to the top of |
Great debug! Looks like this'll solve the problem once and for all @wbond. Thanks |
To make the CA persist in your settings, you should put it inside Also note that this is merely a workaround and not a proper fix. |
I am facing the same problem for two certificates. The root cause is that certificates in Keychain with modified trust settings (even when set to "Always Trust") are not getting exported to the *ca-bundles. System Root Certificates are only exported correctly when they are marked as "This certificate is valid" . Still seems to be a sublime bug. The described solution exporting those certificates as .pem files and adding them manually to Package Control.user-ca-bundle works but is only a workaround. BR |
Thanks @patchsmyle, it did fixed my bug! (High Sierra, 10.13.2) |
I believe the latest build 3158 has fixed this issue for me on macOS: 😄 Relevant parts of the changelog:
|
@jonluca I tried to set the setting as you suggested. Now I got the following error:
|
@michelleowen It looks like you're sitting behind a bloomberg proxy. The errror is that curl is not verifying the certchain. It looks like curl was not compiled with openssl. |
@jonluca I tried this already, I still got the same error though. |
Hi i tried changing the osx downloader preference curl, but I got the following error.
|
Thanks!! |
THX!! |
Brilliant. It would be great if @jonluca could update his reply to clarify this. I edited my personal settings to no effect - but once I changed the Package Control settings and saved the issue resolved itself immediately. |
You saved my day! thanks! |
fyi, |
To fix issues on osx: wbond/package_control#1220 (comment)
awesome, fixed with curl setting |
Error Log:
Package Control: Fetching list of available packages and dependencies
Platform: osx-x64
Sublime Text Version: 3126
Package Control Version: 3.2.1
Package Control: Download Debug
URL: https://packagecontrol.io/channel_v3.json
Timeout: 30
Resolved IP: 50.116.34.243
Resolved IPv6: 2600:3c02:e000:42::1
Package Control: Urllib Debug Proxy
http_proxy:
https_proxy:
proxy_username:
proxy_password:
Package Control: Found previously exported CA bundle at /Users/jonlucadecaro/Library/Application Support/Sublime Text 3/Packages/User/oscrypto-ca-bundle.crt (268794 bytes)
Package Control: Urllib HTTPS Debug General
Connecting to packagecontrol.io on port 443
Package Control: Urllib HTTPS Debug General
Upgrading connection to SSL using CA certs file at /Users/jonlucadecaro/Library/Application Support/Sublime Text 3/Packages/User/Package Control.merged-ca-bundle
Package Control: Error downloading channel. HTTP exception InvalidCertificateException (Host packagecontrol.io returned an invalid certificate ([SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:548))) downloading https://packagecontrol.io/channel_v3.json.
I have tried manually pasting the certificate into both merged-ca-bundle and user-ca-bundle.
There seem to be two other issues open about this issue as well, but they seem to be dead. Package Control is not usable while this happens.
The text was updated successfully, but these errors were encountered: