Summary:
During certificate exchange, the mobile device creates a public/private key pair, and then requests a certificate from flipper to match it's public key.
Flipper responds with the cert and it's written to the sonar dir along side the key pair files.
If certificate exchange happens again for any reason, the mobile device will regenerate the key pair and request a new cert. If for any reason that cert never arrives, then the device is in a state where it has the new key pair, but the old certificate that doesn't match its new credentials. This would never work, but it means you get a strange SSL error because you're using inconsistent files.
To improve error messaging, I'm making the client wipe all files before starting the certificate exchange step, so you should never get key/cert mismatches. Now the device can tell it doesn't have all the necessary files and won't even attempt to connect until it does.
Reviewed By: passy
Differential Revision: D13256369
fbshipit-source-id: 28f3cb5ba5938c17f01294683ba86c418f651376
Summary:
The CSR generation code is written in C-like code with no excpetions because so is openssl, with no RAII structures.
So we don't have fine-grained insight on what could go wrong, but at least if it fails altogether we should error.
Reviewed By: passy
Differential Revision: D13233725
fbshipit-source-id: 75cb3c21144b591947f686b5ad529a14a011baa8
Summary:
Part of the Sonar -> Flipper rename
Intentionally left externally visible buck target as Sonar for now to minimize diff size.
Reviewed By: passy
Differential Revision: D9871684
fbshipit-source-id: 6926eb62c578a05cd895745c75ed7da3cfe965b5
