-
Notifications
You must be signed in to change notification settings - Fork 51
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
Feature request: let client compare self-signed server cert against local embedded version #81
Conversation
… check the server certificate using an embedded local certificate
This can't be merged until you resolve the following issue that is causing a CI failure...
The API, SecTrustEvaluateWithError is not available on all versions of OS that are currently supported by BlueSSLService. In order to accept this PR, you'll have to make changes so that the applicable code is only built when building on macOS 10.14 or higher. This can be accomplished using the if #available() notation. This link goes to the documentation for the #available notation. You have to be able to build without any additional command line parameters. Thanks for the contribution. |
Thanks. Looks like it's passing CI now. |
Any chance you can add a test using that case to SSLServiceTests.swift? That'd be extremely helpful. Thanks. |
…client connection. Added test for embedded certificate on OSX. Adding cert.der (converted from existing cert.pem) to use as embedded server cert.
I added test test case to the SSLServiceTests.swift, but I noticed that the SSL option was turned off for Apple platforms. I turned it back on. All tests are working correctly for me building locally on OSX with SSL, but the Travis CI seems to hang when the client connects. Can you help? Here's the last output before hang...
|
…st will pass Travis CI.
I changed the test order so the original test could be executed first, but it still hangs on connect. I suspect this might be an issue with the Travis CI environment. All tests pass for me locally on OSX 10.14.6. |
Merge remote-tracking branch 'upstream/master' into embeddedServerCert
@djones: Any insight on the CI failure? Thanks. |
Thanks. The last time we had this type of failure it turned out to be a real bug that only seemed to show up in CI. That’s why I asked @djones to take a look. He’s our CI guru. 😉 |
I’ll look into it more. |
Disable SSL when testing on macOS so that it passes CI. This is a definitely a CI problem. After I merge, I'll test locally on macOS to ensure it passes the new test before doing the release. Thanks for your patience... |
Done. Passing CI now. |
@djones6: Can you take a look at the CI failure when we turn on testing for macOS? It passes locally but I want to make sure we’re dealing with a CI issue before I merge the changes. Thanks. |
@billabt I'm afraid I am by no means an expert on this, but my guess would be that the hang is to do with unlocking the keychain. I have successfully used a trick in the past in a headless environment (not Travis) which creates a new keychain (and unlocks it) prior to running the tests: You could add a script like this as I'd be somewhat surprised however if this solves this issue, because we're successfully running Kitura's CI with SSL enabled in Travis without any such tricks. Worth a try though. |
It looks like the statements in @djones6 |
The Travis log shows that the script is running, and doesn't indicate there being any problems with it:
If this doesn't work, then I'm afraid I don't know. For the sake of this PR, the CI is sufficient to demonstrate that it builds successfully in each of the environments. If we can also demonstrate that local testing of the feature is successful, I think that'll have to be good enough. |
I agree. I'll run the checks here to confirm. |
Any issues running the checks? Let me know if I can help. |
@kkieffer Sorry I haven't merged this yet. Spent a bit of time in the hospital and then a bit of recovery time. I should be able to wrap it up this week. Again, sorry... |
No worries, sorry to hear you were in the hospital. |
Any updates? |
Sorry this took so long. Ran into a problem when publishing on cocoa pods. Had to change the if available statement to include tvOS 12.0 as well. Also had to make changes to the Xcode project file (for those that use it) so that it can run the test when enabled. It's now released as Version 1.0.52 on both Github and Cocoapods. |
Awesome - thank you! |
Added an optional URL with a path to a local DER-encocded certificate. When allowing self-signed certificates, the embedded certificate is loaded as an Anchor Certificate and validated using SecTrustEvaluateWithError()
Description
For the user, the only interface change is an optional URL in the Configuration init() method. If not set, the previous behavior is maintained. When the URL is set to a file, and the user has allowed self-signed certificates and is a client, then during the SSLHandshake the server presented trust is validated against the embedded certificate. The certificate must be a DER encoded X.509 certificate.
Motivation and Context
I am using BlueSSLService on iOS to connect securely to a server that uses its own root certificate, but I would like to validate the certificate. Previously, you can only accept any server supplied certificate, or the server certificate must be trusted by iOS. (There's no way to programmatically add the certificate to iOS keychain, you must go through a process to have the user install from a browser). If I have the public certificate of the server embedded in the app, I can use this feature to validate it.
How Has This Been Tested?
This is an iOS feature only - not implemented on Linux. I verified that when the URL is set to nil, the behavior is unchanged - I can successfully connect to my server when self-signed is true, and I get an errSSLXCertChainInvalid error when self-signed is false. If I embed by server certificate in the app and load it as follows
let path = Bundle.main.url(forResource: "cert", withExtension: ".der")
Then it successfully establishes the SSL connection. If I use a different (dummy) certificate, I again get the errSSLXCertChainInvalid error.
Note that in order to compile I needed to use
`swift build -Xswiftc "-target" -Xswiftc "x86_64-apple-macosx10.14"
because SecTrustEvaluateWithError is a 10.14 feature.
Checklist: